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: [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:24:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Jan 2010 23:24:01 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1264980241.41.0.738925850481.issue6939@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in py3k (r77895, r77896) and 3.1 (r77897). Thank you Pascal!

----------
resolution: accepted -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

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: [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 00:50:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 23:50:59 +0000
Subject: [issue7544] Fatal error on thread creation in low memory condition
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1264981859.89.0.137380787844.issue7544@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> PyThreadState_Prealloc and PyThreadState_Init should (...) be prefixed with an underscore (...)

done

> _PyThreadState_New should be static (...) so something like "new_threadstate"

done

> the last change ("Py_InitializeEx() calls _PyGILState_Init() before initsite()") should be part of a separate patch (and issue?)

I'm unable to reproduce the bug related to this patch. I keep the patch somewhere in my disk, and I will open a new issue if I'm able to reproduce it :-)

> you can use the -R option to regrtest to find out if there are any reference leaks (e.g. "-R 3:2:")

I tried all test*thread*py. test_threadsignals leaks a reference... even without my patch, so I opened a new issue: #7825.

----------
Added file: http://bugs.python.org/file16074/thread_prealloc_pystate-4.patch

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

From report at bugs.python.org  Mon Feb  1 00:51:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 23:51:06 +0000
Subject: [issue7544] Fatal error on thread creation in low memory condition
In-Reply-To: <1261226973.79.0.247580976393.issue7544@psf.upfronthosting.co.za>
Message-ID: <1264981866.89.0.912516835507.issue7544@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file15888/thread_prealloc_pystate-3.patch

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

From report at bugs.python.org  Mon Feb  1 00:54:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 31 Jan 2010 23:54:28 +0000
Subject: [issue7478] _sqlite3 doesn't catch PyDict_SetItem error
In-Reply-To: <1260533479.81.0.324820101165.issue7478@psf.upfronthosting.co.za>
Message-ID: <1264982068.3.0.48257141864.issue7478@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

ghaering> I will soon push updates to the version in Python core.

What do you mean by "soon"?

----------

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

From report at bugs.python.org  Mon Feb  1 01:01:49 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 01 Feb 2010 00:01:49 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264982509.42.0.173170517112.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16047/issue7092_Wd_warnings.diff

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

From report at bugs.python.org  Mon Feb  1 01:07:59 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 01 Feb 2010 00:07:59 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264982879.72.0.819148693894.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16050/issue7092_py3k_warnings_args.diff

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

From report at bugs.python.org  Mon Feb  1 01:08:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 01 Feb 2010 00:08:04 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264982884.93.0.148641986217.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16051/issue7092_py3k_warnings_noargs.diff

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

From report at bugs.python.org  Mon Feb  1 01:08:42 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 01 Feb 2010 00:08:42 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264982922.08.0.417827604522.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file16075/issue7092_py3k_warnings_args_v2.diff

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

From report at bugs.python.org  Mon Feb  1 01:09:13 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 01 Feb 2010 00:09:13 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1264982953.44.0.646399317697.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file16076/issue7092_py3k_warnings_noargs_v2.diff

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

From report at bugs.python.org  Mon Feb  1 01:59:13 2010
From: report at bugs.python.org (Brian Harring)
Date: Mon, 01 Feb 2010 00:59:13 +0000
Subject: [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:21:10 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 01 Feb 2010 01:21:10 +0000
Subject: [issue7824] assertion error in 2to3
In-Reply-To: <1264980229.62.0.257206789858.issue7824@psf.upfronthosting.co.za>
Message-ID: <1264987270.57.0.456295782456.issue7824@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the report. This is now fixed in r77900.

----------
nosy: +loewis
resolution:  -> fixed
status: open -> closed

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

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


Brian Harring <ferringb at gmail.com> added the comment:

Attached is a derivative of http://pkgcore.org/trac/pkgcore/browser/ferringb/snakeoil-dev/snakeoil/caching_2to3.py

As you can see in that function, some nastyness is required right now to slip it in w/out duplicating code (hence the first patch).

Patch attached here inlines the support directly into a new module lib2to3.caching, and derives on the fly a caching version of the RefactoringTool.

The on the fly bit is somewhat fancy I admit, but was done so that anyone using an alternate RefactoringTool can get the same benefits.

The sole con to this functionality is that it assumes the transformation will always be the same; in other words, it doesn't account for --fix/--nofix, nor changes in the transformation algorithms that would result in  differing output.

Personally for my uses this was completely valid- when changing the python version (even a minor upgrade) on my buildslaves I'd wipe the caches to be safe anyways.

That said, if there *is* interest in getting caching into stdlib for this, I can poke through the code and incorporate awareness of nofix/fix/python version into the cache key.  I skipped doing that however since I didn't think there was a chance in hell of caching going into mainline however ;)

Either way, for folks targeting py2k and using buildslaves to validate their code and the translation of said code for py3k, either of these patches really is needed to support caching and stop burning cycles.

----------
Added file: http://bugs.python.org/file16078/2to3-caching.patch

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

From report at bugs.python.org  Mon Feb  1 02:28:48 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 01 Feb 2010 01:28:48 +0000
Subject: [issue7826] support caching for 2to3
In-Reply-To: <1264985952.93.0.779639488883.issue7826@psf.upfronthosting.co.za>
Message-ID: <1264987728.68.0.5942731258.issue7826@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Not sure what your use case is, but I always call the refactor method of my subclassed RefactoringTool, instead of calling main. See distutils.util.run_2to3 for an example (and distutils.command.build_py.build_py_2to3 for an application of that).

----------
nosy: +loewis

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

From report at bugs.python.org  Mon Feb  1 02:40:39 2010
From: report at bugs.python.org (Meador Inge)
Date: Mon, 01 Feb 2010 01:40:39 +0000
Subject: [issue2454] sha and md5 fixer
In-Reply-To: <1206147643.89.0.60936055638.issue2454@psf.upfronthosting.co.za>
Message-ID: <1264988439.18.0.894865406608.issue2454@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Attached a patch that provides a (sha | md5) -> hashlib fixer, covering test cases, and updated documentation.

----------
keywords: +patch
nosy: +minge
Added file: http://bugs.python.org/file16079/issue-2454.patch

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

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: [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 03:00:14 2010
From: report at bugs.python.org (Brian Harring)
Date: Mon, 01 Feb 2010 02:00:14 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1264989614.4.0.551885493221.issue1943@psf.upfronthosting.co.za>


Changes by Brian Harring <ferringb at gmail.com>:


----------
nosy: +ferringb

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

From report at bugs.python.org  Mon Feb  1 03:34:17 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 01 Feb 2010 02:34:17 +0000
Subject: [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: <1264991657.34.0.925035251685.issue7827@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is fixed in Python 3.

I think it is (another) bug that it accepts array objects; it should reject them with the same error. OTOH, recv_into should use "w*".

----------
nosy: +loewis

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

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


Brian Harring <ferringb at gmail.com> added the comment:

@martin:

Yeah... that's probably the better approach, although seperation of processes (in terms of setup.py triggering conversion) has some benefits.

The reason I used process seperation and invocation of main was to protect my distutils extensions against having to know the innards of lib2to3- either it could invoke the normal 2to3 or invoke the caching version for the buildslaves.  Essentially I wanted the caching version to behave the same as normal 2to3 invocations.

Not great I'll admit, but so it goes.  I'd still like to see the caching integrated in some form w/in stdlib since it has definite benefits- and folk are more likely to use something from stdlib than go raiding from a backwater pkg like snakeoil.  That said, we'll see what folks think ;)

----------

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

From report at bugs.python.org  Mon Feb  1 04:28:55 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 01 Feb 2010 03:28:55 +0000
Subject: [issue2454] sha and md5 fixer
In-Reply-To: <1206147643.89.0.60936055638.issue2454@psf.upfronthosting.co.za>
Message-ID: <1264994935.95.0.226430090216.issue2454@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components:  -2to3 (2.x to 3.0 conversion tool)
stage:  -> patch review
type:  -> behavior

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

From report at bugs.python.org  Mon Feb  1 04:30:38 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 01 Feb 2010 03:30:38 +0000
Subject: [issue7826] support caching for 2to3
In-Reply-To: <1264985952.93.0.779639488883.issue7826@psf.upfronthosting.co.za>
Message-ID: <1264995038.93.0.705256454763.issue7826@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> test needed

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

From report at bugs.python.org  Mon Feb  1 04:32:02 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 01 Feb 2010 03:32:02 +0000
Subject: [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: <1264995122.65.0.65107114421.issue7827@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> test needed

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

From report at bugs.python.org  Mon Feb  1 04:59:29 2010
From: report at bugs.python.org (Andrew Hays)
Date: Mon, 01 Feb 2010 03:59:29 +0000
Subject: [issue7823] multiplying a list of dictionaries
In-Reply-To: <1264972707.42.0.603624170105.issue7823@psf.upfronthosting.co.za>
Message-ID: <1264996769.75.0.547403054548.issue7823@psf.upfronthosting.co.za>


Andrew Hays <me at andrewhays.net> added the comment:

Ah, my apolgogies, I didn't realize that.  I suppose I didn't look deeply enough into the situation.  I just realized that it worked that way with dictionaries, but by the same right, x=[[]]*3 would create [[], [], []] and if I said x[0][0]=1 then it would only do that for the first inner array. (e.g. x = [[1], [], []]).  Again, my apologies for not looking into this further.

----------

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

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: [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 07:08:56 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Feb 2010 06:08:56 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265004536.24.0.976584890789.issue6760@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ncoghlan

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

From report at bugs.python.org  Mon Feb  1 07:40:54 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 01 Feb 2010 06:40:54 +0000
Subject: [issue2454] sha and md5 fixer
In-Reply-To: <1206147643.89.0.60936055638.issue2454@psf.upfronthosting.co.za>
Message-ID: <1265006454.43.0.946215133888.issue2454@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
components: +2to3 (2.x to 3.0 conversion tool)

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

From report at bugs.python.org  Mon Feb  1 07:42:02 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 01 Feb 2010 06:42:02 +0000
Subject: [issue7826] support caching for 2to3
In-Reply-To: <1264985952.93.0.779639488883.issue7826@psf.upfronthosting.co.za>
Message-ID: <1265006522.27.0.444705121289.issue7826@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

If you meant to propose a patch that does caching, you should include the actual caching code in the patch.

----------

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

From report at bugs.python.org  Mon Feb  1 08:46:58 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 01 Feb 2010 07:46:58 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1265010418.65.0.361267228875.issue3426@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Small note:
 - the unit tests could use assertIsInstance(..., str), assertIsInstance(..., unicode) instead of the custom methods.
 - some "assertTrue" may be replaced by "assertEqual"

----------

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

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


Brian Harring <ferringb at gmail.com> added the comment:

*Cough*.

Ya, going to blame the bugzie on that one.  right, it's at fault rather than me being a complete freaking moron.

Patch attached, hopefully with far less idiocy than I've demonstrated thus far....

Pardon.

----------
Added file: http://bugs.python.org/file16080/2to3-caching.patch

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

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


Brian Harring <ferringb at gmail.com> added the comment:

Related note, don't be drunk when posting the missing patch- sorry for the noise, here is the caching version,, daftly presumed the early patch contained lib2to3.caching

Now I'm going to go crawl in a corner, if you need me, I'll be there.
Doubly pardon.

As for the algo, sha1 might be wiser- as said, integrating fix/nofix is definitely needed, let alone writing tests.  This is more a proof of concept I was using for speed reasons- assuming folk are game, I'm game to write the tests for it.

----------
Added file: http://bugs.python.org/file16081/2to3-caching.patch

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

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


Changes by Brian Harring <ferringb at gmail.com>:


Removed file: http://bugs.python.org/file16078/2to3-caching.patch

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

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


Changes by Brian Harring <ferringb at gmail.com>:


Removed file: http://bugs.python.org/file16080/2to3-caching.patch

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

From report at bugs.python.org  Mon Feb  1 10:53:13 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 01 Feb 2010 09:53:13 +0000
Subject: [issue7826] support caching for 2to3
In-Reply-To: <1264985952.93.0.779639488883.issue7826@psf.upfronthosting.co.za>
Message-ID: <1265017993.24.0.885853866237.issue7826@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please submit a contributor agreement, see http://www.python.org/psf/contrib/

I'm still not clear on what the specific use case is: how *exactly* are you going to run 2to3 when you have that patch integrated? In particular, where do you put the output (3.x) files? I'd rather recommend to create a --outdir option (assuming that would also fit your needs).

I'm -0 on using hashing. The whole point of this caching is speed, so wasting time in recomputing hash codes is, well, wasted.

If you do think you need hashing, please read the source file in binary, rather than first decoding and then encoding it.

Don't use print(). If you must output progress, use the same approach as the rest of 2to3 (i.e. logging).

----------

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

From report at bugs.python.org  Mon Feb  1 10:59:59 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 01 Feb 2010 09:59:59 +0000
Subject: [issue7030] Update version{added,
	changed} entries in py3k unittest docs
In-Reply-To: <1254427741.8.0.290853000948.issue7030@psf.upfronthosting.co.za>
Message-ID: <1265018399.77.0.908845495217.issue7030@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The versionadded/changed have been fixed in r77788.
The doc for assertSameElements should also clarify that repeated elements are ignored.

----------

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

From report at bugs.python.org  Mon Feb  1 11:14:14 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 01 Feb 2010 10:14:14 +0000
Subject: [issue7030] Update version{added,
	changed} entries in py3k unittest docs
In-Reply-To: <1254427741.8.0.290853000948.issue7030@psf.upfronthosting.co.za>
Message-ID: <1265019254.01.0.560826547856.issue7030@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

s/r77788/r77888/

----------

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

From report at bugs.python.org  Mon Feb  1 11:39:19 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 01 Feb 2010 10:39:19 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1263164005.3610.11.camel@localhost>
Message-ID: <4B66AF53.3090605@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> I find that the null termination for 8-bit strings makes low-level
>> parsing operations (e.g., parsing a numeric string) safer and easier:
> 
> Not to mention faster. The new IO library makes use of it (for newline
> detection), on both bytestrings and unicode strings.

I'd consider that a bug. Esp. the IO lib should be 8-bit clean
in the sense that it doesn't add any special meaning to NUL
characters or code points.

Besides, using a for-loop with a counter is both safer and faster
than checking each an every character for NUL.

Just think of what can happen if you have buggy code that overwrites
the NUL byte in some corner case situation and then use the assumption
of having the NUL byte as terminator - a classical buffer overrun.

If you're lucky, you get a segfault. If not, you end up with
data corruption or manipulation of data which could lead to
unwanted code execution.

The Python Unicode API deliberately tries to always use the combination
of a Py_UNICODE* pointer and a length integer to avoid such issues.

----------

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

From report at bugs.python.org  Mon Feb  1 12:39:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Feb 2010 11:39:54 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <4B66AF53.3090605@egenix.com>
Message-ID: <1265024472.3326.7.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'd consider that a bug. Esp. the IO lib should be 8-bit clean
> in the sense that it doesn't add any special meaning to NUL
> characters or code points.

It doesn't add any special meaning to them. It just relies on a NUL
being present after the end of the string. It doesn't care about other
NULs.

> Besides, using a for-loop with a counter is both safer and faster
> than checking each an every character for NUL.

It's slower, since it has one more condition to check.
Newline detection as it is written has a fast path in the form of:
     while (*c++ >= 0x20);

> Just think of what can happen if you have buggy code that overwrites
> the NUL byte in some corner case situation and then use the assumption
> of having the NUL byte as terminator - a classical buffer overrun.

Well, buggy code leads to bugs :)

----------

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

From report at bugs.python.org  Mon Feb  1 12:47:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Feb 2010 11:47:25 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265024845.95.0.616500590196.issue6760@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is a particularly verbose patch for the information it is trying to convey.

----------
nosy: +pitrou

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

From report at bugs.python.org  Mon Feb  1 12:56:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Feb 2010 11:56:34 +0000
Subject: [issue7823] multiplying a list of dictionaries
In-Reply-To: <1264972707.42.0.603624170105.issue7823@psf.upfronthosting.co.za>
Message-ID: <1265025394.85.0.0894113623091.issue7823@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not quite sure from what you wrote if you understood.  Just to make sure no one reading this ticket later gets confused: it works the same way for all objects, and the behavior that sometimes surprises people shows up with mutable objects.  So lists and dicts behave the same way in this scenario:

>>> x = [[]]*3
>>> x
[[], [], []]
>>> x[0].append(1)
>>> x
[[1], [1], [1]]

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Mon Feb  1 12:57:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Feb 2010 11:57:01 +0000
Subject: [issue7823] multiplying a list of dictionaries
In-Reply-To: <1264972707.42.0.603624170105.issue7823@psf.upfronthosting.co.za>
Message-ID: <1265025421.05.0.399480392223.issue7823@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
stage:  -> committed/rejected

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

From report at bugs.python.org  Mon Feb  1 14:04:49 2010
From: report at bugs.python.org (Andrew Dalke)
Date: Mon, 01 Feb 2010 13:04:49 +0000
Subject: [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: <1265029489.99.0.075902091859.issue7827@psf.upfronthosting.co.za>


Andrew Dalke <dalke at dalkescientific.com> added the comment:

Since I see the change to "test needed", I've attached a diff against Python 2.6's test_socket.py. I would have generated one against the 2.7 version in subversion but that test doesn't exit.

----------
keywords: +patch
Added file: http://bugs.python.org/file16082/test_socket.py.diff

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

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: [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 14:28:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Feb 2010 13:28:10 +0000
Subject: [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: <1265030890.17.0.203720412009.issue7829@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: georg.brandl -> brett.cannon
nosy: +brett.cannon

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

From report at bugs.python.org  Mon Feb  1 14:43:14 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 01 Feb 2010 13:43:14 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1265031794.96.0.769715438051.issue1943@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Again, on Windows there are many many usages of PyUnicode_AS_UNICODE() that pass the result to various Windows API functions, expecting a nul-terminated array of WCHARs. Please don't change this!

----------

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

From report at bugs.python.org  Mon Feb  1 15:15:58 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 01 Feb 2010 14:15:58 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1265033758.98.0.109449365664.issue5677@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I see that a complete errno based solution would get messy. To avoid
interfering with EAGAIN special cases, this would be needed:

#if defined(EBADF)
#define ERRNO_EBADF(x) ((x) == EBADF)
#else
#define ERRNO_EBADF(x) 0
#endif

Then, additional checks would need to be added to get_line,
getline_via_fgets and a couple of other places.


I think the right thing is to add a field f_modeflags to the file
object, to be initialized on creation. Or use f->readable, f->writable
like py3k. Thoughts?

----------

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

From report at bugs.python.org  Mon Feb  1 15:37:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Feb 2010 14:37:16 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1265035036.27.0.328189317599.issue5677@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think checking errno would be fine (provided it eliminates all variations ot this bug).

----------

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

From report at bugs.python.org  Mon Feb  1 15:59:52 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 01 Feb 2010 14:59:52 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1265036392.4.0.977295293104.issue3426@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The patch intentionally doesn't use assertIsInstance because that method doesn't exist in 2.6.

----------

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

From report at bugs.python.org  Mon Feb  1 16:46:21 2010
From: report at bugs.python.org (Jon Foster)
Date: Mon, 01 Feb 2010 15:46:21 +0000
Subject: [issue6906] Tkinter sets an unicode environment variable on win32
In-Reply-To: <1252920566.52.0.249075498328.issue6906@psf.upfronthosting.co.za>
Message-ID: <1265039181.72.0.357567611888.issue6906@psf.upfronthosting.co.za>


Jon Foster <jon.foster at cabot.co.uk> added the comment:

This bug also breaks code that uses the subprocess module, e.g.:

env = os.environ.copy()
env['MY_VARIABLE'] = 'MY_VAL'
subprocess.Popen(... , env=env)

Fails on Windows 7 with an error that the environment can only contain strings.  The offending variables are TK_LIBRARY and TCL_LIBRARY, which have Unicode strings as their values.  I'm using Python 2.6.2.

(The subprocess module should probably be fixed to use CreateProcessW and handle Unicode, but that's a separate issue).

----------
nosy: +JonFoster

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

From report at bugs.python.org  Mon Feb  1 16:50:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Feb 2010 15:50:42 +0000
Subject: [issue7805] test_multiprocessing failure
In-Reply-To: <1264773760.19.0.248393154087.issue7805@psf.upfronthosting.co.za>
Message-ID: <1265039442.89.0.515392631116.issue7805@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Also witnessed on one of the buildbots:

test test_multiprocessing failed -- Traceback (most recent call last):
  File "/home/pybot/buildarea/3.x.klose-debian-ia64/build/Lib/test/test_multiprocessing.py", line 1076, in test_pool_worker_lifetime
    self.assertNotEqual(sorted(origworkerpids), sorted(finalworkerpids))
TypeError: unorderable types: NoneType() < int()

http://www.python.org/dev/buildbot/3.x.stable/builders/ia64%20Ubuntu%203.x/builds/434/steps/test/logs/stdio

----------
assignee:  -> jnoller
components: +Tests
versions: +Python 3.1 -Python 2.7

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

From report at bugs.python.org  Mon Feb  1 16:50:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Feb 2010 15:50:50 +0000
Subject: [issue7805] test_multiprocessing failure
In-Reply-To: <1264773760.19.0.248393154087.issue7805@psf.upfronthosting.co.za>
Message-ID: <1265039450.49.0.672707415139.issue7805@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Feb  1 16:51:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 01 Feb 2010 15:51:43 +0000
Subject: [issue6906] Tkinter sets an unicode environment variable on win32
In-Reply-To: <1252920566.52.0.249075498328.issue6906@psf.upfronthosting.co.za>
Message-ID: <1265039503.96.0.306540689567.issue6906@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Windows
keywords: +needs review
nosy: +brian.curtin
priority:  -> normal
stage:  -> test needed
type:  -> behavior

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

From report at bugs.python.org  Mon Feb  1 17:12:15 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 01 Feb 2010 16:12:15 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1263162456.08.0.552290394242.issue1943@psf.upfronthosting.co.za>
Message-ID: <4B66FD58.5060600@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
>> Base type Unicode buffers end with a null-Py_UNICODE termination,
>> but this is not used anywhere, AFAIK
> On Windows, code like 
>    CreateDirectoryW(PyUnicode_AS_UNICODE(po), NULL)
> is very common, at least in posixmodule.c.

The above usage is clearly wrong. PyUnicode_AS_UNICODE() should
only be used to access Py_UNICODE data directly when
working on Python Unicode objects. The macro is not meant
to be used directly in external APIs.

For such uses, the Unicode conversion APIs need to be used,
e.g. the PyUnicode_AsWideChar() API. These will then also
apply any 0-termination as necessary.

Note that Python is free to change the meaning of Py_UNICODE
(e.g. to use UCS4 on all platforms) or Unicode implementation
details (such as e.g. the 0-termination) and this would then break
any use such as the one you quoted.

----------

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

From report at bugs.python.org  Mon Feb  1 17:14:24 2010
From: report at bugs.python.org (=?utf-8?q?Matthieu_Labb=C3=A9?=)
Date: Mon, 01 Feb 2010 16:14:24 +0000
Subject: [issue3872] Python 2.6rc2: Tix ComboBox error
In-Reply-To: <1221463837.04.0.987007832734.issue3872@psf.upfronthosting.co.za>
Message-ID: <1265040864.8.0.110498920723.issue3872@psf.upfronthosting.co.za>


Changes by Matthieu Labb? <bugs.python.org at mattlabbe.com>:


----------
nosy: +matthieu.labbe

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

From report at bugs.python.org  Mon Feb  1 18:27:27 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 01 Feb 2010 17:27:27 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1265045247.55.0.576410913095.issue1943@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Then there are many places to change, in core python as well as in third-party code. And PyArg_ParseTuple("u") would not work any more.

----------

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

From report at bugs.python.org  Mon Feb  1 18:38:30 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Feb 2010 17:38:30 +0000
Subject: [issue7749] pydoc error - "No module named tempfile"
In-Reply-To: <1264109004.41.0.90622697266.issue7749@psf.upfronthosting.co.za>
Message-ID: <1265045910.75.0.607356066686.issue7749@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Just FYI, it was backported to 2.6 in r76313.

----------

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

From report at bugs.python.org  Mon Feb  1 18:51:24 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 01 Feb 2010 17:51:24 +0000
Subject: [issue7798] document pydoc methods
In-Reply-To: <1264692401.66.0.0955816094505.issue7798@psf.upfronthosting.co.za>
Message-ID: <1265046684.19.0.349196552814.issue7798@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I won't mind against the pager module in the main library.

----------

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

From report at bugs.python.org  Mon Feb  1 18:55:05 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 01 Feb 2010 17:55:05 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1265046905.95.0.606077927564.issue1943@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Note that Python is free to change the meaning of Py_UNICODE
> (e.g. to use UCS4 on all platforms)

Python-UCS4 has never worked on Windows. Most developers on Windows, taking example on core python source code, implicitly assumed that HAVE_USABLE_WCHAR_T is true, and use the Py_Unicode* api the same way they use the PyString* functions.

PyString_AsString is documented to return a nul-terminated array. If PyUnicode_AsUnicode starts to behave differently, people will have more trouble to port their modules to py3k.
This is not an implementation detail.

----------

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

From report at bugs.python.org  Mon Feb  1 19:24:23 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Mon, 01 Feb 2010 18:24:23 +0000
Subject: [issue6939] shadows around the io truncate() semantics
In-Reply-To: <1253280113.21.0.651669029601.issue6939@psf.upfronthosting.co.za>
Message-ID: <1265048663.46.0.88013014125.issue6939@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Argh, I had indeed missed some IO-related tests, hadn't noticed the new test_io docstring:
# Tests of io are scattered over the test suite:
# * test_bufio - tests file buffering
# * test_memoryio - tests BytesIO and StringIO
# * test_fileio - tests FileIO
# * test_file - tests the file interface
# * test_io - tests everything else in the io module
# * test_univnewlines - tests universal newline support
# * test_largefile - tests operations on a file greater than 2**32 bytes
#     (only enabled with -ulargefile)

Thanks for the commits B-)

----------

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

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: [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:09:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 01 Feb 2010 19:09:25 +0000
Subject: [issue4331] Can't use _functools.partial() created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1265051365.09.0.494147645706.issue4331@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Please see issue7830 for a related patch.

----------

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

From report at bugs.python.org  Mon Feb  1 20:21:44 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 01 Feb 2010 19:21:44 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1265046905.95.0.606077927564.issue1943@psf.upfronthosting.co.za>
Message-ID: <4B6729C4.7010002@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

modules to py3k.
> This is not an implementation detail.

It is, otherwise I would have documented it. The fact that some
developers are not using those APIs correctly doesn't change that.

Note that PyUnicode_AsUnicode() only returns a pointer to the
Py_UNICODE buffer. It makes no guarantees on the 0-termination.
Developers need to use PyUnicode_GetSize() to access the size
of the Unicode string.

But no worries: We're not going to change it. It's too late
after 10 years in the wild.

Still, developers will have to be aware of the fact that 0-termination
is not a guaranteed Unicode feature and should stop making that
assumption and it will not necessarily hold or be guaranteed
for Unicode subclasses.

----------

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

From report at bugs.python.org  Mon Feb  1 20:29:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Feb 2010 19:29:00 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <4B6729C4.7010002@egenix.com>
Message-ID: <1265052615.3326.16.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le lundi 01 f?vrier 2010 ? 19:21 +0000, Marc-Andre Lemburg a ?crit :
> > This is not an implementation detail.
> 
> It is, otherwise I would have documented it.

Ok, so the current allocation scheme of unicode objects is an
implementation detail as well, right?

----------

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

From report at bugs.python.org  Mon Feb  1 20:42:43 2010
From: report at bugs.python.org (Sijin Joseph)
Date: Mon, 01 Feb 2010 19:42:43 +0000
Subject: [issue7806] httplib.HTTPConnection.getresponse closes socket which
	destroys the response
In-Reply-To: <1264777311.04.0.988942468984.issue7806@psf.upfronthosting.co.za>
Message-ID: <1265053363.14.0.67141304999.issue7806@psf.upfronthosting.co.za>


Sijin Joseph <sijinjoseph at gmail.com> added the comment:

Looking at the code in httplib it seems that response.will_close is set under the following circumstances,

1. HTTP version is 0.9
2. HTTP response header connection is set to close
3. Non-chunked content with a length of zero

This suggests that the underlying socket closure is valid under the conditions and that a subsequent response.read() should not be returning  any content.

If you think this is still an issue, I'd suggest that you create a small example client/server script that

Client:
1. Opens a HTTP connection
2. Continues to read data from it and dumps it to the console.

Server:
1. Setup a script that does not close incoming HTTP connection requests and continues to keep sending data back to the client.

----------
nosy: +sijinjoseph

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

From report at bugs.python.org  Mon Feb  1 20:44:36 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Mon, 01 Feb 2010 19:44:36 +0000
Subject: [issue7813] Bug in command-line module launcher
In-Reply-To: <1264867154.39.0.207369600825.issue7813@psf.upfronthosting.co.za>
Message-ID: <1265053476.25.0.392712258464.issue7813@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Here is the patch you mentionned, it fixes my problem and seems unharmful indeed.

The little problem is, I've not found related tests (test_pkgutil doesn't deal with the importer part) to ad little checks around compile().

Is that patch worth commiting anyway ?

----------
keywords: +patch
Added file: http://bugs.python.org/file16084/py26_pkgutil_compile.patch

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

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: [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 20:54:52 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Mon, 01 Feb 2010 19:54:52 +0000
Subject: [issue7640] buffered io seek() buggy
In-Reply-To: <1262720290.8.0.413817675363.issue7640@psf.upfronthosting.co.za>
Message-ID: <1265054092.22.0.252917905866.issue7640@psf.upfronthosting.co.za>


Changes by Pascal Chambon <chambon.pascal at gmail.com>:


Removed file: http://bugs.python.org/file15759/seek_cur_buffers_py26.patch

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

From report at bugs.python.org  Mon Feb  1 20:57:22 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Mon, 01 Feb 2010 19:57:22 +0000
Subject: [issue7640] buffered io seek() buggy
In-Reply-To: <1262720290.8.0.413817675363.issue7640@psf.upfronthosting.co.za>
Message-ID: <1265054242.59.0.272680751041.issue7640@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

BufferedRandom's seek() is still borken in the latest svn revision of python2.6 (I haven't checked python2.7 yet), so here is a new, smaller patch, tested with the 6 IO-related test suites this time, on win32 and linux.

----------

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

From report at bugs.python.org  Mon Feb  1 20:58:10 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Mon, 01 Feb 2010 19:58:10 +0000
Subject: [issue7640] buffered io seek() buggy
In-Reply-To: <1262720290.8.0.413817675363.issue7640@psf.upfronthosting.co.za>
Message-ID: <1265054290.93.0.134719156446.issue7640@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

The patch itself...

----------
Added file: http://bugs.python.org/file16085/Py26_relative_seek.patch

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

From report at bugs.python.org  Mon Feb  1 21:00:44 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 01 Feb 2010 20:00:44 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265054444.9.0.0360346553.issue6760@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The note starts out "Do not (do x) unless you're not (doing y)". This is confusing. I believe this means "If you are (doing y), you may (do x)". If so, please write it so. If not, please write what you do mean.

After thinking about it, "Only (do x) if you are (doing y)" might be a better rewrite. Or "You may (do x) only if you are (doing y)"

Change "be mindful of escaping" to the more direct "escape". Perhaps give a list of possible special characters.

I agree that this seems a bit verbose for reference documentation. Perhaps there should be a separate PyWiki entry or HowTo doc. That could, for instance, list the special characters for various shells if they are not all the same.

----------
nosy: +tjreedy

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

From report at bugs.python.org  Mon Feb  1 21:03:30 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 01 Feb 2010 20:03:30 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265054610.49.0.217073769421.issue6760@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

PS. I only looked at the style of the patch. Once that is clearer, someone who knows more than me needs to review it for content correctness.

----------

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

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


Florent Xicluna <laxyf at yahoo.fr> added the comment:

As a replacement, it could be useful to propose a "universal key" for sort() method and sorted() builtin.

>>> lst = sorted([{2: '3'}, 1, '05'], key=list.ukey)
>>> 


There's a reference implementation in the pprint._safe_key private class.

----------

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

From report at bugs.python.org  Mon Feb  1 21:30:08 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 01 Feb 2010 20:30:08 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1265056208.38.0.309411846342.issue1943@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>It is, otherwise I would have documented it. The fact that some
developers are not using those APIs correctly doesn't change that.

If, as Antoine claimed, 'it' is a documented feature of str strings, and Py3 says str = Unicode, it is a plausible inference.

----------

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

From report at bugs.python.org  Mon Feb  1 21:46:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Feb 2010 20:46:28 +0000
Subject: [issue3058] Let SimpleXMLRPCServer pass client_address to called
	functions.
In-Reply-To: <1212855971.92.0.424447915547.issue3058@psf.upfronthosting.co.za>
Message-ID: <1265057188.83.0.684100386803.issue3058@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

client_address is not interresting, but I prefer the handler object (SimpleXMLRPCRequestHandler instance). The handler contains more information:
 * handler.address_string() gives the FQDN
 * handler.connection.getpeername() gives the client address
 * handler.connection.getsockanem() gives the server address, useful is the server is listening to multiple addresses
 * etc.

If the server uses SSL, it would be possible to get more information about SSL from handler(.connection).

Your patch breaks the API for all (service) callbacks. Add an option to register_function() would allow a smoother transition (don't break API): you don't have to inherit from a new class. Eg. server.register_function(whoami, with_handler=True).

----------
nosy: +haypo

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

From report at bugs.python.org  Mon Feb  1 21:47:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Feb 2010 20:47:22 +0000
Subject: [issue3058] Let SimpleXMLRPCServer pass client_address to called
	functions.
In-Reply-To: <1212855971.92.0.424447915547.issue3058@psf.upfronthosting.co.za>
Message-ID: <1265057242.54.0.84361577532.issue3058@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops, I mean "client_address is interresting, but ..."

----------

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

From report at bugs.python.org  Mon Feb  1 21:52:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Feb 2010 20:52:16 +0000
Subject: [issue3058] Let SimpleXMLRPCServer pass client_address to called
	functions.
In-Reply-To: <1212855971.92.0.424447915547.issue3058@psf.upfronthosting.co.za>
Message-ID: <1265057536.38.0.191349442379.issue3058@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oops oops oops, samwyse wrote exactly the same idea than me in the first comment!

----------

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

From report at bugs.python.org  Mon Feb  1 22:11:45 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 01 Feb 2010 21:11:45 +0000
Subject: [issue7831] cmp() is missing in 3.x
In-Reply-To: <1265053663.2.0.424350297065.issue7831@psf.upfronthosting.co.za>
Message-ID: <1265058705.12.0.0442274467024.issue7831@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

No, cmp is not missing. It's intentionally removed, and won't come back. So closing this as "won't fix".

I'm not sure what you are aiming at with the universal key function; if you want a key function that guarantees a total order, use key=id.

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

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

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


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Ok.
Maybe we need a "-3" warning and/or a 2to3 fixer?

----------
components: +2to3 (2.x to 3.0 conversion tool)
versions: +Python 2.6, Python 2.7

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

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


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
versions:  -Python 2.6

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

From report at bugs.python.org  Mon Feb  1 22:43:35 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 01 Feb 2010 21:43:35 +0000
Subject: [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 22:45:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Feb 2010 21:45:02 +0000
Subject: [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: <1265060702.69.0.971250583648.issue7832@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Merwok

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

From report at bugs.python.org  Mon Feb  1 22:46:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Feb 2010 21:46:02 +0000
Subject: [issue7831] cmp() is missing in 3.x
In-Reply-To: <1265053663.2.0.424350297065.issue7831@psf.upfronthosting.co.za>
Message-ID: <1265060762.87.0.378798622673.issue7831@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Merwok

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

From report at bugs.python.org  Mon Feb  1 22:54:31 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 01 Feb 2010 21:54:31 +0000
Subject: [issue7831] cmp() is missing in 3.x
In-Reply-To: <1265053663.2.0.424350297065.issue7831@psf.upfronthosting.co.za>
Message-ID: <1265061271.66.0.154653590306.issue7831@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think this should be discussed on python-dev (I believe it *has* been discussed on python-dev, I just don't remember the outcome). Creating fixers is not feasible, I think. In any case, it's an issue different from the one you reported.

----------

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

From report at bugs.python.org  Mon Feb  1 23:12:54 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Mon, 01 Feb 2010 22:12:54 +0000
Subject: [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  Mon Feb  1 23:23:07 2010
From: report at bugs.python.org (Robert Buchholz)
Date: Mon, 01 Feb 2010 22:23:07 +0000
Subject: [issue7806] httplib.HTTPConnection.getresponse closes socket which
	destroys the response
In-Reply-To: <1264777311.04.0.988942468984.issue7806@psf.upfronthosting.co.za>
Message-ID: <1265062987.89.0.571102322477.issue7806@psf.upfronthosting.co.za>


Robert Buchholz <rbu at freitagsrunde.org> added the comment:

An example cannot be constructed using the standard python socket class. As you point out, the response.will_close attribute is set correctly: The client is supposed to close to connect after completion of the request (as does the server). However, when the HTTPConnection object calls close() on the socket, reading the request is not completed -- the request object merely created a file-like object representing the socket.

The reason why this is not an issue is that the Python socket library does reference counting to determine when to close a socket object. When the HTTPConnection calls close(), its own socket object is destroyed and unreferenced. However, the file-like object in the HTTPResponse still has a copy of the socket.

In alternative socket implementations (like Paramiko SOCKS-proxied sockets), this poses a problem: When the socket user calls close(), they actually close the socket -- as the original socket API documentation describes:

    close()
    Close the socket.  It cannot be used after this call.

    makefile([mode[, bufsize]]) -> file object
    Return a regular file object corresponding to the socket.  The mode
    and bufsize arguments are as for the built-in open() function.

Consequently, I do not consider this to be a bug in Paramiko and reported it for the httplib. I can present example code using a paramiko tunneled socket (client and server) if you like.

----------

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

From report at bugs.python.org  Mon Feb  1 23:35:57 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 01 Feb 2010 22:35:57 +0000
Subject: [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: <1265063757.28.0.794775343904.issue7833@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This doesn't look right. IIUC, wininst.exe loads python26.dll, which in turn loads pywintypes.dll. So it should be python26.dll which loads the CRT.

IIUC, wininst.exe is linked statically, precisely to avoid a dependency on the CRT assembly.

----------
nosy: +loewis

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

From report at bugs.python.org  Mon Feb  1 23:54:44 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 01 Feb 2010 22:54:44 +0000
Subject: [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: <1265064884.72.0.0869935402531.issue7832@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch which adds method "assertItemsEqual".

However we could reuse the "assertSameElements" name, and replace the current implementation: it is still the alpha stage.

----------
keywords: +patch
Added file: http://bugs.python.org/file16087/issue7832_assertItemsEqual.diff

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

From report at bugs.python.org  Tue Feb  2 00:45:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Feb 2010 23:45:27 +0000
Subject: [issue7830] Flatten nested functools.partial
In-Reply-To: <1265051251.66.0.305258896073.issue7830@psf.upfronthosting.co.za>
Message-ID: <1265067927.79.0.739376939268.issue7830@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Flattening should only happen for instances of the exact type. When people create subclasses, there's usually a reason for it.

----------
nosy: +pitrou

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

From report at bugs.python.org  Tue Feb  2 01:02:15 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 02 Feb 2010 00:02:15 +0000
Subject: [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: <1265068935.01.0.999469625002.issue7833@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

The last line of my previous post should actually read 
  python.exe setup.py bdist_wininst

Anyway, here are three files (also attached) that can reproduce the problem:

1) setup.py

from distutils.core import setup, Extension
setup(name='testpyd', scripts = ["testpyd_postinstall.py"],
    ext_modules=[Extension('testpyd', ['testpyd.c'],)],
    options = {"bdist_wininst": {"install_script": 
        "testpyd_postinstall.py", "user_access_control": "auto"},})

2) testpyd.c

#include "Python.h"
PyMethodDef methods[] = {{NULL, NULL},};
void inittestpyd() {(void)Py_InitModule("testpyd", methods);}

3) testpyd_postinstall.py

#!python
import testpyd


Build the installer with python 2.6 and Issue4120 patch applied:
    python setup.py bdist_wininst

Run the installer:
    dist\testpyd-0.0.0.win32-py2.6.exe

The postinstall script fails with:

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

According to Sysinternals process monitor python26.dll is loaded from the system32 directory, the testpyd.pyd extension is found at the right place, and then the Windows path is searched in vain for MSVCR90.DLL.

Tested on Windows 7 Pro 64 bit.

----------
Added file: http://bugs.python.org/file16088/test-bdist_wininst.zip

_______________________________________
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: [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 01:14:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2010 00:14:54 +0000
Subject: [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: <1265069694.59.0.213707532468.issue7834@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Could you produce a patch?

----------
keywords: +easy
nosy: +pitrou
priority:  -> normal
stage:  -> needs patch

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

From report at bugs.python.org  Tue Feb  2 01:30:05 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 02 Feb 2010 00:30:05 +0000
Subject: [issue4772] undesired switch fall-through in socketmodule.c
In-Reply-To: <1230582973.84.0.698923049603.issue4772@psf.upfronthosting.co.za>
Message-ID: <1265070605.4.0.312192246867.issue4772@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file15665/issue4772.diff

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

From report at bugs.python.org  Tue Feb  2 01:33:20 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 02 Feb 2010 00:33:20 +0000
Subject: [issue4772] undesired switch fall-through in socketmodule.c
In-Reply-To: <1230582973.84.0.698923049603.issue4772@psf.upfronthosting.co.za>
Message-ID: <1265070800.03.0.306978607886.issue4772@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Minor change to the patch to correct for Antoine's suggestion.

----------
Added file: http://bugs.python.org/file16089/issue4772.diff

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

From report at bugs.python.org  Tue Feb  2 01:47:08 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 02 Feb 2010 00:47:08 +0000
Subject: [issue4772] undesired switch fall-through in socketmodule.c
In-Reply-To: <1230582973.84.0.698923049603.issue4772@psf.upfronthosting.co.za>
Message-ID: <1265071628.66.0.0741839430758.issue4772@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file16089/issue4772.diff

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

From report at bugs.python.org  Tue Feb  2 01:47:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 02 Feb 2010 00:47:43 +0000
Subject: [issue4772] undesired switch fall-through in socketmodule.c
In-Reply-To: <1230582973.84.0.698923049603.issue4772@psf.upfronthosting.co.za>
Message-ID: <1265071663.5.0.328620259944.issue4772@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Added file: http://bugs.python.org/file16090/issue4772.diff

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

From report at bugs.python.org  Tue Feb  2 02:03:09 2010
From: report at bugs.python.org (Jesse Aldridge)
Date: Tue, 02 Feb 2010 01:03:09 +0000
Subject: [issue7835] Minor bug in 2.6.4 related to cleanup at end of program
Message-ID: <1265072589.47.0.177431351508.issue7835@psf.upfronthosting.co.za>


Jesse Aldridge <jessealdridge at gmail.com> added the comment:

I ran into an error while trying to use the shelve module.  Alex Martelli seemed to think I was running into a python bug.  He suggested I file a bug report.  For more info see:  http://stackoverflow.com/questions/2180946/really-weird-issue-with-shelve-python

----------

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

From report at bugs.python.org  Tue Feb  2 02:49:42 2010
From: report at bugs.python.org (Meador Inge)
Date: Tue, 02 Feb 2010 01:49:42 +0000
Subject: [issue7266] test_lib2to3 failure under Windows
In-Reply-To: <1257433591.14.0.555852020916.issue7266@psf.upfronthosting.co.za>
Message-ID: <1265075382.45.0.334358503505.issue7266@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

This looks to be fixed now [1].  The log shows 'test_lib2to3' passing.

BTW, why do we run through Cygwin?  I think to test on Windows as most Windows developers do things we need to use the native cmd.exe shell.

[1] http://www.python.org/dev/buildbot/builders/x86%20XP-4%20trunk/builds/2931/steps/test/logs/stdio

----------
nosy: +minge

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

From report at bugs.python.org  Tue Feb  2 03:04:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 02 Feb 2010 02:04:20 +0000
Subject: [issue7830] Flatten nested functools.partial
In-Reply-To: <1265051251.66.0.305258896073.issue7830@psf.upfronthosting.co.za>
Message-ID: <1265076260.18.0.382754844239.issue7830@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Antoine> Flattening should only happen for instances of the exact type.

I am attaching a variant of the patch that will only flatten if both nested and wrapping partial is of the exact type. Other possibilities would include flattening partial_subtype(f, ...) if type(f) == partial and if type(f) == partial_subtype, but I'll present only the least and most conservative variants.

Antoine> When people create subclasses [of partial type], there's usually a reason for it.

It is hard not to agree with this thesis, but I don't see how it follows that subclass writers will not benefit from flattening their instances.  Can you suggest a use case where flattening in functools.partial subtype would be undesirable?

----------
Added file: http://bugs.python.org/file16091/no-nested-partial-exact.diff

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

From report at bugs.python.org  Tue Feb  2 03:46:31 2010
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 02 Feb 2010 02:46:31 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265078791.73.0.762407833087.issue6760@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Working on a more concise new draft...

----------

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

From report at bugs.python.org  Tue Feb  2 03:52:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Feb 2010 02:52:08 +0000
Subject: [issue7835] Minor bug in 2.6.4 related to cleanup at end of program
Message-ID: <1265079128.93.0.324362521986.issue7835@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here's a patch that fixes the problem for shelve.  For the more general problem with Python shutdown and module cleanup, see issue 812369.

I can come up with a sort-of unit test for this (setting _ClosedDict to None, calling close to prove it doesn't generate an error, and restoring _CloseDict), but it is rather artificial, since the real bug involves __del__ getting called during shutdown after module finalization.  So I'm not sure the unit test is worthwhile.

----------
keywords: +easy, patch
nosy: +r.david.murray
priority:  -> normal
stage:  -> patch review
versions: +Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file16092/shelve-clean-shutdown.patch

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

From report at bugs.python.org  Tue Feb  2 04:04:25 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 02 Feb 2010 03:04:25 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
Message-ID: <1265079865.79.0.758165630053.issue1578269@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I haven't yet had a chance to look into what caused the failures, but test_tarfile did not pass. This is on Windows 7 x64.


======================================================================
ERROR: test_extract_hardlink (__main__.MiscReadTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "lib\test\test_tarfile.py", line 295, in test_extract_hardlink
    data = open(os.path.join(TEMPDIR, "ustar/symtype"), "rb").read()
IOError: [Errno 2] No such file or directory: 'd:\\python-dev\\py3k\\@test_2972_
tmp\\ustar/symtype'

======================================================================
ERROR: test_extract_hardlink (__main__.GzipMiscReadTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "lib\test\test_tarfile.py", line 295, in test_extract_hardlink
    data = open(os.path.join(TEMPDIR, "ustar/symtype"), "rb").read()
IOError: [Errno 2] No such file or directory: 'd:\\python-dev\\py3k\\@test_2972_
tmp\\ustar/symtype'

----------

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

From report at bugs.python.org  Tue Feb  2 04:47:29 2010
From: report at bugs.python.org (Reid Kleckner)
Date: Tue, 02 Feb 2010 03:47:29 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1238701276.41.0.515283298202.issue5673@psf.upfronthosting.co.za>
Message-ID: <1265082449.69.0.261022562821.issue5673@psf.upfronthosting.co.za>


Reid Kleckner <rnk at mit.edu> added the comment:

> - why do you say Thread.join() uses a busy loop? is it because it uses
>   Condition.wait()? If so, this will be solved in py3k by issue7316 (which you
>   are welcome to review). Otherwise, I think there should be an upper bound on
>   the sleeping granularity (say 2 seconds).

Yes, that's what I was referring to.  I'm glad to hear the situation will
improve in the future!

> - the "if 'timeout' in kwargs" dance is a bit complicated. Why not simply
>   "kwargs.pop('timeout', None)"?

Good call, done.

> - if it times out, communicate() should raise a specific exception. Bonus points
>   if the exception holds the partial output as attributes (that's what we do for
>   non-blocking IO in py3k), but if it's too difficult we can leave that out. I
>   don't think returning None would be very good.

I agree.  Does subprocess.TimeoutExpired sound good?

It won't be possible with the current implementation to put the partial output
in the exception, because read blocks.  For example, in the Windows threaded
implementation, there's a background thread that just calls self.stdout.read(),
which blocks until its finished.

> - for consistency, other methods should probably raise the same exception. I
>   think we can leave out the more complex scenarios such as "timing out but
>   still processing the beginning of the output".

What do you mean still processing?  I agree, they should all throw the same
exception.  I think call and check_call should clean up after themselves by
killing the child processes they create, while communicate and wait should leave
that to the user.

I'm imagining something like this for communicate:

try:
    (stdout, stderr) = p.communicate(timeout=123)
except subprocess.TimeoutExpired:
    p.kill()
    (stdout, stderr) = p.communicate()  # Should not block long

And nothing special for check_call(cmd=[...], timeout=123).

----------
Added file: http://bugs.python.org/file16093/subprocess-timeout.patch

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

From report at bugs.python.org  Tue Feb  2 05:04:46 2010
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 02 Feb 2010 04:04:46 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265083486.87.0.225800217931.issue6760@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Okay; new, hopefully better, draft. Feedback?

----------
versions:  -Python 3.1
Added file: http://bugs.python.org/file16094/subprocess.rst.patch

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

From report at bugs.python.org  Tue Feb  2 05:06:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 02 Feb 2010 04:06:43 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and	os.path.islink()
	support for Windows
Message-ID: <1265083603.77.0.330667072003.issue1578269@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Most of the guts have already been reviewed, but here are some mainly minor comments on the last patch.

Lib/test/symlink_support.py
- No need to import print_function
- I'd just put the docstrings on one line
- A bunch of if tests are one-lined

Lib/test/test_win_symlink.py
- getwindowsversion now returns named members, so you can just use getwindowsversion().major for example, rather than the tuple.
- Rather than check the Windows version in the setUp, I think it would be cleaner to use the unittest.skipIf decorator on the entire WindowsSymlinkTest class.
- You might want to stack skip decorators to first skip outright if it's not Windows, and then skip if it's not Win 6 or greater -- it gets you out of checking if getwindowsversion actually exists.
- test_remove_directory_link_to_missing_target has some commented out code.

Lib/test/test_posixpath.py
- Lines 365-366 - why check has_symlink() and immediately check it again?

Modules/posixmodule.c
- Line 2740 - "//*** todo: fix this"
- C++ style comments in a few other places (nit picky, I know)
- Line 5117 - win_symlink__doc__ is double spaced and contains an extra slash at line 5121. For consistency it should probably just be single spaced.

----------

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

From report at bugs.python.org  Tue Feb  2 05:17:41 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 02 Feb 2010 04:17:41 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265084261.87.0.373578591298.issue6760@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The raw_input() doesn't provide anything. I'd just drop that and pass the string directly to shlex.split.

"Do not put an argument-taking option together with its argument as a single item in the *args* list"
-- Something like "Argument-taking options should not be grouped with their arguments in the *args* list." may be a cleaner read, and avoids the big scary "do not".

"Because that is incorrect"
-- Maybe something like "shlex.split would suggest the following" instead?

----------
keywords: +needs review
nosy: +brian.curtin
stage:  -> patch review

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

From report at bugs.python.org  Tue Feb  2 05:20:58 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 02 Feb 2010 04:20:58 +0000
Subject: [issue7316] Add a timeout functionality to common locking operations
In-Reply-To: <1258133508.5.0.728130823639.issue7316@psf.upfronthosting.co.za>
Message-ID: <1265084458.78.0.260929560076.issue7316@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

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

From report at bugs.python.org  Tue Feb  2 05:23:36 2010
From: report at bugs.python.org (Meador Inge)
Date: Tue, 02 Feb 2010 04:23:36 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1265084616.11.0.00986779171889.issue5211@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Mark,

Is this still of interest?

I found the relevant changes in py3k, but I am not sure it is the behavior that gumtree is expecting.  Since py3k removes coercion completely, the test case from issue 3734 would just issue:

   Traceback (most recent call last):
     File "test-5211.py", line 34, in <module>
       print type(z + xz)
     File "test-5211.py", line 5, in __coerce__
       t = complex.__coerce__(self,other)
   AttributeError: type object 'complex' has no attribute '__coerce__'

Where as I think gumtree wants the xcomplex case to behave as the xfloat case, e.g.
   <class '__main__.xfloat'>
   <class '__main__.xcomplex'>
Since coercion is getting axed in py3k, I don't think it makes sense to provide this behavior.

On the other hand, as you mentioned, the removal of coercion from complex could be backported.  However, if we are going to do that then we might as well just backport the whole removal of coercion instead of just the bits from 'complexobject.c'.  Bascially checkins r51431 and r58226.

----------
nosy: +minge

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

From report at bugs.python.org  Tue Feb  2 05:23:50 2010
From: report at bugs.python.org (Chuck Rhode)
Date: Tue, 02 Feb 2010 04:23:50 +0000
Subject: [issue6978] compiler.transformer dict key bug d[1,] = 1
In-Reply-To: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za>
Message-ID: <1265084630.47.0.965397655808.issue6978@psf.upfronthosting.co.za>


Chuck Rhode <CRhode at LacusVeris.com> added the comment:

Here are four ways to generate things called in the documentation Abstract Syntax Trees (ASTs).  Obviously they are not all the same kind of object:

#!/usr/local/bin/python2.6

import sys
import compiler
import parser
import ast

STATEMENT = 'd[1,] = 2'

print 'level %s' % sys.version
print compiler.parse(STATEMENT)
print parser.suite(STATEMENT).tolist()
print ast.dump(
    compile(STATEMENT, '<string>', 'exec', ast.PyCF_ONLY_AST),
    annotate_fields=False,
    include_attributes=False,
    )
print ast.dump(
    ast.parse(STATEMENT),
    annotate_fields=False,
    include_attributes=False,
    )

# Fin

Here are the results:

>>> level 2.6.2 (r262:71600, Jun 29 2009, 08:08:18) 
[GCC 4.3.2]
>>> Module(None, Stmt([Assign([Subscript(Name('d'), 'OP_ASSIGN', [Const(1)])], Const(2))]))
>>> [257, [267, [268, [269, [270, [327, [304, [305, [306, [307, [308, [310, [311, [312, [313, [314, [315, [316, [317, [318, [1, 'd']], [322, [9, '['], [323, [324, [304, [305, [306, [307, [308, [310, [311, [312, [313, [314, [315, [316, [317, [318, [2, '1']]]]]]]]]]]]]]]], [12, ',']], [10, ']']]]]]]]]]]]]]]]], [22, '='], [327, [304, [305, [306, [307, [308, [310, [311, [312, [313, [314, [315, [316, [317, [318, [2, '2']]]]]]]]]]]]]]]]]], [4, '']]], [0, '']]
>>> Module([Assign([Subscript(Name('d', Load()), Index(Tuple([Num(1)], Load())), Store())], Num(2))])
>>> Module([Assign([Subscript(Name('d', Load()), Index(Tuple([Num(1)], Load())), Store())], Num(2))])

To me the *compiler* module has vestigial utility.  It would be nice if it returned correct results.

----------

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

From report at bugs.python.org  Tue Feb  2 05:55:29 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Feb 2010 04:55:29 +0000
Subject: [issue6978] compiler.transformer dict key bug d[1,] = 1
In-Reply-To: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za>
Message-ID: <1265086529.43.0.608578646304.issue6978@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I don't see why the compiler module is any better than any of the other ways that produce reasonable AST.

----------

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

From report at bugs.python.org  Tue Feb  2 06:06:30 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 02 Feb 2010 05:06:30 +0000
Subject: [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: <1265087190.49.0.953728960196.issue7832@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I like that this patch adds a new method with the different behavior.  They are both distinct and desirable behaviors.  The existing behavior has already been shipped in Python 3.1 so it should not change.  Also it is already in use via the http://code.google.com/p/python-unittest-backport/ project.

Also, I would put the assertItemEquals unit tests in their own method instead of at the end of the existing one.

----------
assignee:  -> gregory.p.smith

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

From report at bugs.python.org  Tue Feb  2 06:07:45 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 02 Feb 2010 05:07:45 +0000
Subject: [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: <1265087265.25.0.0315863933203.issue7832@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +michael.foord

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

From report at bugs.python.org  Tue Feb  2 06:08:20 2010
From: report at bugs.python.org (Chuck Rhode)
Date: Tue, 02 Feb 2010 05:08:20 +0000
Subject: [issue6978] compiler.transformer dict key bug d[1,] = 1
In-Reply-To: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za>
Message-ID: <1265087300.3.0.547369557602.issue6978@psf.upfronthosting.co.za>


Chuck Rhode <CRhode at LacusVeris.com> added the comment:

> I don't see why the compiler module is any better than any of the other 
> ways that produce reasonable AST.

It is available on Python releases older than 2.6?

----------

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

From report at bugs.python.org  Tue Feb  2 06:53:20 2010
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 02 Feb 2010 05:53:20 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265090000.28.0.36910941727.issue6760@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Gonna have to disagree about the raw_input(), because the escaping involved would complicate the example and could be distracting/confusing.
Rest of Brian's suggestions taken into account.

----------
Added file: http://bugs.python.org/file16095/subprocess.rst.patch

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

From report at bugs.python.org  Tue Feb  2 06:53:49 2010
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 02 Feb 2010 05:53:49 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265090029.31.0.21481774035.issue6760@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


Removed file: http://bugs.python.org/file14770/subprocess.rst.patch

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

From report at bugs.python.org  Tue Feb  2 06:54:26 2010
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 02 Feb 2010 05:54:26 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265090066.36.0.859917256576.issue6760@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


Removed file: http://bugs.python.org/file16094/subprocess.rst.patch

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

From report at bugs.python.org  Tue Feb  2 07:01:21 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 02 Feb 2010 06:01:21 +0000
Subject: [issue1683368] object.__init__ shouldn't allow args/kwds
Message-ID: <1265090481.03.0.381277947751.issue1683368@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

FYI - A discussion on why this change may have been a bad idea and breaks peoples existing code:

 http://freshfoo.com/blog/object__init__takes_no_parameters

----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Tue Feb  2 07:21:27 2010
From: report at bugs.python.org (Kees Bos)
Date: Tue, 02 Feb 2010 06:21:27 +0000
Subject: [issue6978] compiler.transformer dict key bug d[1,] = 1
In-Reply-To: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za>
Message-ID: <1265091687.84.0.82973932621.issue6978@psf.upfronthosting.co.za>


Kees Bos <k.bos at zx.nl> added the comment:

It's available at least since 2.4.

We're using it in Pyjamas (pyjs.org) to generate javascript code from python code.

If there are better ways to produce python asts, I'd be happy to know that.

----------

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

From report at bugs.python.org  Tue Feb  2 07:35:44 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Feb 2010 06:35:44 +0000
Subject: [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: <1265092544.71.0.0721177790958.issue7832@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Just out of curiosity, what are the use cases for assertSameElements? If one has two objects, doesn't care about the order and the duplicates then these two objects are most likely sets and assertSetEqual can be used instead.
OTOH checking if two sequences have the same elements regardless of their order seems more common, and I don't see any method that does it (I was expecting assertSameElements to do that).

I would be -0 to add another method -- the API is already too confusing IMHO (is not so easy to remember if it's assertSameList, assertSameLists, assertListEqual, assertListsEqual; also note the 'assertItemsEqual' in msg98697, 'assertItemEquals' in msg98717).
Maybe a check_order arg in assertSequenceEqual (or was it assertSameSequence? ;) would be better, or at least more explicit.

----------
stage:  -> needs patch

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

From report at bugs.python.org  Tue Feb  2 10:04:16 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 02 Feb 2010 09:04:16 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1265101456.26.0.0770377359898.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16043/issue7092_bsddb3.diff

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

From report at bugs.python.org  Tue Feb  2 10:04:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 02 Feb 2010 09:04:20 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1265101460.4.0.728602355264.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16065/issue7092_bsddb3v2.diff

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

From report at bugs.python.org  Tue Feb  2 10:06:08 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Feb 2010 09:06:08 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1265101568.22.0.458669296344.issue7092@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

bsddb is now fixed in r77910.

----------

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

From report at bugs.python.org  Tue Feb  2 10:19:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 02 Feb 2010 09:19:20 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1265102360.44.0.0534296362683.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Proposed patch to filter out some deprecated comparisons in "unittest" module.

----------
Added file: http://bugs.python.org/file16096/issue7092_unittest.py

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

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: [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 10:57:49 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Feb 2010 09:57:49 +0000
Subject: [issue7831] cmp() is missing in 3.x
In-Reply-To: <1265053663.2.0.424350297065.issue7831@psf.upfronthosting.co.za>
Message-ID: <1265104669.54.0.483152581686.issue7831@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

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: [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 13:12:19 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 02 Feb 2010 12:12:19 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
In-Reply-To: <1265083603.77.0.330667072003.issue1578269@psf.upfronthosting.co.za>
Message-ID: <D67B8A86984F00488D0776065BA56DBD882237DEED@Teach.jaraco.com>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Brian, thanks for the review. I really appreciate it. I'll fix all of the identified issues.

> Lib/test/test_posixpath.py
> - Lines 365-366 - why check has_symlink() and immediately check it
> again?

In the unpatched code, there were two calls that checked for the existence of 'symlink' in the os module. I thought it strange too, but left it assuming it was there for some reason and not wanting to over extend beyond my primary objective. I will rewrite that test to use only one check unless someone posts otherwise.

----------
title: Add os.link() and os.symlink() and	os.path.islink() support for Windows -> Add os.link() and os.symlink() and os.path.islink()	support for Windows

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

From report at bugs.python.org  Tue Feb  2 13:55:30 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 02 Feb 2010 12:55:30 +0000
Subject: [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: <1265115330.73.0.37381979234.issue7832@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Damn. If assertSameElements has already shipped with the existing implementation then we can't change it. The documentation really needs clarifying to make it clear that it ignores duplicates.

I would be happy with a 'check_order' argument to assertSequenceEqual defaulting to True, and slightly prefer that to a new method.

FWIW the http://code.google.com/p/python-unittest-backport/ project is quite out of date. I am intending to do my own port (before PyCon) that subclasses unittest so that it can interoperate with code using the Python 2.4-2.6 standard library unittest. I may get in touch with the project owner to see if I can join him on his project.

----------

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

From report at bugs.python.org  Tue Feb  2 13:58:03 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 02 Feb 2010 12:58:03 +0000
Subject: [issue7837] assertSameElements doesn't filter enough py3k warnings
In-Reply-To: <1265106776.19.0.232903733304.issue7837@psf.upfronthosting.co.za>
Message-ID: <1265115483.33.0.110104326583.issue7837@psf.upfronthosting.co.za>


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


----------
assignee:  -> ezio.melotti

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

From report at bugs.python.org  Tue Feb  2 14:03:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2010 13:03:24 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265115804.86.0.991864524832.issue6760@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I still think this is much too verbose. The second note looks redundant with the first one and the third one.
Remember, the notes you are adding may be useful, but they'll also make reading the whole page more tedious.

----------

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

From report at bugs.python.org  Tue Feb  2 14:08:33 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 02 Feb 2010 13:08:33 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1265116113.86.0.422250128694.issue1578269@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

- When run with patch 20 as non-admin on Windows 7, I get the same test_tarfile errors that Brian gets. I do not get these errors with an unpatched py3k build.

- When run with patch 20 as an admin on Windows 7, I do not get the errors in test_tarfile. However, I do get errors in test_posixpath that I do not get on an unpatched py3k build:
======================================================================
FAIL: test_realpath_basic (test.test_posixpath.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\opt\cygwin\home\eric\python\py3k\lib\test\test_posixpath.py", line 49
9, in test_realpath_basic
    self.assertEqual(realpath(ABSTFN), ABSTFN+"1")
AssertionError: 'C:\\opt\\cygwin\\home\\eric\\python\\py3k/C:\\opt\\cygwin\\home
\\eric\\python\\py3k/C:\\opt\\cygwin\\home\\eric\\python\\py3k/@test_3404_tmp1'
!= 'C:\\opt\\cygwin\\home\\eric\\python\\py3k/@test_3404_tmp1'

======================================================================
FAIL: test_realpath_resolve_before_normalizing (test.test_posixpath.PosixPathTes
t)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\opt\cygwin\home\eric\python\py3k\lib\test\test_posixpath.py", line 56
0, in test_realpath_resolve_before_normalizing
    self.assertEqual(realpath(ABSTFN + "/link-y/.."), ABSTFN + "/k")
AssertionError: 'C:\\opt\\cygwin\\home\\eric\\python\\py3k/C:\\opt\\cygwin\\home
\\eric\\python\\py3k/@test_3404_tmp/C:\\opt\\cygwin\\home\\eric\\python\\py3k/@t
est_3404_tmp/k' != 'C:\\opt\\cygwin\\home\\eric\\python\\py3k/@test_3404_tmp/k'

======================================================================
FAIL: test_realpath_resolve_first (test.test_posixpath.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\opt\cygwin\home\eric\python\py3k\lib\test\test_posixpath.py", line 58
3, in test_realpath_resolve_first
    self.assertEqual(realpath(base + "link"), ABSTFN)
AssertionError: 'C:\\opt\\cygwin\\home\\eric\\python\\py3k/C:\\opt\\cygwin\\home
\\eric\\python\\py3k/@test_3404_tmp' != 'C:\\opt\\cygwin\\home\\eric\\python\\py
3k/@test_3404_tmp'

======================================================================
FAIL: test_realpath_resolve_parents (test.test_posixpath.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\opt\cygwin\home\eric\python\py3k\lib\test\test_posixpath.py", line 53
7, in test_realpath_resolve_parents
    self.assertEqual(realpath("a"), ABSTFN + "/y/a")
AssertionError: 'C:\\opt\\cygwin\\home\\eric\\python\\py3k\\@test_3404_tmp\\k/a'
 != 'C:\\opt\\cygwin\\home\\eric\\python\\py3k/@test_3404_tmp/y/a'

======================================================================
FAIL: test_realpath_symlink_loops (test.test_posixpath.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\opt\cygwin\home\eric\python\py3k\lib\test\test_posixpath.py", line 50
9, in test_realpath_symlink_loops
    self.assertEqual(realpath(ABSTFN), ABSTFN)
AssertionError: 'C:\\opt\\cygwin\\home\\eric\\python\\py3k/C:\\opt\\cygwin\\home
\\eric\\python\\py3k/C:\\opt\\cygwin\\home\\eric\\python\\py3k/@test_3404_tmp' !
= 'C:\\opt\\cygwin\\home\\eric\\python\\py3k/@test_3404_tmp'

======================================================================
FAIL: test_samefile (test.test_posixpath.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\opt\cygwin\home\eric\python\py3k\lib\test\test_posixpath.py", line 34
3, in test_samefile
    False
  File "C:\opt\cygwin\home\eric\python\py3k\lib\test\test_posixpath.py", line 29
, in assertIs
    self.assertTrue(a is b)
AssertionError: False is not True

======================================================================
FAIL: test_samestat (test.test_posixpath.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\opt\cygwin\home\eric\python\py3k\lib\test\test_posixpath.py", line 38
4, in test_samestat
    False
  File "C:\opt\cygwin\home\eric\python\py3k\lib\test\test_posixpath.py", line 29
, in assertIs
    self.assertTrue(a is b)
AssertionError: False is not True

----------------------------------------------------------------------
Ran 30 tests in 0.201s

FAILED (failures=7)
test test_posixpath failed -- multiple errors occurred
1 test failed:
    test_posixpath

Even though "cygwin" is in the path, I am running these tests from a cmd.exe (or whatever the built-in shell is called these days) shell. I am not running these tests under cygwin bash.

----------

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

From report at bugs.python.org  Tue Feb  2 14:18:22 2010
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 02 Feb 2010 13:18:22 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265116702.85.0.50027375245.issue6760@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Well, the same basic example is used for cohesiveness, but the issue/pitfall being highlighted in each note is distinct. But you have a point about shlex being pointed out twice, so here's a version with that redundancy excised.

----------
Added file: http://bugs.python.org/file16098/subprocess.rst.patch

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

From report at bugs.python.org  Tue Feb  2 14:30:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Feb 2010 13:30:34 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265117434.88.0.497938010243.issue6760@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I like the idea of pointing out that shlex can be used to determine exactly what to pass to subprocess, but I agree that the proposed patch is too wordy (and still too much in a negative voice).

Here is an alternate simpler patch.

Note that while I have also clarified the last sentence in the shell=True case, I think that this is in fact a bug in the Popen API.  As far as I can tell the ability to pass arguments to the shell after the -c is useless, and I think Popen should instead raise a ValueError if passed a sequence when shell is True.  But that is a different bug report....

----------
nosy: +r.david.murray
priority:  -> normal

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

From report at bugs.python.org  Tue Feb  2 14:33:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Feb 2010 13:33:59 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265117639.23.0.858093321463.issue6760@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  Somehow the patch got lost.  Let's try again.

----------
Added file: http://bugs.python.org/file16099/subprocess-doc.patch

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

From report at bugs.python.org  Tue Feb  2 14:37:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Feb 2010 13:37:31 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265117851.29.0.232286005095.issue6760@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file16099/subprocess-doc.patch

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

From report at bugs.python.org  Tue Feb  2 14:38:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Feb 2010 13:38:17 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265117897.84.0.557466920378.issue6760@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Woops, spotted a word I left out.  Fixed.

----------
Added file: http://bugs.python.org/file16100/subprocess-doc.patch

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

From report at bugs.python.org  Tue Feb  2 14:56:06 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 02 Feb 2010 13:56:06 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265118966.56.0.45726451087.issue6760@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

>From David's patch:

   Note in particular that options and their arguments go in separate list
   elements, while arguments that need quoting when used in the shell
   (such as filenames containing spaces or the python command shown
   above) are single list elements.

It's not always true that options and their arguments should be in separate elements. For example:
['/bin/ls', '-l',  '--block-size=1024']
I understand the sentiment, but if we're trying to give guidance that people can follow without understanding the underlying issue, then they should be correct all the time.

Also, the code snippet includes subprocess without using it.

----------
nosy: +eric.smith

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

From report at bugs.python.org  Tue Feb  2 15:01:29 2010
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 02 Feb 2010 14:01:29 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265119289.69.0.697496030522.issue6760@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Counterpatch incorporating R. David Murray's succinctness improvements while retaining correct positioning of the first note, managing to incorporate the 3rd note not present in Mr. Murray's, and including more precise wording to address the problem Eric Smith pointed out.

----------
Added file: http://bugs.python.org/file16101/subprocess.rst.patch

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

From report at bugs.python.org  Tue Feb  2 15:01:37 2010
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 02 Feb 2010 14:01:37 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265119297.3.0.748235103791.issue6760@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


Removed file: http://bugs.python.org/file15033/subprocess.rst.patch

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

From report at bugs.python.org  Tue Feb  2 15:01:49 2010
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 02 Feb 2010 14:01:49 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265119309.37.0.882497904269.issue6760@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


Removed file: http://bugs.python.org/file16095/subprocess.rst.patch

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

From report at bugs.python.org  Tue Feb  2 15:08:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2010 14:08:04 +0000
Subject: [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: <1265119684.62.0.977582826388.issue7827@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There's a patch to make array implement the new buffer API in the following issue, which was closed:
http://bugs.python.org/issue6071
The patch is "hasharray.patch".

----------
nosy: +pitrou

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

From report at bugs.python.org  Tue Feb  2 15:36:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Feb 2010 14:36:28 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265121388.67.0.369503621617.issue6760@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My placement of the note was carefully considered.  It is discussing the shell=False case and IMO belongs after that paragraph.  I understand now your concern about the note I omitted...and again I think this is a bug in the Popen API.  If shell=False, I think Popen should generate an error if args is a string.  Absent that fix, I've reworded the existing sentence along the lines you suggest, but using positive language rather than negative.  I've incorporated your fix for Eric's bug report, but I haven't added in the explicit references to the strings in the example.  IMO those are obvious and don't need repeating, but if others think it is clearer to add them, I'm fine with that.

As for subprocess, IMO there's no need to show the subprocess call.  The shlex result shows the list that would go into the subprocess call, and I think that's sufficient.  What do others think?

I've updated my version of the patch.

----------
versions: +Python 2.7, Python 3.1
Added file: http://bugs.python.org/file16102/subprocess-doc.patch

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

From report at bugs.python.org  Tue Feb  2 15:37:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Feb 2010 14:37:53 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265121473.25.0.792244081109.issue6760@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file16100/subprocess-doc.patch

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

From report at bugs.python.org  Tue Feb  2 15:40:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Feb 2010 14:40:42 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265121642.65.0.855416681185.issue6760@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

By the way, I've been wanting the Popen docs improved for a long time but never got around to it, so thanks for pushing for this.

----------

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

From report at bugs.python.org  Tue Feb  2 15:41:18 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 02 Feb 2010 14:41:18 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1265121678.74.0.271873706089.issue5677@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

An errno+ferror approach works except for two cases:

  (1) MS fgets() does not consider reading from a write-only stream
      an error. While annoying, I think this is standard conforming.

  (2) OpenSolaris sets errno unreliably after getc.


I do not know how to get around those without using OS specifics.

----------
Added file: http://bugs.python.org/file16103/errno-ebadf.patch

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

From report at bugs.python.org  Tue Feb  2 15:41:41 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 02 Feb 2010 14:41:41 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1265121701.6.0.524230344019.issue5677@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file16104/errno-ebadf-tests.patch

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

From report at bugs.python.org  Tue Feb  2 15:51:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2010 14:51:51 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1265121678.74.0.271873706089.issue5677@psf.upfronthosting.co.za>
Message-ID: <1265122389.3343.10.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> An errno+ferror approach works except for two cases:
> 
>   (1) MS fgets() does not consider reading from a write-only stream
>       an error. While annoying, I think this is standard conforming.
> 
>   (2) OpenSolaris sets errno unreliably after getc.
> 
> 
> I do not know how to get around those without using OS specifics.

Ok, then perhaps it's better to have some internal {readable, writable}
flags based on the original mode string.

----------

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

From report at bugs.python.org  Tue Feb  2 15:56:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2010 14:56:18 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265122578.48.0.767464709888.issue6760@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The following sentences look like a distraction to me:

? Additional quoting may be required because the entire string is a Python string.  It may be useful to use a Python raw string in complex cases. ?

It is true of every string literal and is not specific to the subprocess module.

Also, I don't understand what the reference to "-c" is about. subprocess isn't only for executing Python interpreters. Or perhaps you are talking about "sh -c", but it is quite cryptic.

----------

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

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


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

New patch that filters one more warning.

----------
assignee: ezio.melotti -> 
Added file: http://bugs.python.org/file16105/issue7837v2.patch

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

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


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee:  -> ezio.melotti

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

From report at bugs.python.org  Tue Feb  2 16:18:16 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 02 Feb 2010 15:18:16 +0000
Subject: [issue7837] assertSameElements doesn't filter enough py3k warnings
In-Reply-To: <1265106776.19.0.232903733304.issue7837@psf.upfronthosting.co.za>
Message-ID: <1265123896.76.0.154732688436.issue7837@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Variant based on the previous patches.

It fixes an error relative to assertSameElements: comparing sequences which contain unorderable types.

Example: [2j, 5j, set(), frozenset()]


The util.unorderable_list_difference() helper is backported from 3.x.

----------
Added file: http://bugs.python.org/file16106/issue7837_assertSameElements.diff

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

From report at bugs.python.org  Tue Feb  2 16:24:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Feb 2010 15:24:07 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265124247.19.0.90842603122.issue6760@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm happy to delete the two sentences about quoting.

As for -c, you are so right that it is cryptic.  In the new version of the patch I've changed the sentence to be as precise as possible, but I'm not at all convinced that it is less confusing.  This is why I think the API should be changed.

----------
Added file: http://bugs.python.org/file16107/subprocess-doc.patch

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

From report at bugs.python.org  Tue Feb  2 16:35:28 2010
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 02 Feb 2010 15:35:28 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265124928.37.0.94257535476.issue6760@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

This version takes Murray's most recent draft, applies some minor tweaks from my prior patch, and has the "python -c" etc. changed to "echo '$MONEY'" so the sh -c comment is completely unambiguous (and it's a simpler example generally).

Whether the subprocess.Popen() call should be demonstrated in the code snippet remains an open issue.

----------
Added file: http://bugs.python.org/file16108/subprocess.rst.patch

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

From report at bugs.python.org  Tue Feb  2 16:35:42 2010
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 02 Feb 2010 15:35:42 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265124942.38.0.975540798324.issue6760@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


Removed file: http://bugs.python.org/file16101/subprocess.rst.patch

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

From report at bugs.python.org  Tue Feb  2 16:56:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Feb 2010 15:56:17 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265126177.57.0.621332708332.issue6760@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The change to echo is an excellent improvement.  You forgot to change 'python' to 'echo' in the following paragraph, though. You are also correct about /bin/sh vs sh, my bad.  And I was even looking at the source code when I wrote that...

----------

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

From report at bugs.python.org  Tue Feb  2 16:59:03 2010
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 02 Feb 2010 15:59:03 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265126343.37.0.242638809217.issue6760@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


Added file: http://bugs.python.org/file16109/subprocess.rst.patch

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

From report at bugs.python.org  Tue Feb  2 16:59:17 2010
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 02 Feb 2010 15:59:17 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265126357.43.0.155593111461.issue6760@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


Removed file: http://bugs.python.org/file16108/subprocess.rst.patch

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

From report at bugs.python.org  Tue Feb  2 17:26:33 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 02 Feb 2010 16:26:33 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265127993.17.0.489903695331.issue6760@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Now you need to put the import of subprocess back in!

Otherwise it looks good to me.

----------

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

From report at bugs.python.org  Tue Feb  2 17:37:43 2010
From: report at bugs.python.org (Eric Hopper)
Date: Tue, 02 Feb 2010 16:37:43 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1265128663.7.0.64958208194.issue7753@psf.upfronthosting.co.za>


Changes by Eric Hopper <eric-bugs at omnifarious.org>:


----------
nosy: +Omnifarious

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

From report at bugs.python.org  Tue Feb  2 17:48:18 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 02 Feb 2010 16:48:18 +0000
Subject: [issue5099] subprocess.POpen.__del__() AttributeError (os module ==
	None!)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1265129298.02.0.804694501477.issue5099@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> patch review

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

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: [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 18:35:35 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Feb 2010 17:35:35 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1265132135.54.0.466081214604.issue7092@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

test_exceptions and test_pep352 fixed in r77913.

----------

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

From report at bugs.python.org  Tue Feb  2 18:35:50 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Feb 2010 17:35:50 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1265132150.5.0.950351637335.issue7092@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file16053/issue7092_test_exceptions_v2.diff

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

From report at bugs.python.org  Tue Feb  2 18:44:42 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 02 Feb 2010 17:44:42 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1265132682.25.0.827328799742.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16096/issue7092_unittest.py

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

From report at bugs.python.org  Tue Feb  2 18:45:26 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 02 Feb 2010 17:45:26 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1265132726.8.0.161261614887.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

test_unittest fixed in r77911. See also #7837.

----------

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

From report at bugs.python.org  Tue Feb  2 18:55:23 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Feb 2010 17:55:23 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1265133323.22.0.465543689662.issue7092@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

In issue7092_test_support:
1) silence_py3k_warning should have a docstring that explain what the function does and what filters should be, possibly including an example;
2) I'd use "if not filters:" instead of "if filters == ():";
3) are there cases where the third arg of filterwarnings is not DeprecationWarning? If not, it's probably better to turn "filters" in a list of regex instead than a sequence of tuples like (regex, DeprecationWarning);
4) maybe silence_py3k_warning could yield an instance of WarningsRecorder, in case someone wants to access the silenced warnings.

----------

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

From report at bugs.python.org  Tue Feb  2 19:20:49 2010
From: report at bugs.python.org (Will Grainger)
Date: Tue, 02 Feb 2010 18:20:49 +0000
Subject: [issue6676] expat parser throws Memory Error when parsing multiple
	files
In-Reply-To: <1249921405.95.0.689815480815.issue6676@psf.upfronthosting.co.za>
Message-ID: <1265134849.92.0.789360244328.issue6676@psf.upfronthosting.co.za>


Will Grainger <willgrainger at gmail.com> added the comment:

I don't think this is a python specific problem. I have just seen 
the same error when working with the expat library from C, and the cause
is using the same parser to read multiple files.

----------
nosy: +willgrainger

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

From report at bugs.python.org  Tue Feb  2 19:54:39 2010
From: report at bugs.python.org (Todd Whiteman)
Date: Tue, 02 Feb 2010 18:54:39 +0000
Subject: [issue7753] newgil backport
In-Reply-To: <1264124458.62.0.397981823576.issue7753@psf.upfronthosting.co.za>
Message-ID: <1265136879.39.0.670620497912.issue7753@psf.upfronthosting.co.za>


Changes by Todd Whiteman <twhitema at yahoo.com.au>:


----------
nosy: +twhitema

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

From report at bugs.python.org  Tue Feb  2 20:08:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Feb 2010 19:08:05 +0000
Subject: [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 20:39:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2010 19:39:48 +0000
Subject: [issue7385] MemoryView_FromObject crashes if PyBuffer_GetBuffer fails
In-Reply-To: <1259014027.47.0.458918561634.issue7385@psf.upfronthosting.co.za>
Message-ID: <1265139588.8.0.0486858965015.issue7385@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

When PyMemoryView_FromObject() doesn't return NULL, you should decref the result. Otherwise, it's "perfect".

----------

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

From report at bugs.python.org  Tue Feb  2 21:49:04 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 02 Feb 2010 20:49:04 +0000
Subject: [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: <1265143744.52.0.986114040624.issue7839@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

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


Brian Curtin <curtin at acm.org> added the comment:

Attached is a patch which adds docstrings to the functions in PC/_subprocess.c, documents the functions in Doc/library/subprocess.rst, and removes a chunk of unneeded import code from Lib/subprocess.py

----------
keywords: +needs review, patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file16110/issue7838.diff

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

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


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file16110/issue7838.diff

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

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


Changes by Brian Curtin <curtin at acm.org>:


Added file: http://bugs.python.org/file16111/issue7838.diff

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

From report at bugs.python.org  Tue Feb  2 22:22:40 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Feb 2010 21:22:40 +0000
Subject: [issue7838] Undocumented subprocess functions on Windows
In-Reply-To: <1265130024.2.0.807929500007.issue7838@psf.upfronthosting.co.za>
Message-ID: <1265145760.8.0.690417378301.issue7838@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is likely because these functions are meant to be undocumented implementation details.

----------
nosy: +benjamin.peterson

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

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


Brian Curtin <curtin at acm.org> added the comment:

True. Is there value in eventually privatizing these functions?

It feels weird having them exposed but not documented at all...maybe just keep the docstrings around?

----------
status: open -> pending

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

From report at bugs.python.org  Tue Feb  2 23:09:33 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 02 Feb 2010 22:09:33 +0000
Subject: [issue7385] MemoryView_FromObject crashes if PyBuffer_GetBuffer fails
In-Reply-To: <1259014027.47.0.458918561634.issue7385@psf.upfronthosting.co.za>
Message-ID: <1265148573.56.0.241114427485.issue7385@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16060/issue7385_memoryview.diff

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

From report at bugs.python.org  Tue Feb  2 23:16:32 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 02 Feb 2010 22:16:32 +0000
Subject: [issue7385] MemoryView_FromObject crashes if PyBuffer_GetBuffer fails
In-Reply-To: <1259014027.47.0.458918561634.issue7385@psf.upfronthosting.co.za>
Message-ID: <1265148992.37.0.275947372567.issue7385@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Thanks.

----------
Added file: http://bugs.python.org/file16112/issue7385_memoryview_v2.diff

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

From report at bugs.python.org  Tue Feb  2 23:20:01 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 02 Feb 2010 22:20:01 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1265149201.96.0.225662285592.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16044/issue7092_test_support.py

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

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: [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:36:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2010 22:36:48 +0000
Subject: [issue7385] MemoryView_FromObject crashes if PyBuffer_GetBuffer fails
In-Reply-To: <1259014027.47.0.458918561634.issue7385@psf.upfronthosting.co.za>
Message-ID: <1265150208.74.0.902821452724.issue7385@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've added a missing call to PyBuffer_Release() and committed the patch to trunk (r77916).

----------

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

From report at bugs.python.org  Tue Feb  2 23:45:43 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 02 Feb 2010 22:45:43 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1265150743.21.0.320888893377.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Docstring added.

Notes:
 - there's 2 categories of -3 warnings: SyntaxWarning and DeprecationWarning.
 - AFAICT, the WarningsRecorder needs "catch_warnings(record=True)".
   And in such case, *all* warnings are silenced.

----------
Added file: http://bugs.python.org/file16113/issue7092_test_support_v2.diff

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

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: [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:48:21 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 02 Feb 2010 22:48:21 +0000
Subject: [issue7841] test_capi fails when run more than once
In-Reply-To: <1265150762.77.0.853473335422.issue7841@psf.upfronthosting.co.za>
Message-ID: <1265150901.33.0.7203513686.issue7841@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Backport missing. See #7816

----------
nosy: +flox
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> test_capi crashes when run with "-R"

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

From report at bugs.python.org  Tue Feb  2 23:49:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2010 22:49:19 +0000
Subject: [issue7816] test_capi crashes when run with "-R"
In-Reply-To: <1264893605.27.0.74560765307.issue7816@psf.upfronthosting.co.za>
Message-ID: <1265150959.3.0.263845148583.issue7816@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Needs to be merged in py3k :)

----------
nosy: +pitrou

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

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: [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  Tue Feb  2 23:52:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2010 22:52:12 +0000
Subject: [issue7385] MemoryView_FromObject crashes if PyBuffer_GetBuffer fails
In-Reply-To: <1259014027.47.0.458918561634.issue7385@psf.upfronthosting.co.za>
Message-ID: <1265151132.8.0.955153414625.issue7385@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Merged in r77918 (py3k) and r77920 (3.1).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Feb  3 00:02:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Feb 2010 23:02:17 +0000
Subject: [issue7723] sqlite only accept buffer() for BLOB
	objects	(input/output)
In-Reply-To: <1263735953.04.0.426363629034.issue7723@psf.upfronthosting.co.za>
Message-ID: <1265151737.71.0.173625632215.issue7723@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Pablo's documentation patch for py3k has been committed.

----------

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

From report at bugs.python.org  Wed Feb  3 00:22:31 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 02 Feb 2010 23:22:31 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1265152951.32.0.431203462024.issue7511@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
priority:  -> critical
resolution:  -> accepted

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

From report at bugs.python.org  Wed Feb  3 00:23:30 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 02 Feb 2010 23:23:30 +0000
Subject: [issue6283] Cannot build extension in amd64 using msvc9compiler
In-Reply-To: <1244987468.85.0.396301631891.issue6283@psf.upfronthosting.co.za>
Message-ID: <1265153010.1.0.724218513157.issue6283@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee:  -> tarek
nosy: +tarek
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Wed Feb  3 02:14:02 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Feb 2010 01:14:02 +0000
Subject: [issue7816] test_capi crashes when run with "-R"
In-Reply-To: <1264893605.27.0.74560765307.issue7816@psf.upfronthosting.co.za>
Message-ID: <1265159642.68.0.0239870865948.issue7816@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

As you wish: r77934.

----------

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

From report at bugs.python.org  Wed Feb  3 03:00:52 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Feb 2010 02:00:52 +0000
Subject: [issue6978] compiler.transformer dict key bug d[1,] = 1
In-Reply-To: <1253712935.73.0.771654753866.issue6978@psf.upfronthosting.co.za>
Message-ID: <1265162452.19.0.649648518244.issue6978@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

As I said before, the patch needs a test and should remove those ugly \ from the list comprehension.

----------

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

From report at bugs.python.org  Wed Feb  3 03:48:48 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Feb 2010 02:48:48 +0000
Subject: [issue7838] Undocumented subprocess functions on Windows
In-Reply-To: <1265130024.2.0.807929500007.issue7838@psf.upfronthosting.co.za>
Message-ID: <1265165328.21.0.434068693013.issue7838@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Actually, I consider them private now, given that they aren't in __all__ or documented. I'd prefer if the code was changed to qualify their use with _subprocess.X actually. Docstrings are fine, I suppose.

----------
status: pending -> open

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

From report at bugs.python.org  Wed Feb  3 04:00:33 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Feb 2010 03:00:33 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1258157753.29.0.814065625122.issue7319@psf.upfronthosting.co.za>
Message-ID: <1265166033.91.0.876058777103.issue7319@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Has enough time elapsed yet for py3k merging?

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Wed Feb  3 07:21:53 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 03 Feb 2010 06:21:53 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1265178113.74.0.178611722289.issue7092@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Applied the syntax fixes in r77942.

----------
assignee:  -> ezio.melotti

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

From report at bugs.python.org  Wed Feb  3 07:22:23 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 03 Feb 2010 06:22:23 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1265178143.27.0.260485523907.issue7092@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file16048/issue7092_syntax_fixes.diff

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

From report at bugs.python.org  Wed Feb  3 07:27:59 2010
From: report at bugs.python.org (Garen Parham)
Date: Wed, 03 Feb 2010 06:27:59 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1265178479.99.0.535650088626.issue6715@psf.upfronthosting.co.za>


Garen Parham <garen.parham at gmail.com> added the comment:

Once Python gets native support for lzma/xz like it does for zlib, bzip2 it could switch to using it for bundles and remote transfers. See:

http://mercurial.selenic.com/bts/issue1463

With lzma/xz being able to compress so much better, it'd be really appreciated by users on especially slow links(!!).

----------
nosy: +Garen.Parham

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

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: [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 07:35:00 2010
From: report at bugs.python.org (Garen)
Date: Wed, 03 Feb 2010 06:35:00 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1265178900.36.0.814393332262.issue6715@psf.upfronthosting.co.za>


Garen <garen.parham at gmail.com> added the comment:

Ugh, can't edit previous message. Meant to say:

"Once Python gets native support for lzma/xz like it does for zlib and bzip2, Mercurial could switch to using it for bundles and remote transfers."

For platforms with native support in-kernel (e.g. Linux) that could be used instead of the bundled version.

(Since Python is officially switching to Mercurial, arguably this issue even more important.)

----------

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

From report at bugs.python.org  Wed Feb  3 08:19:38 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Feb 2010 07:19:38 +0000
Subject: [issue7319] Silence DeprecationWarning by default
In-Reply-To: <1265166033.91.0.876058777103.issue7319@psf.upfronthosting.co.za>
Message-ID: <bbaeab101002022318j18f0ccbcpccb726a88221a22a@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Tue, Feb 2, 2010 at 19:00, Benjamin Peterson <report at bugs.python.org> wrote:
>
> Benjamin Peterson <benjamin at python.org> added the comment:
>
> Has enough time elapsed yet for py3k merging?

Sure. I will try to do it before or at PyCon.

----------

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

From report at bugs.python.org  Wed Feb  3 09:02:17 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Feb 2010 08:02:17 +0000
Subject: [issue7361] importlib not checking bytecode length
In-Reply-To: <1258658288.16.0.0772350847135.issue7361@psf.upfronthosting.co.za>
Message-ID: <1265184137.53.0.531306329455.issue7361@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I can't reproduce the failure as running test_multiprocessing and then test_importlib does not show any left over stuff in the interpreter what would lead to importlib being used for __import__. But as the IndexError part is a valid issue I am renaming the issue.

----------
title: Strange importlib error during test_multiprocessing failure -> importlib not checking bytecode length

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

From report at bugs.python.org  Wed Feb  3 09:20:11 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Feb 2010 08:20:11 +0000
Subject: [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: <1265185211.2.0.571235262713.issue7829@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority:  -> low
stage:  -> needs patch

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

From report at bugs.python.org  Wed Feb  3 09:21:17 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Feb 2010 08:21:17 +0000
Subject: [issue2874] Remove use of the stat module in the stdlib
In-Reply-To: <1210913145.44.0.456986373707.issue2874@psf.upfronthosting.co.za>
Message-ID: <1265185277.61.0.567656660617.issue2874@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, this ain't ever going to happen, so I am just going to close this issue.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Wed Feb  3 09:49:31 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 03 Feb 2010 08:49:31 +0000
Subject: [issue7838] Undocumented subprocess functions on Windows
In-Reply-To: <1265130024.2.0.807929500007.issue7838@psf.upfronthosting.co.za>
Message-ID: <1265186971.18.0.514589997506.issue7838@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree.  Docstrings never hurt.

----------

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

From report at bugs.python.org  Wed Feb  3 14:51:22 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 03 Feb 2010 13:51:22 +0000
Subject: [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:52:21 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 03 Feb 2010 13:52:21 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1265205141.38.0.965845045174.issue5677@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The new patch takes over the logic from fileio.c. Tested on Linux, Windows x86/x64 and OpenSolaris.

----------
Added file: http://bugs.python.org/file16115/add-readable-writable.patch

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

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


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
stage:  -> needs patch

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

From report at bugs.python.org  Wed Feb  3 15:08:22 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 03 Feb 2010 14:08:22 +0000
Subject: [issue7844] Add -3 warning for absolute imports.
In-Reply-To: <1265205081.99.0.588324125272.issue7844@psf.upfronthosting.co.za>
Message-ID: <1265206102.76.0.388340486236.issue7844@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Wed Feb  3 15:12:10 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 03 Feb 2010 14:12:10 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1265206330.11.0.404826379137.issue5211@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, I'd certainly be interested in reviewing a patch.  Though the current behaviour is at most a minor wart, and since it's gone in Python 3.x the motivation to fix it isn't huge. :)

> Where as I think gumtree wants the xcomplex case to behave as
> the xfloat case, e.g. ...

Yes, that was what I was proposing.  But as you point out, the new behaviour wouldn't even match the behaviour of Python 3.x, so it really wouldn't be a terribly useful change.

> However, if we are going to do that then we might as well just
> backport the whole removal of coercion.

That's not really an option:  it has the potential to break existing code that uses coercion.  Removing coercion in Python 2.x would require at least a PEP plus one version's worth of DeprecationWarning.  And given that it currently looks as though Python 2.8 isn't likely to happen at all, that would likely be a wasted effort.

----------

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

From report at bugs.python.org  Wed Feb  3 15:52:13 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 03 Feb 2010 14:52:13 +0000
Subject: [issue7788] segfault when deleting from a list using slice with very
	big `step' value
In-Reply-To: <1264531632.85.0.040390960633.issue7788@psf.upfronthosting.co.za>
Message-ID: <1265208733.56.0.967271097046.issue7788@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This patch is producing warnings about signed <-> unsigned comparisons on the Windows buildbots;  these should be fixed.  See:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%202.6/builds/781/steps/compile/logs/warnings

----------
priority: release blocker -> normal
status: closed -> open

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

From report at bugs.python.org  Wed Feb  3 16:02:17 2010
From: report at bugs.python.org (Andrew Clegg)
Date: Wed, 03 Feb 2010 15:02:17 +0000
Subject: [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 16:29:24 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 03 Feb 2010 15:29:24 +0000
Subject: [issue7846] Fnmatch cache is never cleared during usage
In-Reply-To: <1265209336.56.0.865162695939.issue7846@psf.upfronthosting.co.za>
Message-ID: <1265210964.79.0.401873465205.issue7846@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> test needed
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

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

From report at bugs.python.org  Wed Feb  3 16:31:27 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 03 Feb 2010 15:31:27 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265211087.6.0.111788909771.issue6877@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


----------
nosy: +fdrake

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

From report at bugs.python.org  Wed Feb  3 16:34:10 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 03 Feb 2010 15:34:10 +0000
Subject: [issue7838] Undocumented subprocess functions on Windows
In-Reply-To: <1265130024.2.0.807929500007.issue7838@psf.upfronthosting.co.za>
Message-ID: <1265211250.9.0.861452437735.issue7838@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Here's a patch which keeps docstrings, and explicitly qualifies the Windows specific functions from _subprocess rather than using import * (which causes a couple of lines just over 79 chars). Now the functions are more hidden than before.

Ran the tests to be sure I got each change, nothing seems to have slipped by.

----------
Added file: http://bugs.python.org/file16117/issue7838_v2.diff

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

From report at bugs.python.org  Wed Feb  3 17:38:45 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 03 Feb 2010 16:38:45 +0000
Subject: [issue6716] Windows install error when choosing to compile .py files
In-Reply-To: <1250514309.72.0.0787236734451.issue6716@psf.upfronthosting.co.za>
Message-ID: <1265215125.64.0.0149179132661.issue6716@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I just saw this today while installing the 3.1.1 final MSI on a Server 2003 box.

----------
components: +Windows
nosy: +brian.curtin
priority:  -> high
stage:  -> needs patch
type: compile error -> behavior

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

From report at bugs.python.org  Wed Feb  3 17:45:58 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 03 Feb 2010 16:45:58 +0000
Subject: [issue3920] OpenBSD 4.4 still doesn't support _XOPEN_SOURCE
In-Reply-To: <1221983557.66.0.866339205664.issue3920@psf.upfronthosting.co.za>
Message-ID: <1265215558.32.0.591734065706.issue3920@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I tested bsd3.diff on OpenBSD-4.4/py3k and it works fine. ncurses
doesn't build and I get a libssl assertion failure in test_ftplib,
but without the patch I can't build py3k at all.
 
This is a significant improvement, so +1 for applying the patch.

----------
nosy: +skrah

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

From report at bugs.python.org  Wed Feb  3 17:53:58 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Feb 2010 16:53:58 +0000
Subject: [issue7845] complex.__lt__ should return NotImplemented instead of
	raising TypeError
In-Reply-To: <1265205516.08.0.748801363745.issue7845@psf.upfronthosting.co.za>
Message-ID: <1265216038.89.0.772252914296.issue7845@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1

----------
nosy: +rhettinger

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

From report at bugs.python.org  Wed Feb  3 18:35:08 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 03 Feb 2010 17:35:08 +0000
Subject: [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 18:45:32 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 03 Feb 2010 17:45:32 +0000
Subject: [issue7847] Remove 'python -U' or document it
In-Reply-To: <1265218507.7.0.0697222778425.issue7847@psf.upfronthosting.co.za>
Message-ID: <1265219132.98.0.342415178865.issue7847@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> loewis
nosy: +loewis

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

From report at bugs.python.org  Wed Feb  3 18:55:04 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 03 Feb 2010 17:55:04 +0000
Subject: [issue7847] Remove 'python -U' or document it
In-Reply-To: <1265218507.7.0.0697222778425.issue7847@psf.upfronthosting.co.za>
Message-ID: <4B69B875.70704@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Barry A. Warsaw wrote:
> 
> 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).

+1 on removing it.

It has been deliberately been undocumented since Python 2.2
in order to be able to phase out its use and finally remove it.

----------
nosy: +lemburg

_______________________________________
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: [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 20:44:27 2010
From: report at bugs.python.org (Arkadiusz Miskiewicz Arkadiusz Miskiewicz)
Date: Wed, 03 Feb 2010 19:44:27 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1265226267.29.0.068141830083.issue6715@psf.upfronthosting.co.za>


Arkadiusz Miskiewicz				Arkadiusz Miskiewicz <arekm at maven.pl> added the comment:

About why xz is important. 

gnu.org, tug.org started publishing sources in xz format, quick grep:

autoconf/autoconf.spec:Source0: http://ftp.gnu.org/gnu/autoconf/%{name}-%{version}.tar.xz
coreutils/coreutils.spec:Source0:       http://ftp.gnu.org/gnu/coreutils/%{name}-%{version}.tar.xz
libpng12/libpng12.spec:Source0: http://downloads.sourceforge.net/libpng/libpng-%{version}.tar.xz
libpng/libpng.spec:Source0:     http://downloads.sourceforge.net/libpng/%{name}-%{version}.tar.xz
parted/parted.spec:Source0:     http://ftp.gnu.org/gnu/parted/%{name}-%{version}.tar.xz
texlive-texmf/texlive-texmf.spec:Source0:       ftp://tug.org/texlive/historic/%{year}/texlive-%{version}-texmf.tar.xz

xz is also supported by automake as dist target.

----------
nosy: +arekm

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

From report at bugs.python.org  Wed Feb  3 20:47:59 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 03 Feb 2010 19:47:59 +0000
Subject: [issue7847] Remove 'python -U' or document it
In-Reply-To: <1265218507.7.0.0697222778425.issue7847@psf.upfronthosting.co.za>
Message-ID: <1265226479.22.0.423303596525.issue7847@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I fail to see the point. This bug was fixed in Python 3. Why risk breaking something in the last 2.x release?

----------

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

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: [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 21:04:08 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 03 Feb 2010 20:04:08 +0000
Subject: [issue7849] Improve "test_support.check_warnings()"
In-Reply-To: <1265227352.4.0.15322999222.issue7849@psf.upfronthosting.co.za>
Message-ID: <1265227448.05.0.543694491063.issue7849@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file16118/issue7849_check_warnings.diff

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

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


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch for the context managers.
Patch to fix the stdlib.

----------
Added file: http://bugs.python.org/file16119/issue7849_lib_fixes.diff

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

From report at bugs.python.org  Wed Feb  3 21:09:42 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 03 Feb 2010 20:09:42 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1265227782.32.0.946614168306.issue7092@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
dependencies: +Improve "test_support.check_warnings()"

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

From report at bugs.python.org  Wed Feb  3 21:39:42 2010
From: report at bugs.python.org (Blair)
Date: Wed, 03 Feb 2010 20:39:42 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1265229582.85.0.0781624958201.issue5211@psf.upfronthosting.co.za>


Blair <bidihall at gmail.com> added the comment:

I also agree that this bug was never more than a small wart. However, I'm now curious. 

If Python 3 does not support coercion, I think that it will not be possible to write something like my xfloat class, derived from float (i.e., some binary operations between an xfloat and a float would return a float instead of an xfloat). 

If I am correct in think that it would seem to be a step backward.

Will Python 3 deal with mixed types in some other way, or has this problem been abandoned altogether? If it is the latter, I think it is a pity.

----------

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

From report at bugs.python.org  Wed Feb  3 21:44:09 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 03 Feb 2010 20:44:09 +0000
Subject: [issue7845] complex.__lt__ should return NotImplemented instead of
	raising TypeError
In-Reply-To: <1265205516.08.0.748801363745.issue7845@psf.upfronthosting.co.za>
Message-ID: <1265229849.02.0.0285475560203.issue7845@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Wed Feb  3 22:07:11 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 03 Feb 2010 21:07:11 +0000
Subject: [issue7849] Improve "test_support.check_warnings()"
In-Reply-To: <1265227352.4.0.15322999222.issue7849@psf.upfronthosting.co.za>
Message-ID: <1265231231.28.0.179001879275.issue7849@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

In other words you want a way to limit what the context manager catches and records while allowing all other warnings to propagate. That seems fine.

I didn't do much of a code review, but there is a grammatical error in the docstring: change "a filter catch nothing" to "a filter catches nothing".

----------
nosy: +brett.cannon

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

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


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Actually this patch enhances check_warnings() in other ways too:
 - it verifies if the warning is effectively raised
 - it deals with "py3k" warnings separately

It could be used instead of warnings.filterwarnings() with some benefits.

----------

_______________________________________
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: [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:07:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 03 Feb 2010 23:07:47 +0000
Subject: [issue7849] Improve "test_support.check_warnings()"
In-Reply-To: <1265227352.4.0.15322999222.issue7849@psf.upfronthosting.co.za>
Message-ID: <1265238467.98.0.396546667655.issue7849@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16118/issue7849_check_warnings.diff

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

From report at bugs.python.org  Thu Feb  4 00:11:22 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 03 Feb 2010 23:11:22 +0000
Subject: [issue7849] Improve "test_support.check_warnings()"
In-Reply-To: <1265227352.4.0.15322999222.issue7849@psf.upfronthosting.co.za>
Message-ID: <1265238682.45.0.788108264115.issue7849@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Fixed. Tested with different options: "-Wd", "-3"

----------
Added file: http://bugs.python.org/file16120/issue7849_check_warnings_v2.diff

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

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: [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 01:28:21 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 04 Feb 2010 00:28:21 +0000
Subject: [issue7092] Test suite emits many DeprecationWarnings when -3 is
	enabled
In-Reply-To: <1255098633.29.0.866346989212.issue7092@psf.upfronthosting.co.za>
Message-ID: <1265243301.06.0.436538689546.issue7092@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The enhancement proposed on #7849 should be considered before reviewing the last 2 patches.

If #7849 is accepted, these patches will need update.

----------

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

From report at bugs.python.org  Thu Feb  4 01:37:24 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Thu, 04 Feb 2010 00:37:24 +0000
Subject: [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: <1265243844.96.0.825849650052.issue7833@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

I thought one conclusion of the discussion on issue4120 was that any executable, which embeds Python and imports MSVCR9 dependent extensions, must now provide the manifest for the MSVCR9 runtimes, either embedded or as a separate file. See <http://bugs.python.org/issue4120#msg94644> and responses. Why shouldn't this apply to wininst executables?

Another observation: importing the winsound extension in the postinstall script works even though it also depends on MSVCR90.DLL. Winsound.pyd does not have an embedded manifest. It is linked with /MANIFEST:NO. Apparently there is a difference between an "empty" manifest and no manifest. 

How about a patch that does:

1) not embed any manifest into PYD files if the manifest contains only a single MSVCR90 dependentAssembly element. 

2) remove the MSVCR90 dependentAssembly element from manifests embedded into PYD files if the manifest defines additional dependentAssembly elements (e.g. for MFC or Common Controls). This is essentially what the msvc9compiler_stripruntimes patch does now.

3) not embed manifests into any file (EXE, PYD, or DLL) if '/MANIFEST:NO' is defined in extra_link_args. Extension developers can then provide external manifest files.

4) not touch the default manifests embedded into EXE and DLL files. The msvc9compiler_stripruntimes currently produces DLLs that can not be used standalone, such as pythoncom26.dll from the pywin32 package (I can file a separate bug if requested). Pythoncom26.dll is meant to be placed in the system32 folder and to be used outside of a Python environment, i.e. from the Windows Scripting Host. Several pywin32 tests fail with the pythoncom26.dll built with the msvc9compiler_stripruntimes patch. Placing a MSVCR9 manifest file into the system32 folder next to the pythoncom26.dll is not an option.


A tentative patch against the Python 2.6 branch is attached. I will test it further.

(1) and (4) will solve the original pywin32 wininstaller problem without changing wininst.exe.

As it is now the installer and some functionality of the pywin32 package will likely break if pywin32 is built on Python 2.6.5.

----------
Added file: http://bugs.python.org/file16121/msvc9compiler_stripruntimes_revised.patch

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

From report at bugs.python.org  Thu Feb  4 01:40:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2010 00:40:58 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1265178479.99.0.535650088626.issue6715@psf.upfronthosting.co.za>
Message-ID: <1265244138.3469.2.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

We all agree that lzma/xz is important, what is needed is a patch.

----------

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

From report at bugs.python.org  Thu Feb  4 01:50:34 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 04 Feb 2010 00:50:34 +0000
Subject: [issue1225769] Proposal to implement comment rows in csv module
Message-ID: <1265244634.7.0.127289400583.issue1225769@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Here is another -1 for this proposed feature. Having a comments in the csv fields and providing a way to deal will complicate matters more than required. Different suggestions of how to accomplish it has been suggested here. As others, I too recommend closing it. (It is assigned to andewmcnamara, so I guess, he would close it).

----------
nosy: +orsenthil

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

From report at bugs.python.org  Thu Feb  4 03:10:24 2010
From: report at bugs.python.org (Andrew McNamara)
Date: Thu, 04 Feb 2010 02:10:24 +0000
Subject: [issue1225769] Proposal to implement comment rows in csv module
Message-ID: <1265249424.27.0.173536144843.issue1225769@psf.upfronthosting.co.za>


Andrew McNamara <andrewm at object-craft.com.au> added the comment:

Okay, while I am sympathetic to the points raised by the people asking for this enhancement, I'm persuaded to reject it by the arguments that the potential benefit is outweighed by the increase in complexity (code and documentation).

While the attached patch from Iain requires relatively minor and innocuous changes to the state machine, it only satisfies a limited subset of users, and the effect of complexity is geometric. In other words, to understand the state machine, you need to understand the relation of each state to every other state, etc.

As to why the core of the module is implemented in C, the sort of stateful parsing done by the module is one area where python does not excel (Ha!). Stripping comments, on the other hand, CAN be done with reasonable efficiency from python (and considerably more flexibility). Also, it has been my experience that CSV files that use comments typically have other non-standard features as well, requiring additional pre- and post-processing in any case.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Thu Feb  4 03:34:45 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 04 Feb 2010 02:34:45 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1265250885.6.0.222058888757.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20100204.zip is a new version of the regex module.

I've added splititer and added a build for Python 3.1.

----------
versions: +Python 3.1
Added file: http://bugs.python.org/file16122/issue2636-20100204.zip

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

From report at bugs.python.org  Thu Feb  4 03:54:41 2010
From: report at bugs.python.org (Meador Inge)
Date: Thu, 04 Feb 2010 02:54:41 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1265252081.2.0.993744240476.issue5211@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> Mark
>
> Yes, that was what I was proposing.

As you pointed out in issue 3734, the patch is basically:

===================================================================
--- Objects/complexobject.c	(revision 77909)
+++ Objects/complexobject.c	(working copy)
@@ -1282,7 +1282,8 @@
 	PyObject_GenericGetAttr,		/* tp_getattro */
 	0,					/* tp_setattro */
 	0,					/* tp_as_buffer */
-	Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE, /* tp_flags */
+	Py_TPFLAGS_DEFAULT | Py_TPFLAGS_CHECKTYPES 
+                | Py_TPFLAGS_BASETYPE,          /* tp_flags */
 	complex_doc,				/* tp_doc */
 	0,					/* tp_traverse */
 	0,					/* tp_clear */

plus the relevant test cases and documentation changes.

> Mark
>
> That's not really an option:  it has the potential to break existing 
> code that uses coercion.  Removing coercion in Python 2.x would 
> require at least a PEP plus one version's worth of DeprecationWarning.

Ah, good point.  In that case I am -1 on changing the behavior at all.  For the sole reason that cases like Blair originally reported would not work as expected in version < 2.7, then would work in 2.7, and then would break again in > 3.0.  I think explaining and documenting the change in behavior would be really confusing.

> Blair
>
> If I am correct in think that it would seem to be a step backward.

I disagree.  I think type coercion (or implicit conversions) is hard to follow and understand.  I say this from many years of C and C++ programming.  I see bugs all of the time in these languages due to conversions silently happening that the programmer was not aware of.  Yes the feature is convenient, but documenting and explaining these rules to programmers becomes very tedious and requires that most programmers have deep understanding of the languages typing rules.  This typically leads to books like "Effective C++" that catalog a list of things *not* to do in a language.  The relevant case for C++ being to avoid user defined conversions and use explicit constructers.  As such, I am definitely +1 on removing coercion.

----------

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

From report at bugs.python.org  Thu Feb  4 04:48:42 2010
From: report at bugs.python.org (Blair)
Date: Thu, 04 Feb 2010 03:48:42 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1265255322.01.0.418670010752.issue5211@psf.upfronthosting.co.za>


Blair <bidihall at gmail.com> added the comment:

OK. I have gone back to the beginning to refresh my memory and I see a possible point of misunderstanding. I am not sure that we are really talking about the problem that prompted my initial report (msg72169, issue 3734). 

Immediately following my message, Daniel Diniz confirmed the bug and expanded on my code with an xfloat class of his own that uses __coerce__. 

In fact, if I had submitted an xfloat class it would have been the following 

class xfloat( float ):

    def __new__(cls,*args,**kwargs):
        return float.__new__(cls,*args,**kwargs)
        
    def __add__(self,x):
        return xfloat( float.__add__(self,x) )

    def __radd__(self,x):
        return xfloat( float.__radd__(self,x) )

My xfloat works fine in 2.6.4 and it was my wish, at the time, to write a class for xcomplex that behaved in a similar way. According to the Python manual, that should have been possible, but it wasn't.

So, I guess coercion is not really the problem. 

However, there does seem to be something wrong with the complex type.

I have looked at the manual for Python 3 and see that the same rules apply for classes that emulate numeric types, namely:

"If the right operand?s type is a subclass of the left operand?s type and that subclass provides the reflected method for the operation, this method will be called before the left operand?s non-reflected method. This behavior allows subclasses to override their ancestors? operations."

The question I have then is will the following work in Python 3 (it doesn't in 2.6.4)?

class xcomplex( complex ):

    def __new__(cls,*args,**kwargs):
        return complex.__new__(cls,*args,**kwargs)

##    def __coerce__(self,other):
##        t = complex.__coerce__(self,other)
##        try:
##            return (self,xcomplex(t[1]))
##        except TypeError:
##            return t
        
    def __add__(self,x):
        return xcomplex( complex.__add__(self,x) )
    
    def __radd__(self,x):
        return xcomplex( complex.__radd__(self,x) )

xz = xcomplex(1+2j)
xy = float(10.0)
z = complex(10+1j)

print "would like xcomplex type each time"
print type(xz + z)  
print type(xz + xy) 
print type(xz + 10) 
print type(xy + xz) 
print type(10 + xz) 
print type(z + xz)

----------

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

From report at bugs.python.org  Thu Feb  4 05:05:38 2010
From: report at bugs.python.org (Andrew McNamara)
Date: Thu, 04 Feb 2010 04:05:38 +0000
Subject: [issue1225769] Proposal to implement comment rows in csv module
Message-ID: <1265256338.72.0.612838631507.issue1225769@psf.upfronthosting.co.za>


Andrew McNamara <andrewm at object-craft.com.au> added the comment:

Note that there is one case that cannot easily be addressed via pre-processing: where the comment character coincidently appears at the start of a line within a multi-line quoted field. For example:

# This is a comment
1, 2, "This is field^M
#3"

What this should produce is debatable, but it would be hard to make it produce:

  ["1", "2", "This is field^M#3"]

without implementing it within the parser.

----------

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

From report at bugs.python.org  Thu Feb  4 08:12:58 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 04 Feb 2010 07:12:58 +0000
Subject: [issue1005895] curses for win32
Message-ID: <1265267578.14.0.311624975997.issue1005895@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Can this be considered a duplicate of issue 2889?

----------
versions: +Python 2.7 -Python 2.6

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

From report at bugs.python.org  Thu Feb  4 08:27:21 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 04 Feb 2010 07:27:21 +0000
Subject: [issue7728] test_timeout should use "find_unused_port" helper
In-Reply-To: <1263763659.44.0.532251726667.issue7728@psf.upfronthosting.co.za>
Message-ID: <1265268441.95.0.490495225091.issue7728@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

http://www.python.org/dev/buildbot/all/builders/AMD64%20Ubuntu%20trunk/builds/387

----------

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

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: [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:11:27 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Feb 2010 09:11:27 +0000
Subject: [issue4978] allow unicode keyword args
In-Reply-To: <1232233645.86.0.929697154925.issue4978@psf.upfronthosting.co.za>
Message-ID: <1265274687.71.0.405773293652.issue4978@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

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

From report at bugs.python.org  Thu Feb  4 10:27:55 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Feb 2010 09:27:55 +0000
Subject: [issue4978] allow unicode keyword args
In-Reply-To: <1232233645.86.0.929697154925.issue4978@psf.upfronthosting.co.za>
Message-ID: <1265275675.91.0.0390917995094.issue4978@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Really trivial back port of r68805 from trunk.

----------
assignee:  -> benjamin.peterson
components: +Interpreter Core -Library (Lib)
keywords: +needs review
resolution: accepted -> 
stage:  -> patch review
status: closed -> open
type: feature request -> behavior
versions: +Python 2.6
Added file: http://bugs.python.org/file16124/py26-backport.patch

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

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


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed 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 10:37:57 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 04 Feb 2010 09:37:57 +0000
Subject: [issue7853] on __exit__(), exc_value does not contain the exception.
In-Reply-To: <1265276109.88.0.802756804705.issue7853@psf.upfronthosting.co.za>
Message-ID: <1265276277.73.0.381118374795.issue7853@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file16126/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 10:52:30 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Feb 2010 09:52:30 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265277150.06.0.166659294849.issue6877@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

The readline-libedit-2.patch no longer applies against the 2.6 branch because of changes in setup.py since then.  If this is fixed and the subsequent patch is reviewed and approved, then this can be landed for Python 2.6.5.

----------

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

From report at bugs.python.org  Thu Feb  4 10:52:45 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Feb 2010 09:52:45 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265277165.59.0.074213152558.issue6877@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

release blocker for 2.6.5

----------
priority:  -> release blocker

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

From report at bugs.python.org  Thu Feb  4 10:52:49 2010
From: report at bugs.python.org (Marcin Bachry)
Date: Thu, 04 Feb 2010 09:52:49 +0000
Subject: [issue7788] segfault when deleting from a list using slice with very
	big `step' value
In-Reply-To: <1264531632.85.0.040390960633.issue7788@psf.upfronthosting.co.za>
Message-ID: <1265277169.82.0.290287586999.issue7788@psf.upfronthosting.co.za>


Marcin Bachry <hegel666 at gmail.com> added the comment:

I had odd problems matching line numbers reported by Windows compiler
to actual sources, so I used "gcc -Wextra" to produce (even more)
signedness warnings against Python 2.x r77957:

  listobject.c:132: warning: comparison between signed and unsigned integer expressions
  listobject.c:1435: warning: comparison between signed and unsigned integer expressions
  listobject.c:2639: warning: comparison between signed and unsigned integer expressions
  listobject.c:2655: warning: comparison between signed and unsigned integer expressions
  listobject.c:2661: warning: comparison between signed and unsigned integer expressions
  listobject.c:2670: warning: comparison between signed and unsigned integer expressions
  bytearrayobject.c:708: warning: comparison between signed and unsigned integer expressions
  bytearrayobject.c:716: warning: comparison between signed and unsigned integer expressions
  bytearrayobject.c:920: warning: comparison between signed and unsigned integer expressions
  arraymodule.c:745: warning: comparison between signed and unsigned integer expressions
  arraymodule.c:751: warning: comparison between signed and unsigned integer expressions
  arraymodule.c:835: warning: comparison between signed and unsigned integer expressions
  arraymodule.c:890: warning: comparison between signed and unsigned integer expressions
  arraymodule.c:1228: warning: comparison between signed and unsigned integer expressions
  arraymodule.c:1310: warning: comparison between signed and unsigned integer expressions
  arraymodule.c:1326: warning: comparison between signed and unsigned integer expressions
  arraymodule.c:1389: warning: comparison between signed and unsigned integer expressions
  arraymodule.c:1450: warning: comparison between signed and unsigned integer expressions
  arraymodule.c:1807: warning: comparison between signed and unsigned integer expressions
  arraymodule.c:1814: warning: comparison between signed and unsigned integer expressions

Most of them are due to comparisons between "size_t" variables and
Py_SIZE() macro which points to signed "ob_size" member of type
structure.  Because the sequence types above don't hold negative
numbers in "ob_size", I think we can silence the warnings by doing
explicit casts to "size_t".  Or we can ignore the warnings in
buildbot.  What do you think?

----------

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

From report at bugs.python.org  Thu Feb  4 10:54:17 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Feb 2010 09:54:17 +0000
Subject: [issue4978] allow unicode keyword args
In-Reply-To: <1232233645.86.0.929697154925.issue4978@psf.upfronthosting.co.za>
Message-ID: <1265277257.05.0.63343387001.issue4978@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

release blocker for 2.6.5

----------
priority:  -> release blocker

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

From report at bugs.python.org  Thu Feb  4 10:55:49 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Feb 2010 09:55:49 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265277349.82.0.103443859104.issue6877@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
status: closed -> open

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

From report at bugs.python.org  Thu Feb  4 11:09:46 2010
From: report at bugs.python.org (Albertas Agejevas)
Date: Thu, 04 Feb 2010 10:09:46 +0000
Subject: [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: <1265278186.73.0.809320739875.issue7848@psf.upfronthosting.co.za>


Albertas Agejevas <alga at pov.lt> added the comment:

This bug is a duplicate of issue6827, sorry.

----------

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

From report at bugs.python.org  Thu Feb  4 11:12:55 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Feb 2010 10:12:55 +0000
Subject: [issue4978] allow unicode keyword args
In-Reply-To: <1232233645.86.0.929697154925.issue4978@psf.upfronthosting.co.za>
Message-ID: <1265278375.36.0.755584535459.issue4978@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Why backport? Isn't this a new feature?

----------

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

From report at bugs.python.org  Thu Feb  4 11:27:08 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Feb 2010 10:27:08 +0000
Subject: [issue7847] Remove 'python -U' or document it
In-Reply-To: <1265218507.7.0.0697222778425.issue7847@psf.upfronthosting.co.za>
Message-ID: <1265279228.85.0.424126332966.issue7847@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This is really all I'm thinking about.

----------
keywords: +needs review, patch
stage:  -> patch review
versions: +Python 2.6
Added file: http://bugs.python.org/file16127/7847.patch

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

From report at bugs.python.org  Thu Feb  4 11:33:02 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 04 Feb 2010 10:33:02 +0000
Subject: [issue4978] allow unicode keyword args
In-Reply-To: <1232233645.86.0.929697154925.issue4978@psf.upfronthosting.co.za>
Message-ID: <1265279582.27.0.111855674196.issue4978@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Maybe not.  It's arguably a bug that adding unicode_literals breaks keyword arguments.  Guido seems to (mostly) agree that it's a bug we just never got around to fixing.

http://www.mail-archive.com/python-dev at python.org/msg45346.html

----------

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

From report at bugs.python.org  Thu Feb  4 11:47:54 2010
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 04 Feb 2010 10:47:54 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265280474.55.0.990716341206.issue6760@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Okay, now if this could just get dev review...

----------
Added file: http://bugs.python.org/file16128/subprocess.rst.patch

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

From report at bugs.python.org  Thu Feb  4 11:48:05 2010
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 04 Feb 2010 10:48:05 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265280485.07.0.947051289569.issue6760@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


Removed file: http://bugs.python.org/file16109/subprocess.rst.patch

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

From report at bugs.python.org  Thu Feb  4 12:31:11 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 04 Feb 2010 11:31:11 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265283071.67.0.605494162556.issue6760@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I think this is an improvement to the existing docs, and should be committed.

----------

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

From report at bugs.python.org  Thu Feb  4 12:49:02 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 04 Feb 2010 11:49:02 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1265284142.26.0.569537542202.issue5211@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Blair:  I don't think you'll have any problems getting the behaviour you in Python 3.  For example:

Python 3.2a0 (py3k:77952, Feb  4 2010, 10:56:12) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class xcomplex(complex):
...     def __add__(self, other): return xcomplex(complex(self) + other)
...     __radd__ = __add__
... 
>>> xz = xcomplex(1+2j)
>>> all(type(xz + y) is type(y + xz) is xcomplex for y in (1, 10.0, 10+1j, xz))
True

So I don't consider that the removal of coerce and the __coerce__ magic method is a step backward:  it still allows mixed-type operations, but without coerce the rules for those operations are significantly cleaner.

The real problem case in 2.6.4 seems to be when doing <instance of complex> + <instance of xcomplex>:  in this case, Python first calls complex.__coerce__ (which returns its arguments unchanged), then complex.__add__.  None of the xcomplex methods even gets a look in, so there's no opportunity to force the return type to be xcomplex.

If you look at the source (see particularly the binary_op1 function in Objects/abstract.c ) you can see where this behaviour is coming from.  The complex type (along with its subclasses) is classified as an 'old-style' number, while ints, longs and floats are 'new-style' (note that this has nothing to do with the distinction between old-style and new-style classes).  Operations between new-style numbers use the scheme described in the documentation, but where old-style numbers are involved there's an extra coercion step.  In particular, when adding a complex to an xcomplex, the rule you quoted (about the case when the right operand is an instance of a subclass of the class of the left operand) isn't applied.

It's too risky to change the general behaviour for old-style numbers:  I don't think there are any old-style numbers besides complex in the Python code, but there may well be some in third party extensions.  Certainly documenting it better would be an option, and making complex a new-style number for Python 2.7 seems like a reasonable thing to consider.

----------

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

From report at bugs.python.org  Thu Feb  4 12:52:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 04 Feb 2010 11:52:33 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1265284353.09.0.218910332522.issue5211@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> As you pointed out in issue 3734, the patch is basically:
> <snipped patch that adds Py_TPFLAGS_CHECKTYPES>

Yes, that's the essence of it.  In addition, each of the functions implementing a complex special method would need to do its own argument conversion.  (Compare the implementation of complex_add in py3k with that in trunk.)

----------

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

From report at bugs.python.org  Thu Feb  4 12:59:23 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 04 Feb 2010 11:59:23 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1265284763.15.0.00206477115021.issue5211@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Yes, that was what I was proposing.  But as you point out, the new
> behaviour wouldn't even match the behaviour of Python 3.x, so it really
> wouldn't be a terribly useful change.

Hmm.  I take this back:  if complex were made 'new-style' in 2.7, then it *would* be possible to write fairly obvious code (not using coerce or __coerce__) that operated in the same way in both 2.7 and 3.2.  So I still think it's worth considering.

----------

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

From report at bugs.python.org  Thu Feb  4 13:15:59 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 04 Feb 2010 12:15:59 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265285759.83.0.514711927114.issue6760@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Removed file: http://bugs.python.org/file16098/subprocess.rst.patch

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

From report at bugs.python.org  Thu Feb  4 13:29:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2010 12:29:41 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1265286581.39.0.56146023023.issue5677@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

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

From report at bugs.python.org  Thu Feb  4 13:41:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2010 12:41:29 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1265287289.65.0.691003150242.issue5677@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, test_file.py is for the new IO library (backported from 3.x). You should use test_file2k.py for tests against the 2.x file object.

Also, readinto() should take something such as a bytearray() as argument, not a string.

----------
versions: +Python 2.7

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

From report at bugs.python.org  Thu Feb  4 13:43:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2010 12:43:56 +0000
Subject: [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: <1265287436.8.0.475336919884.issue7848@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +alexandre.vassalotti

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

From report at bugs.python.org  Thu Feb  4 13:45:21 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 04 Feb 2010 12:45:21 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265287521.32.0.458116175999.issue6760@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Committed for 2.7 as r77959.

Still needs to be merged to the other branches.

----------
resolution:  -> accepted
status: open -> pending

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

From report at bugs.python.org  Thu Feb  4 13:47:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2010 12:47:08 +0000
Subject: [issue7853] on __exit__(), exc_value does not contain the exception.
In-Reply-To: <1265276109.88.0.802756804705.issue7853@psf.upfronthosting.co.za>
Message-ID: <1265287628.52.0.179638193867.issue7853@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed, it seems the exception isn't always normalized.

----------
nosy: +benjamin.peterson, pitrou

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

From report at bugs.python.org  Thu Feb  4 13:48:52 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Feb 2010 12:48:52 +0000
Subject: [issue7853] on __exit__(), exc_value does not contain the exception.
In-Reply-To: <1265276109.88.0.802756804705.issue7853@psf.upfronthosting.co.za>
Message-ID: <1265287732.84.0.720356882017.issue7853@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Has this behavior changed between 2.6 and 2.7?

----------

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

From report at bugs.python.org  Thu Feb  4 13:52:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2010 12:52:30 +0000
Subject: [issue7853] on __exit__(), exc_value does not contain the exception.
In-Reply-To: <1265276109.88.0.802756804705.issue7853@psf.upfronthosting.co.za>
Message-ID: <1265287950.25.0.0490846180026.issue7853@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

No, it's also in 2.6.

----------

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

From report at bugs.python.org  Thu Feb  4 14:15:27 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 04 Feb 2010 13:15:27 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265289327.64.0.466429606291.issue6760@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

When merging to py3k, don't forget to modify the print statement to be a function.

----------
status: pending -> open

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

From report at bugs.python.org  Thu Feb  4 17:21:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Feb 2010 16:21:42 +0000
Subject: [issue6827] deepcopy erroneously doesn't call __setstate__ if
	__getstate__ returns empty dict
In-Reply-To: <1251926992.64.0.823425954467.issue6827@psf.upfronthosting.co.za>
Message-ID: <1265300502.14.0.592186463189.issue6827@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The documentation also says, "if the object defines both a __getstate__ and a __setstate__ method, the state object does not need to be a dictionary and the methods can do what they want."  In issue 7848 (which I will close as a duplicate of this issue), the object wants to return a single integer as the state, and that integer can happen to be zero, so clearly "anything they want" is demonstrably not true.  Granted that this can also be worked around with a __new__ method, it feels like a broken API.  It unnecessarily complicates the implementation of objects that implement the protocol but whose state object can legitimately taken on a False value.  It also breaks the principle of least surprise for someone taking advantage of the "anything they want" clause (it may not occur to them that the 'black blox' state they are passing between their methods could take on a False value...and therefore break their code).

Since this was clearly a conscious choice for new-style classes, does anyone know why it was made?

----------
keywords: +easy
nosy: +r.david.murray
priority:  -> normal
status: pending -> open
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2 -Python 2.5

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

From report at bugs.python.org  Thu Feb  4 17:22:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Feb 2010 16:22:51 +0000
Subject: [issue6827] deepcopy erroneously doesn't call __setstate__ if
	__getstate__ returns empty dict
In-Reply-To: <1251926992.64.0.823425954467.issue6827@psf.upfronthosting.co.za>
Message-ID: <1265300571.22.0.918905511102.issue6827@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

At the very least the documentation should be updated to warn that cooperating __getstate__ and __setstate__ methods must make sure the state object can never take on a False value.

----------

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

From report at bugs.python.org  Thu Feb  4 17:23:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Feb 2010 16:23:53 +0000
Subject: [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: <1265300633.36.0.82200909122.issue7848@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
superseder:  -> deepcopy erroneously doesn't call __setstate__ if __getstate__ returns empty dict

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

From report at bugs.python.org  Thu Feb  4 17:44:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2010 16:44:02 +0000
Subject: [issue7728] test_timeout should use "find_unused_port" helper
In-Reply-To: <1263763659.44.0.532251726667.issue7728@psf.upfronthosting.co.za>
Message-ID: <1265301842.87.0.914222853728.issue7728@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you provide a patch?

----------
keywords: +easy
type:  -> behavior

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

From report at bugs.python.org  Thu Feb  4 17:49:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Feb 2010 16:49:43 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265302183.69.0.276309511315.issue6760@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Merged as part of r77961 (2.6), r77962 (py3k), and r77963 (3.1).  Print fixed for py3.

----------
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Feb  4 17:52:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Feb 2010 16:52:15 +0000
Subject: [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: <1265302335.16.0.350830780233.issue7851@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +vinay.sajip
priority:  -> normal
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Feb  4 17:52:30 2010
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 04 Feb 2010 16:52:30 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265302350.87.0.249528601387.issue6760@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Thanks to all for the copious feedback & suggestions, and R. David Murray for his superior docs writing skills!

----------

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

From report at bugs.python.org  Thu Feb  4 18:28:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 04 Feb 2010 17:28:09 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1265304489.0.0.272098385717.issue5341@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

I fixed a few remaining misuses of ?builtin? in the source. There is some diff noise due to reformatting paragraphs where the addition of the hyphen caused the line to get over 80 characters.

Note that I didn?t check the use of ?built-in?, for fear of having too much files to review.

I looked only in Doc. I?ve found misuses in other places, but reviewing the whole source would take more time than I had on my hands.

Please review.

Regards

----------
Added file: http://bugs.python.org/file16129/fix-builtin_2.7.diff

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

From report at bugs.python.org  Thu Feb  4 18:28:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 04 Feb 2010 17:28:39 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1265304519.23.0.264236381781.issue5341@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file16130/fix-builtin_3.2.diff

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

From report at bugs.python.org  Thu Feb  4 18:29:10 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 04 Feb 2010 17:29:10 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1265304550.55.0.652644946494.issue5341@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
status: closed -> open

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

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: [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 19:47:58 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 04 Feb 2010 18:47:58 +0000
Subject: [issue7854] term paper
In-Reply-To: <1265309227.46.0.140579300213.issue7854@psf.upfronthosting.co.za>
Message-ID: <1265309278.18.0.176248245174.issue7854@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Feb  4 19:48:18 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 04 Feb 2010 18:48:18 +0000
Subject: [issue7854] term paper
Message-ID: <1265309298.55.0.623584183985.issue7854@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------

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

From report at bugs.python.org  Thu Feb  4 20:17:11 2010
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 04 Feb 2010 19:17:11 +0000
Subject: [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  Thu Feb  4 20:17:58 2010
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 04 Feb 2010 19:17:58 +0000
Subject: [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: <1265311078.52.0.942828306944.issue7855@psf.upfronthosting.co.za>


Changes by Dino Viehland <dinov at microsoft.com>:


----------
type:  -> behavior
versions: +Python 3.2
Added file: http://bugs.python.org/file16132/patch30.diff

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

From report at bugs.python.org  Thu Feb  4 20:28:44 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 04 Feb 2010 19:28:44 +0000
Subject: [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: <1265311724.81.0.274929294711.issue7855@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Rather than calling QueryValue and using fail(...) if it doesn't throw, assertRaises(...) would do the trick.

----------
assignee: theller -> 
keywords: +needs review
nosy: +brian.curtin, michael.foord
priority:  -> normal
stage:  -> patch review

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

From report at bugs.python.org  Thu Feb  4 20:32:20 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 04 Feb 2010 19:32:20 +0000
Subject: [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: <1265311940.86.0.31772707969.issue7855@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Also assertEqual(..., True) can be replaced by assertTrue(...) (same for False and assertFalse).

----------
assignee:  -> theller
keywords:  -needs review
nosy: +ezio.melotti
priority: normal -> 
stage: patch review -> 

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

From report at bugs.python.org  Thu Feb  4 20:33:36 2010
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 04 Feb 2010 19:33:36 +0000
Subject: [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: <1265312016.18.0.722043391739.issue7855@psf.upfronthosting.co.za>


Dino Viehland <dinov at microsoft.com> added the comment:

The problem with assertRaises is I need to actually check the errno on the exception and assertRaises doesn't let me do that.

----------

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

From report at bugs.python.org  Thu Feb  4 20:33:43 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 04 Feb 2010 19:33:43 +0000
Subject: [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: <1265312023.85.0.48731478696.issue7855@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Hmm... assertTrue(...) is semantically different from assertEqual(True, ...).

----------

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

From report at bugs.python.org  Thu Feb  4 20:35:05 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 04 Feb 2010 19:35:05 +0000
Subject: [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: <1265312105.55.0.585574976814.issue7855@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Dino - if you use assertRaises as a context manager the exception is kept as an attribute on the context. You can make assertions about the exception after the with block has executed.

----------

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

From report at bugs.python.org  Thu Feb  4 20:38:35 2010
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 04 Feb 2010 19:38:35 +0000
Subject: [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: <1265312315.12.0.863816601688.issue7855@psf.upfronthosting.co.za>


Dino Viehland <dinov at microsoft.com> added the comment:

I'll switch to the context manager form in the 3.x branch - it looks like that's not available in the 2.x branch.

----------

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

From report at bugs.python.org  Thu Feb  4 20:48:14 2010
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 04 Feb 2010 19:48:14 +0000
Subject: [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: <1265312894.28.0.461054080201.issue7855@psf.upfronthosting.co.za>


Changes by Dino Viehland <dinov at microsoft.com>:


Added file: http://bugs.python.org/file16133/patch30.diff

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

From report at bugs.python.org  Thu Feb  4 20:49:17 2010
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 04 Feb 2010 19:49:17 +0000
Subject: [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: <1265312957.18.0.490144651818.issue7855@psf.upfronthosting.co.za>


Dino Viehland <dinov at microsoft.com> added the comment:

Ezio: I'm going to stick w/ assertEqual here as Michael points out these are different.  In particular I want to make sure that you can assign any true value to the ctypes field but when you read it back you get True or False regardless of the value assigned.

----------

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

From report at bugs.python.org  Thu Feb  4 21:11:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2010 20:11:19 +0000
Subject: [issue5673] Add timeout option to subprocess.Popen
In-Reply-To: <1265082449.69.0.261022562821.issue5673@psf.upfronthosting.co.za>
Message-ID: <1265314359.27288.1.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I agree.  Does subprocess.TimeoutExpired sound good?

Yes.

> It won't be possible with the current implementation to put the partial output
> in the exception, because read blocks.

Fair enough :)

> I think call and check_call should clean up after themselves by
> killing the child processes they create, while communicate and wait should leave
> that to the user.

It sounds good.

----------

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

From report at bugs.python.org  Thu Feb  4 21:15:09 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 04 Feb 2010 20:15:09 +0000
Subject: [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: <1265314509.37.0.639147660186.issue7855@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

For your purpose indeed assertTrue() is not appropriate, however assertEqual(x, True) works for several different x, including 1.0 or 1.
Also assertRaises can be used as a context manager on 2.7 too.

----------
priority:  -> normal
stage:  -> patch review

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

From report at bugs.python.org  Thu Feb  4 21:24:44 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 04 Feb 2010 20:24:44 +0000
Subject: [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: <1265315084.91.0.549449711511.issue7851@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into trunk (r77973).

----------
assignee: georg.brandl -> vinay.sajip

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

From report at bugs.python.org  Thu Feb  4 21:24:54 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 04 Feb 2010 20:24:54 +0000
Subject: [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: <1265315094.67.0.972287359982.issue7851@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Thu Feb  4 21:26:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Feb 2010 20:26:58 +0000
Subject: [issue4772] undesired switch fall-through in socketmodule.c
In-Reply-To: <1230582973.84.0.698923049603.issue4772@psf.upfronthosting.co.za>
Message-ID: <1265315218.51.0.773864863016.issue4772@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in all four branches, thank you.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Feb  4 21:58:56 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 04 Feb 2010 20:58:56 +0000
Subject: [issue7847] Remove 'python -U' or document it
In-Reply-To: <1265218507.7.0.0697222778425.issue7847@psf.upfronthosting.co.za>
Message-ID: <1265317136.39.0.723833461888.issue7847@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm +0 on such a change - I don't think it makes anything better (it will only cause more users asking what this is, why it was added, and demand that something should be done about it).

Feel free to commit it, anyway.

----------
assignee: loewis -> barry

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

From report at bugs.python.org  Thu Feb  4 22:02:27 2010
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 04 Feb 2010 21:02:27 +0000
Subject: [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: <1265317347.54.0.582511504154.issue7855@psf.upfronthosting.co.za>


Changes by Dino Viehland <dinov at microsoft.com>:


Added file: http://bugs.python.org/file16134/patch.diff

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

From report at bugs.python.org  Thu Feb  4 22:02:48 2010
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 04 Feb 2010 21:02:48 +0000
Subject: [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: <1265317368.94.0.512618063463.issue7855@psf.upfronthosting.co.za>


Changes by Dino Viehland <dinov at microsoft.com>:


Added file: http://bugs.python.org/file16135/patch30.diff

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

From report at bugs.python.org  Thu Feb  4 22:04:22 2010
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 04 Feb 2010 21:04:22 +0000
Subject: [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: <1265317462.34.0.120400219921.issue7855@psf.upfronthosting.co.za>


Dino Viehland <dinov at microsoft.com> added the comment:

Ahh, so it is in 2.7, apparently I was in a 2.6 enlistment.  I've updated the 2.x patch to use the context manager as well.

I've also switched to using assertTrue(x is True) and assertTrue(x is False) so that it's not checking precisely for the bool value based upon Ezio's feedback.

----------

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

From report at bugs.python.org  Thu Feb  4 22:24:57 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 04 Feb 2010 21:24:57 +0000
Subject: [issue7853] on __exit__(), exc_value does not contain the exception.
In-Reply-To: <1265276109.88.0.802756804705.issue7853@psf.upfronthosting.co.za>
Message-ID: <1265318697.9.0.258084007954.issue7853@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> benjamin.peterson

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

From report at bugs.python.org  Thu Feb  4 22:45:01 2010
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Thu, 04 Feb 2010 21:45:01 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265319901.18.0.258735217993.issue6877@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

The readline-libedit-2.6.5.patch is attached.

The patch was applied and python built in several configurations on Mac
OS X 10.6 (Snow Leopard).  There is no regression (details below).

Can somebody else test on Mac OS X 10.5 (Leopard)?

32-bit
======

Configuration with system libedit::

    ./configure --prefix=${HOME}/opt/snapshot/2.6.5 \
        BASECFLAGS="-arch i386" \
        CFLAGS="-arch i386" \
        LDFLAGS="-arch i386" \
        MACOSX_DEPLOYMENT_TARGET=10.6

Configuration with GNU readline 6.1::

    ./configure --prefix=${HOME}/opt/snapshot/gnurl/2.6.5 \
        BASECFLAGS="-arch i386" \
        CFLAGS="-arch i386" \
        CPPFLAGS="-I/opt/local/include" \
        LDFLAGS="-arch i386 -L/opt/local/lib" \
        MACOSX_DEPLOYMENT_TARGET=10.6

Failed tests for both builds:

- test_asynchat
- test_smtplib


64-bit
======

Configuration with system libedit::

    ./configure --prefix=${HOME}/opt/snapshot/2.6.5-64 \
        MACOSX_DEPLOYMENT_TARGET=10.6

Configuration with GNU readline 6.1::

    ./configure --prefix=${HOME}/opt/snapshot/gnurl/2.6.5-64 \
        CPPFLAGS="-I/opt/local/include" \
        LDFLAGS="-L/opt/local/lib" \
        MACOSX_DEPLOYMENT_TARGET=10.6checking

Failed tests for both builds:

- test_asynchat
- test_macostools
- test_smtplib

Unexpected skips:

- test_dl


Universal
=========

Configuration with system libedit::

    ./configure --prefix=${HOME}/opt/snapshot \
        BASECFLAGS="-arch x86_64 -arch i386" \
        CFLAGS="-arch x86_64 -arch i386" \
        LDFLAGS="-arch x86_64 -arch i386" \
        MACOSX_DEPLOYMENT_TARGET=10.6

Configuration with GNU readline 6.1::

    ./configure --prefix=${HOME}/opt/snapshot/gnurl \
        BASECFLAGS="-arch x86_64 -arch i386" \
        CFLAGS="-arch x86_64 -arch i386" \
        CPPFLAGS="-I/opt/local/include" \
        LDFLAGS="-arch x86_64 -arch i386 -L/opt/local/lib" \
        MACOSX_DEPLOYMENT_TARGET=10.6

Failed tests for both builds:

- test_asynchat
- test_macostools
- test_smtplib

Unexpected skips:

- test_dl

when run as 64-bit or 32-bit executable.

Errors in both asynchat and smtplib are caused by the same issue in
asyncore.py.  A typical error output::

    error: uncaptured python exception, closing channel
    <test.test_asynchat.echo_client at 0x1b112b0>
    (<class 'socket.error'>:[Errno 9]
     Bad file descriptor
     [/Users/zvezdan/opt/snapshot/2.6.5/lib/python2.6/asyncore.py|
      readwrite|107]
     [/Users/zvezdan/opt/snapshot/2.6.5/lib/python2.6/asyncore.py|
      handle_expt_event|441]
     [<string>|getsockopt|1]
     [/Users/zvezdan/opt/snapshot/2.6.5/lib/python2.6/socket.py|_dummy|165])

but this is not caused by readline patch.

----------
Added file: http://bugs.python.org/file16136/readline-libedit-2.6.5.patch

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

From report at bugs.python.org  Thu Feb  4 22:46:14 2010
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Thu, 04 Feb 2010 21:46:14 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265319974.12.0.852701086355.issue6877@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

I forgot to add that the patch for 2.6.5 is based on:
http://svn.python.org/view?rev=74970&view=rev

----------

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

From report at bugs.python.org  Fri Feb  5 01:40:16 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 05 Feb 2010 00:40:16 +0000
Subject: [issue7853] on __exit__(), exc_value does not contain the exception.
In-Reply-To: <1265276109.88.0.802756804705.issue7853@psf.upfronthosting.co.za>
Message-ID: <1265330416.21.0.440693978098.issue7853@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch.

----------
keywords: +patch
stage: test needed -> patch review
Added file: http://bugs.python.org/file16137/issue7853_cm_exit.diff

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

From report at bugs.python.org  Fri Feb  5 01:56:57 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 05 Feb 2010 00:56:57 +0000
Subject: [issue7728] test_timeout should use "find_unused_port" helper
In-Reply-To: <1263763659.44.0.532251726667.issue7728@psf.upfronthosting.co.za>
Message-ID: <1265331417.16.0.476573486958.issue7728@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file16138/issue7728_timeout.diff

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

From report at bugs.python.org  Fri Feb  5 02:00:31 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 05 Feb 2010 01:00:31 +0000
Subject: [issue7847] Remove 'python -U' or document it
In-Reply-To: <1265218507.7.0.0697222778425.issue7847@psf.upfronthosting.co.za>
Message-ID: <1265331631.52.0.764331157696.issue7847@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

If you document -X, you should also document -J.

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Fri Feb  5 03:12:54 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Feb 2010 02:12:54 +0000
Subject: [issue7853] on __exit__(), exc_value does not contain the exception.
In-Reply-To: <1265276109.88.0.802756804705.issue7853@psf.upfronthosting.co.za>
Message-ID: <1265335974.56.0.118301243734.issue7853@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Fixed in r77983.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Feb  5 04:57:34 2010
From: report at bugs.python.org (Gabriel Genellina)
Date: Fri, 05 Feb 2010 03:57:34 +0000
Subject: [issue5680] Command-line arguments when running in IDLE
In-Reply-To: <1238798556.38.0.28468201552.issue5680@psf.upfronthosting.co.za>
Message-ID: <1265342254.41.0.459949907625.issue5680@psf.upfronthosting.co.za>


Gabriel Genellina <gagsl-py2 at yahoo.com.ar> added the comment:

A different patch to solve the same issue.
This one uses a standard tkSimpleDialog to prompt for the command line, and follows the directives found at the top of the source (only took 8 years to implement... not so bad :) )

XXX GvR Redesign this interface (yet again) as follows:

- Present a dialog box for ``Run Module''

- Allow specify command line arguments in the dialog box

----------
nosy: +gagenellina
Added file: http://bugs.python.org/file16139/issue5680-patch2.diff

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

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: [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 06:16:17 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 05 Feb 2010 05:16:17 +0000
Subject: [issue7856] cannot decode from or encode to big5 \xf9\xd8
In-Reply-To: <1265346469.79.0.269704961777.issue7856@psf.upfronthosting.co.za>
Message-ID: <1265346977.53.0.522449575097.issue7856@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

That iconv supports it is not convincing, IMO. Do you have other sources (like tables in the web somewhere) that support your request?

----------
nosy: +loewis

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

From report at bugs.python.org  Fri Feb  5 06:41:50 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 05 Feb 2010 05:41:50 +0000
Subject: [issue7856] cannot decode from or encode to big5 \xf9\xd8
In-Reply-To: <1265346469.79.0.269704961777.issue7856@psf.upfronthosting.co.za>
Message-ID: <1265348510.76.0.83842848153.issue7856@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

In particular, the Unicode consortium mapping table, now at

http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/OTHER/BIG5.TXT

doesn't map f9d8 to anything; the current version of that table (in unihan.zip) has these mappings for U+88CF:

U+88CF	kCCCII	232E61
U+88CF	kCNS1986	E-444E
U+88CF	kCNS1992	3-444E
U+88CF	kEACC	215763
U+88CF	kGB1	3279
U+88CF	kHKSCS	F9D8
U+88CF	kJis0	4602
U+88CF	kKPS0	D9E0
U+88CF	kKSC0	5574
U+88CF	kTaiwanTelegraph	5937
U+88CF	kXerox	241:102

As you can see, it isn't supported in big5.

----------

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

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


Xuefer x <xuefer at gmail.com> added the comment:

sure after enlighten by your url which is OBSOLETE
see: http://www.unicode.org/Public/MAPPINGS/EASTASIA/ReadMe.txt
i found http://unicode.org/charts/unihan.html
then http://www.unicode.org/Public/UNIDATA/
then http://www.unicode.org/Public/UNIDATA/Unihan.zip
in side the zip, open Unihan_OtherMappings.txt
big 5 includes
#	kBigFive
#	kHKSCS
which are listed in Unihan_OtherMappings.txt
HKSCS is one of the big-5 encoding
and i search for F9D8 got
U+88CF	kHKSCS	F9D8

you may also want to update other encoding map table to catch up with Unihan_OtherMappings.txt

thanks for your quick reply btw

----------

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

From report at bugs.python.org  Fri Feb  5 07:23:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 05 Feb 2010 06:23:04 +0000
Subject: [issue7856] cannot decode from or encode to big5 \xf9\xd8
In-Reply-To: <1265346469.79.0.269704961777.issue7856@psf.upfronthosting.co.za>
Message-ID: <1265350984.22.0.949256275122.issue7856@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

perky, what do you think?

----------
assignee:  -> hyeshik.chang
nosy: +hyeshik.chang

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

From report at bugs.python.org  Fri Feb  5 14:31:13 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 05 Feb 2010 13:31:13 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1265376673.27.0.744618062324.issue5677@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Thanks Antoine, I fixed both issues.

----------
Added file: http://bugs.python.org/file16140/add-readable-writable2.patch

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

From report at bugs.python.org  Fri Feb  5 14:55:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Feb 2010 13:55:43 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1265378143.38.0.0579264942601.issue5677@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oh and the following line shouldn't be needed:

data = b'xxx' if 'b' in mode else u'xxx'

Since old-style file objects always take bytestrings (it's harmless, though, because the unicode string will be implicitly converted).

----------

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

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: [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 15:14:50 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 05 Feb 2010 14:14:50 +0000
Subject: [issue7857] test_logging fails
In-Reply-To: <1265378336.27.0.807146257248.issue7857@psf.upfronthosting.co.za>
Message-ID: <1265379290.42.0.527444860244.issue7857@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

It could take benefit of "test_support.find_unused_port".

----------
components: +Library (Lib)
keywords: +buildbot
nosy: +flox

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

From report at bugs.python.org  Fri Feb  5 15:35:24 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 05 Feb 2010 14:35:24 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1265380524.31.0.0529188676477.issue5677@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Ok, I'll fix that. Perhaps I should also remove the comment in err_mode(). I wonder if the ValueError in fileio.c is intentional:

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

----------

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

From report at bugs.python.org  Fri Feb  5 15:48:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Feb 2010 14:48:02 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1265381282.59.0.257610778878.issue5677@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I wonder if the ValueError in fileio.c is intentional:

I don't know, but this would be the subject of a separate issue anyway.

----------

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

From report at bugs.python.org  Fri Feb  5 15:54:15 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 05 Feb 2010 14:54:15 +0000
Subject: [issue7857] test_logging fails
In-Reply-To: <1265378336.27.0.807146257248.issue7857@psf.upfronthosting.co.za>
Message-ID: <1265381655.97.0.876912008044.issue7857@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix checked into trunk with following changes:
  - use of test_support.find_unused_port()
  - if connection is refused, a finally clause shuts down the server thread.

Marked as pending awaiting testing of these changes on buildbots.

----------
resolution:  -> fixed
status: open -> pending

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

From report at bugs.python.org  Fri Feb  5 16:56:29 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 05 Feb 2010 15:56:29 +0000
Subject: [issue7857] test_logging fails
In-Reply-To: <1265378336.27.0.807146257248.issue7857@psf.upfronthosting.co.za>
Message-ID: <1265385389.72.0.428547560564.issue7857@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Further update done to disable listening tests for now (r77986). Will try to investigate these - the trouble is, they work on my system :-(

----------
status: pending -> open

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

From report at bugs.python.org  Fri Feb  5 17:00:44 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 05 Feb 2010 16:00:44 +0000
Subject: [issue5498] Can SGMLParser properly handle <empty/> tags?
In-Reply-To: <1237288775.97.0.464945533476.issue5498@psf.upfronthosting.co.za>
Message-ID: <1265385644.63.0.562530158086.issue5498@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
priority:  -> normal
resolution:  -> invalid
stage: test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Feb  5 17:02:17 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 05 Feb 2010 16:02:17 +0000
Subject: [issue7857] test_logging fails
In-Reply-To: <1265378336.27.0.807146257248.issue7857@psf.upfronthosting.co.za>
Message-ID: <1265385737.46.0.388890714287.issue7857@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

You may use the decorator @unittest.skip("see issue #7857") for these tests, until it's fixed.
(or @unittest.expectedFailure, if you want to run them anyway)

http://docs.python.org/dev/library/unittest.html#unittest.skip

----------

_______________________________________
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: [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 17:12:35 2010
From: report at bugs.python.org (Chris Rebert)
Date: Fri, 05 Feb 2010 16:12:35 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265386355.65.0.428227957778.issue6760@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

One problem with the 3.x versions: the raw_input() should be input().

----------

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

From report at bugs.python.org  Fri Feb  5 17:23:31 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 05 Feb 2010 16:23:31 +0000
Subject: [issue5498] Can SGMLParser properly handle <empty/> tags?
In-Reply-To: <1237288775.97.0.464945533476.issue5498@psf.upfronthosting.co.za>
Message-ID: <1265387011.82.0.7508238103.issue5498@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Fri Feb  5 17:24:55 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 05 Feb 2010 16:24:55 +0000
Subject: [issue7844] Add -3 warning for absolute imports.
In-Reply-To: <1265205081.99.0.588324125272.issue7844@psf.upfronthosting.co.za>
Message-ID: <1265387095.88.0.267412006145.issue7844@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> needs patch
type:  -> feature request

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

From report at bugs.python.org  Fri Feb  5 17:28:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Feb 2010 16:28:05 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1265387285.67.0.134218750218.issue6760@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for catching that.  Fixed r77987 r77988.

----------

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

From report at bugs.python.org  Fri Feb  5 17:38:23 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 05 Feb 2010 16:38:23 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1265387903.72.0.139662340115.issue5677@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Added file: http://bugs.python.org/file16141/add-readable-writable3.patch

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

From report at bugs.python.org  Fri Feb  5 17:57:18 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 05 Feb 2010 16:57:18 +0000
Subject: [issue850997] mbcs encoding ignores errors
Message-ID: <1265389038.78.0.896770256594.issue850997@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
versions: +Python 2.7, Python 3.2

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

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: [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 18:03:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Feb 2010 17:03:45 +0000
Subject: [issue7859] support "with self.assertRaises(SomeException) as exc:"
	syntax
In-Reply-To: <1265389329.54.0.487777722436.issue7859@psf.upfronthosting.co.za>
Message-ID: <1265389425.39.0.0779057335225.issue7859@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You can't get the exception before it is even raised...

----------
nosy: +pitrou

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

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


Florent Xicluna <laxyf at yahoo.fr> added the comment:

right, but it could return a wrapper object which receives the exception on __exit__.

----------

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

From report at bugs.python.org  Fri Feb  5 18:13:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Feb 2010 17:13:42 +0000
Subject: [issue5677] Serious interpreter crash and/or arbitrary memory leak
	using .read() on writable file
In-Reply-To: <1238721884.54.0.371516304831.issue5677@psf.upfronthosting.co.za>
Message-ID: <1265390022.04.0.859127119989.issue5677@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch was committed in r77989 (trunk) and r77990 (2.6). Thank you Stefan!

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

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

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


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch

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

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


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed. In that case, I am all for it.

----------

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

From report at bugs.python.org  Fri Feb  5 18:27:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Feb 2010 17:27:00 +0000
Subject: [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: <1265390820.98.0.0521082505358.issue7858@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks like a missing "goto done" in posix_utime(), posixmodule.c, line 2805. Could you test the following patch?

----------
keywords: +patch
nosy: +pitrou
priority:  -> normal
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5
Added file: http://bugs.python.org/file16142/win_utime.patch

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

From report at bugs.python.org  Fri Feb  5 18:33:32 2010
From: report at bugs.python.org (Damien Elmes)
Date: Fri, 05 Feb 2010 17:33:32 +0000
Subject: [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: <1265391212.08.0.542229545424.issue7858@psf.upfronthosting.co.za>


Damien Elmes <resolver at gmail.com> added the comment:

I'm afraid I don't have a Windows build environment handy, but a quick look at the function in question seems to indicate that is the problem. Thanks for the quick reply!

----------

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

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


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Too clever by far.

----------
nosy: +rhettinger

_______________________________________
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: [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 19:21:49 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 05 Feb 2010 18:21:49 +0000
Subject: [issue7847] Remove 'python -U' or document it
In-Reply-To: <1265218507.7.0.0697222778425.issue7847@psf.upfronthosting.co.za>
Message-ID: <1265394109.83.0.567347699223.issue7847@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Good point Georg.  See updated patch.

----------
Added file: http://bugs.python.org/file16144/7847-2.patch

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

From report at bugs.python.org  Fri Feb  5 19:22:19 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 05 Feb 2010 18:22:19 +0000
Subject: [issue7847] Remove 'python -U' or document it
In-Reply-To: <1265218507.7.0.0697222778425.issue7847@psf.upfronthosting.co.za>
Message-ID: <1265394139.26.0.582368071602.issue7847@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Martin, thanks.

----------

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

From report at bugs.python.org  Fri Feb  5 19:28:54 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 05 Feb 2010 18:28:54 +0000
Subject: [issue7852] [PATCH] Drop "Computer" from "Apple Computer" in plistlib
In-Reply-To: <1265274130.06.0.273637901356.issue7852@psf.upfronthosting.co.za>
Message-ID: <1265394534.81.0.218846027205.issue7852@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I did a quick search and couldn't find any reference about this change, the examples in the apple doc still use 'Apple Computer'.
Do you have any reference that says that the correct doctype (now) uses only 'Apple'?

----------
nosy: +ezio.melotti
priority:  -> low
stage:  -> patch review

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

From report at bugs.python.org  Fri Feb  5 19:52:48 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 05 Feb 2010 18:52:48 +0000
Subject: [issue7847] Remove 'python -U' or document it
In-Reply-To: <1265218507.7.0.0697222778425.issue7847@psf.upfronthosting.co.za>
Message-ID: <1265395968.38.0.982800071895.issue7847@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

trunk: r77992
py26: r77993

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Feb  5 20:16:21 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 05 Feb 2010 19:16:21 +0000
Subject: [issue7250] wsgiref.handlers.CGIHandler caches os.environ,
	leaking info between requests
In-Reply-To: <1257147245.14.0.668660104401.issue7250@psf.upfronthosting.co.za>
Message-ID: <1265397381.55.0.780998777511.issue7250@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Phillip, can you fix this in 2.6, 2.7, 3.1 and trunk? (There are certain rules for merging fixes between branches but I don't recall the details. Contact Benjamin or another active core developer via IRC if you need help.)

----------
nosy: +gvanrossum

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

From report at bugs.python.org  Fri Feb  5 20:16:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Feb 2010 19:16:55 +0000
Subject: [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: <1265397415.76.0.503902193783.issue7860@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +lemburg

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

From report at bugs.python.org  Fri Feb  5 20:20:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Feb 2010 19:20:33 +0000
Subject: [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: <1265397633.7.0.313834059874.issue7860@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's also inconsistent with Linux behaviour:

>>> import sys 
>>> sys.maxsize
2147483647
>>> import platform
>>> platform.machine()
'x86_64'
>>> platform.architecture()
('32bit', 'ELF')

(on a Python compiled with "-m32" on a 64-bit Linux)

----------
nosy: +pitrou

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

From report at bugs.python.org  Fri Feb  5 20:23:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Feb 2010 19:23:06 +0000
Subject: [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: <1265397786.69.0.115648884629.issue7860@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The test could simply check that platform.machine() never returns "x86" when sys.maxsize is greater than 2**32.
(and it would even be platform-agnostic)

----------

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

From report at bugs.python.org  Fri Feb  5 20:34:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Feb 2010 19:34:26 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1265398466.18.0.535219377127.issue5341@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Additional note to help reviewing: I changed occurrences of the form ?builtin x? to ?built-in function x? not because I think the noun ?builtin? is incorrect, as you may guess from my first message in this thread, but because it seemed more readable for beginners. If core devs disagree for some reason I?ll back out these changes.

About the change from ?the builtin set function? to ?the built-in set class?: I stumbled about this occurrence and fixed it, but haven?t looked at the rest of the docs. Tell me if this belongs in a separate, more complete patch.

----------

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

From report at bugs.python.org  Fri Feb  5 20:35:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Feb 2010 19:35:29 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1265398529.07.0.191850408685.issue6715@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There's a Python binding for some lzma lib here: https://launchpad.net/pyliblzma

----------

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

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: [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 20:39:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Feb 2010 19:39:23 +0000
Subject: [issue5689] please support lzma compression as an extension and
	in	the tarfile module
In-Reply-To: <1238861315.81.0.348941469726.issue5689@psf.upfronthosting.co.za>
Message-ID: <1265398763.83.0.0442703276065.issue5689@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Merwok

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

From report at bugs.python.org  Fri Feb  5 20:39:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Feb 2010 19:39:41 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1265398781.88.0.985465287477.issue6715@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Merwok

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

From report at bugs.python.org  Fri Feb  5 20:39:56 2010
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Fri, 05 Feb 2010 19:39:56 +0000
Subject: [issue7807] test_macostools fails on OS X 10.6: no attribute 'FSSpec'
In-Reply-To: <1264787865.0.0.0322335198663.issue7807@psf.upfronthosting.co.za>
Message-ID: <1265398796.39.0.541074930033.issue7807@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

This seems to be a 64-bit issue.

The 32-bit build passes this test.

>>> echo ${TESTPYTHON} ${TESTPROG} ${TESTOPTS}
/Users/zvezdan/opt/snapshot/2.6.5/bin/python -E -tt /Users/zvezdan/opt/snapshot/2.6.5/lib/python2.6/test/test_macostools.py -l -uall

>>> ${TESTPYTHON} ${TESTPROG} ${TESTOPTS}
test_copy (__main__.TestMacostools) ... ok
test_mkalias (__main__.TestMacostools) ... ok
test_mkalias_relative (__main__.TestMacostools) ... ok
test_touched (__main__.TestMacostools) ... ok

----------------------------------------------------------------------
Ran 4 tests in 0.013s

OK

When 64-bit build is used:

>>> echo ${TESTPYTHON} ${TESTPROG} ${TESTOPTS}
/Users/zvezdan/opt/snapshot/2.6.5-64/bin/python -E -tt /Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/test/test_macostools.py -l -uall


>>> ${TESTPYTHON} ${TESTPROG} ${TESTOPTS}
test_copy (__main__.TestMacostools) ... ERROR
test_mkalias (__main__.TestMacostools) ... ERROR
test_mkalias_relative (__main__.TestMacostools) ... ERROR
test_touched (__main__.TestMacostools) ... ok

======================================================================
ERROR: test_copy (__main__.TestMacostools)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/test/test_macostools.py", line 65, in test_copy
    macostools.copy(test_support.TESTFN, TESTFN2)
  File "/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/plat-mac/macostools.py", line 114, in copy
    srcfss = File.FSSpec(src)
AttributeError: 'module' object has no attribute 'FSSpec'

======================================================================
ERROR: test_mkalias (__main__.TestMacostools)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/test/test_macostools.py", line 73, in test_mkalias
    macostools.mkalias(test_support.TESTFN, TESTFN2)
  File "/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/plat-mac/macostools.py", line 46, in mkalias
    dstfsr, dstfss = Res.FSCreateResourceFile(dstdirfsr, unicode(dstname),
AttributeError: 'module' object has no attribute 'FSCreateResourceFile'

======================================================================
ERROR: test_mkalias_relative (__main__.TestMacostools)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/test/test_macostools.py", line 88, in test_mkalias_relative
    macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix)
  File "/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/plat-mac/macostools.py", line 46, in mkalias
    dstfsr, dstfss = Res.FSCreateResourceFile(dstdirfsr, unicode(dstname),
AttributeError: 'module' object has no attribute 'FSCreateResourceFile'

----------------------------------------------------------------------
Ran 4 tests in 0.016s

FAILED (errors=3)
Traceback (most recent call last):
  File "/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/test/test_macostools.py", line 101, in <module>
    test_main()
  File "/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/test/test_macostools.py", line 97, in test_main
    test_support.run_unittest(TestMacostools)
  File "/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/test/test_support.py", line 734, in run_unittest
    _run_suite(suite)
  File "/Users/zvezdan/opt/snapshot/2.6.5-64/lib/python2.6/test/test_support.py", line 717, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: multiple errors occurred

----------
nosy: +zvezdan

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

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


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +benjamin.peterson, ezio.melotti, mark.dickinson
priority:  -> normal
stage:  -> needs patch
type: compile error -> feature request

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

From report at bugs.python.org  Fri Feb  5 20:43:31 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 05 Feb 2010 19:43:31 +0000
Subject: [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: <1265399011.48.0.167463987515.issue7860@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

The patch looks ok. Since we are emulating the Unix uname() function here, we might as well mimic its inconsistencies.

Note that platform.machine() and platform.processor() are not really very reliable ways of determining the machine type or processor.

----------

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

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


Thomas Spura <tomspur at fedoraproject.org> added the comment:

#2446 should be related to this one.

----------
nosy: +David Wolever

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

From report at bugs.python.org  Fri Feb  5 20:53:44 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 05 Feb 2010 19:53:44 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265399624.46.0.887687427005.issue6877@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This worked fine on OS X 10.6, but failed on OS X 10.5:

gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/Users/barry/projects/python/python26/./Include -I/Users/barry/projects/python/python26/./Mac/Include -I. -IInclude -I./Include -I/usr/local/include -I/Users/barry/projects/python/python26/Include -I/Users/barry/projects/python/python26 -c /Users/barry/projects/python/python26/Modules/readline.c -o build/temp.macosx-10.3-ppc-2.6/Users/barry/projects/python/python26/Modules/readline.o
/Users/barry/projects/python/python26/Modules/readline.c:41: error: conflicting types for 'completion_matches'
/usr/include/readline/readline.h:172: error: previous declaration of 'completion_matches' was here
/Users/barry/projects/python/python26/Modules/readline.c: In function 'py_remove_history':
/Users/barry/projects/python/python26/Modules/readline.c:378: warning: passing argument 1 of 'free' discards qualifiers from pointer target type
/Users/barry/projects/python/python26/Modules/readline.c: In function 'py_replace_history':
/Users/barry/projects/python/python26/Modules/readline.c:415: warning: passing argument 1 of 'free' discards qualifiers from pointer target type
/Users/barry/projects/python/python26/Modules/readline.c: In function 'call_readline':
/Users/barry/projects/python/python26/Modules/readline.c:1032: warning: assignment discards qualifiers from pointer target type
/Users/barry/projects/python/python26/Modules/readline.c:1035: warning: assignment discards qualifiers from pointer target type

Failed to find the necessary bits to build these modules:
_bsddb             gdbm               linuxaudiodev   
ossaudiodev        spwd               sunaudiodev     
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
readline                                              

running build_scripts
@bytor[~/projects/python/python26:1011]%

----------

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

From report at bugs.python.org  Fri Feb  5 21:00:39 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 05 Feb 2010 20:00:39 +0000
Subject: [issue7861] 2to3: "import foo" ->  "from . import foo"
In-Reply-To: <1265398652.17.0.813820450189.issue7861@psf.upfronthosting.co.za>
Message-ID: <1265400039.94.0.127728931154.issue7861@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +dmalcolm

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

From report at bugs.python.org  Fri Feb  5 21:30:47 2010
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Fri, 05 Feb 2010 20:30:47 +0000
Subject: [issue7852] [PATCH] Drop "Computer" from "Apple Computer" in plistlib
In-Reply-To: <1265274130.06.0.273637901356.issue7852@psf.upfronthosting.co.za>
Message-ID: <1265401847.01.0.799889807829.issue7852@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

How about this example from Mac OS X Reference Library "Property List Programming Guide":

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/PropertyLists/QuickStartPlist/QuickStartPlist.html

Perhaps the fact that Apple officially changed the name from "Apple Computer" to "Apple" back in 2007 also helps:

http://www.macworld.com/article/54770/2007/01/applename.html

This one had a short URL, you can search Google for "apple computer changes name" for more (Forbes, Information Week, etc.)

Do you have a reference where Apple docs written after 2007 use "Apple Computer"?

----------
nosy: +zvezdan

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

From report at bugs.python.org  Fri Feb  5 21:44:28 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Feb 2010 20:44:28 +0000
Subject: [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: <1265402668.44.0.915815402754.issue7829@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The doc begins
"30.12. dis ? Disassembler for Python bytecode
The dis module supports the analysis of Python bytecode by disassembling it. Since there is no Python assembler, this module defines the Python assembly language. The Python bytecode which this module takes as an input is defined in the file Include/opcode.h and used by the compiler and the interpreter."

This goes back to when python.exe (CPython) was the only implementation. "Python bytecode" is no longer appropriate. It should be changed to CPython bytecode. My suggestion for a possible update:

30.12. dis ? Disassembler for CPython bytecode
CPython currently compiles Python source code to a custom bytecode that is defined by the CPytyon source file Include/opcode.h and explained below. While such implementation details are subject to change in any CPython x.y version, the dis module supports the analysis of current bytecode by disassembling it to a format similar to assembly language."

Calling it an actual assembly language, as the current doc does, implies to me that there is/should be an assembler (which Guido has said there should not be).

"30.12.1. Python Bytecode Instructions
The Python compiler ..."

Python -> CPython

In the glossary:
"bytecode 
Python source code is compiled into bytecode, the internal representation of a Python program in the interpret"
=> something like
"bytecode
CPython currently compiles Python source code to an internal bytecode representation that it uses to execute the program. Some other implementations do something similar."

These suggestions touch on the larger issue of differentiating and disentangling language doc from CPython implementation doc. I support this even though I have never used any of the other implementations.

----------
nosy: +tjreedy

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

From report at bugs.python.org  Fri Feb  5 21:44:32 2010
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Fri, 05 Feb 2010 20:44:32 +0000
Subject: [issue7852] [PATCH] Drop "Computer" from "Apple Computer" in plistlib
In-Reply-To: <1265274130.06.0.273637901356.issue7852@psf.upfronthosting.co.za>
Message-ID: <1265402672.68.0.0506968641841.issue7852@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

Also, on a Mac computer:

- start Xcode 3.2.1 and select Help->Developer Documentation
- type in the search box in the top right corner "property list"
- the second hit is "Property List Programming Guide"; click on it
- the second page gives the same example as the URL I put in msg98905
- it uses DOCTYPE with /Apple/ only

----------

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

From report at bugs.python.org  Fri Feb  5 22:01:56 2010
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Fri, 05 Feb 2010 21:01:56 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265403716.19.0.471323796253.issue6877@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

This is a configuration bug:

/Users/barry/projects/python/python26/Modules/readline.c -o build/temp.macosx-10.3-ppc-2.6 ...

Why is it trying to build using macosx-10.3 target?
I bet if you specify MACOSX_DEPLOYMENT_TARGET=10.5 on the ./configure line it will work fine.  It worked for me when I used Leopard (until September 2009).

This is a bug in configure.in

----------

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

From report at bugs.python.org  Fri Feb  5 22:24:55 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 05 Feb 2010 21:24:55 +0000
Subject: [issue7852] [PATCH] Drop "Computer" from "Apple Computer" in plistlib
In-Reply-To: <1265274130.06.0.273637901356.issue7852@psf.upfronthosting.co.za>
Message-ID: <1265405095.32.0.273727165175.issue7852@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ronaldoussoren

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

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: [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  Fri Feb  5 22:41:31 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 05 Feb 2010 21:41:31 +0000
Subject: [issue4722] _winreg.QueryValue fault while reading mangled registry
	values
In-Reply-To: <1229958391.62.0.85659959701.issue4722@psf.upfronthosting.co.za>
Message-ID: <1265406091.54.0.522543729529.issue4722@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file15960/issue4722.diff

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

From report at bugs.python.org  Fri Feb  5 22:51:31 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 05 Feb 2010 21:51:31 +0000
Subject: [issue7030] Update version{added,
	changed} entries in py3k unittest docs
In-Reply-To: <1254427741.8.0.290853000948.issue7030@psf.upfronthosting.co.za>
Message-ID: <1265406691.09.0.222277561963.issue7030@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

assertSameElements doc issue fixed in revision 77997. Also improved example for assertRaises as a context manager and added versionadded to the test skipping section. Revisions 77999-78002.

Thanks for sorting the version changed / added in the Py3k docs Ezio.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Feb  5 22:54:40 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 05 Feb 2010 21:54:40 +0000
Subject: [issue7856] cannot decode from or encode to big5 \xf9\xd8
In-Reply-To: <1265346469.79.0.269704961777.issue7856@psf.upfronthosting.co.za>
Message-ID: <1265406880.4.0.107876040075.issue7856@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

> That iconv supports it is not convincing, ...

GNU libc is not convincing . What you talking about ?

----------
nosy: +rpetrov

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

From report at bugs.python.org  Fri Feb  5 22:54:48 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Feb 2010 21:54:48 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265406888.94.0.46797012598.issue6877@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

It's not a configuration bug.  All current python.org python installers are built with MACOSX_DEPLOYMENT_TARGET=10.3 and with the 10.4u SDK to allow one installer to work on systems from 10.3.9 through 10.6.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Fri Feb  5 22:56:22 2010
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Fri, 05 Feb 2010 21:56:22 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265406982.59.0.573757879597.issue6877@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

Barry,

I'm sorry, I only now noticed this line in your compilation on 10.5:

/Users/barry/projects/python/python26/Modules/readline.c:41: error: conflicting types for 'completion_matches'

This problem was introduced by a patch in issue4204.
See my comments in msg82619 and msg92482.
They've been ignored because the issue was closed, and I did not have a right to reopen it.

Please notice that my original patch attached here (readline-trunk.patch) has this part in it, which is very important for 10.5:

@@ -6,6 +6,7 @@
 
 /* Standard definitions */
 #include "Python.h"
+#include <stdlib.h>
 #include <setjmp.h>
 #include <signal.h>
 #include <errno.h>

Ronald has omitted that part when he was changing the patch and I completely forgot about its importance since I'm running 10.6 and did not have problems.

Initially my first version of the patch was checking for __APPLE__ and avoided to re-define completion_matches on lines 35-36.  I used that patch when 2.6.1 came out in my personal builds. 

Then I found out that including stdlib early avoided the problem.

I really do not have a 10.5 machine to test on now.
Can you please try inserting that include <stdlib.h> and see if 10.5 builds readline?

If yes, I'd be glad to make a new patch against 2.6 branch and trunk/3.x branch (probably need the same include line).

If not, then we need to make a choice of #ifdef __FreeBSD__ as I suggested in issue4204, or #ifndef __APPLE__ as I used in my first personal version of the patch.

The problem with re-definition of completion_matches did not exist in 2.4 and 2.5 and is definitely introduced by a patch in issue 4204, which annoyed me because it broke a modern OS to support a very old version of FreeBSD (4.x).
:-)

<aside note>
That said, I still think that configure.in should not treat 10.5 as 10.3 because Leopard was a big change to the UNIX 2003 specification and too many things are different between 10.3/10.4 and 10.5/10.6.

We had a discussion on pythonmac-sig about it and people mostly agreed but I do not remember if any issue was opened in the tracker to act on it or not.
</aside note>

----------

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

From report at bugs.python.org  Fri Feb  5 22:58:01 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 05 Feb 2010 21:58:01 +0000
Subject: [issue7030] Update version{added,
	changed} entries in py3k unittest docs
In-Reply-To: <1254427741.8.0.290853000948.issue7030@psf.upfronthosting.co.za>
Message-ID: <1265407081.94.0.0982548917755.issue7030@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

You should thank Georg for those, I just fixed the examples in r77968. ;)

----------
stage: needs patch -> committed/rejected

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

From report at bugs.python.org  Fri Feb  5 23:25:36 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 05 Feb 2010 22:25:36 +0000
Subject: [issue7501] python -m unittest path_to_suite_function errors
In-Reply-To: <1260742792.63.0.561457576654.issue7501@psf.upfronthosting.co.za>
Message-ID: <1265408736.17.0.444758801778.issue7501@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

What made you think that would work? In your example foo.test_suite is neither a test nor a suite but a function.

----------

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

From report at bugs.python.org  Fri Feb  5 23:34:56 2010
From: report at bugs.python.org (Wang Chun)
Date: Fri, 05 Feb 2010 22:34:56 +0000
Subject: [issue7852] [PATCH] Drop "Computer" from "Apple Computer" in plistlib
In-Reply-To: <1265274130.06.0.273637901356.issue7852@psf.upfronthosting.co.za>
Message-ID: <1265409296.64.0.523827910389.issue7852@psf.upfronthosting.co.za>


Wang Chun <yaohua2000 at gmail.com> added the comment:

plutil is a command shipped with every Mac. See the example in my original post.

----------

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

From report at bugs.python.org  Fri Feb  5 23:35:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Feb 2010 22:35:01 +0000
Subject: [issue7862] fileio.c: ValueError vs. IOError with impossible
	operations
In-Reply-To: <1265405300.06.0.973184216127.issue7862@psf.upfronthosting.co.za>
Message-ID: <1265409301.44.0.910199033906.issue7862@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Sat Feb  6 00:00:23 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 05 Feb 2010 23:00:23 +0000
Subject: [issue7588] unittest.TestCase.shortDescription isn't short anymore
In-Reply-To: <1262010641.75.0.70494250568.issue7588@psf.upfronthosting.co.za>
Message-ID: <1265410823.24.0.809792245651.issue7588@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

The problem this fix was trying to fix was that if you provide a docstring for your test then the test name is ommitted in the report.

This could be fixed in the _TextTestResult instead - changing the getDescription() method to always include str(test).

----------

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

From report at bugs.python.org  Sat Feb  6 00:11:20 2010
From: report at bugs.python.org (Robert Collins)
Date: Fri, 05 Feb 2010 23:11:20 +0000
Subject: [issue7501] python -m unittest path_to_suite_function errors
In-Reply-To: <1260742792.63.0.561457576654.issue7501@psf.upfronthosting.co.za>
Message-ID: <1265411480.68.0.0212958437887.issue7501@psf.upfronthosting.co.za>


Robert Collins <robertc at robertcollins.net> added the comment:

Its a common convention in zope.testing, trial, testtools, bzr, ...

----------

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

From report at bugs.python.org  Sat Feb  6 00:12:22 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 05 Feb 2010 23:12:22 +0000
Subject: [issue7501] python -m unittest path_to_suite_function errors
In-Reply-To: <1260742792.63.0.561457576654.issue7501@psf.upfronthosting.co.za>
Message-ID: <1265411542.8.0.20545678813.issue7501@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

So it's a feature request then...

----------

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

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: [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 00:33:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Feb 2010 23:33:45 +0000
Subject: [issue7863] platform module doesn't detect Windows 7
In-Reply-To: <1265412745.93.0.400074024271.issue7863@psf.upfronthosting.co.za>
Message-ID: <1265412825.9.0.309462117303.issue7863@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +lemburg

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

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


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Confirmed on Python 2.7a2.

----------
nosy: +brian.curtin, ezio.melotti
priority:  -> normal
stage:  -> test needed
type:  -> behavior
versions: +Python 2.7

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

From report at bugs.python.org  Sat Feb  6 00:56:23 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 05 Feb 2010 23:56:23 +0000
Subject: [issue7860] 32-bit Python on 64-bit Windows reports incorrect
	architecture
In-Reply-To: <1265397786.69.0.115648884629.issue7860@psf.upfronthosting.co.za>
Message-ID: <4B6CB024.4000407@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
> The test could simply check that platform.machine() never returns "x86" when sys.maxsize is greater than 2**32.
> (and it would even be platform-agnostic)

I'm not sure what such a test would prove, e.g. on 64-bit Mac OS X,
platform.machine() return 'i386'. That could be mapped to 'x86'...

Note that 'x86_64' is just a 'x86' compatible processor with
the AMD 64-bit extensions, so 'x86' is a superset of 'x86_64'.

----------

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

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


Brian Curtin <curtin at acm.org> added the comment:

Note that this will also need the Workstation check that 6.0 has right above this, because both Windows 7 and Windows Server 2008 R2 are version 6.1.x.

Also of note is that sys.getwindowsversion (renamed as GetVersionEx here) has been expanded to make use of the OSVERSIONINFOEX structure in trunk and py3k, which will make things like getting the platform and service pack info cleaner.

I'll work on a patch.

----------
assignee:  -> brian.curtin

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

From report at bugs.python.org  Sat Feb  6 01:24:32 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 06 Feb 2010 00:24:32 +0000
Subject: [issue7799] unittest returning standard_tests from load_tests in
	module fails
In-Reply-To: <1264702646.96.0.224010366293.issue7799@psf.upfronthosting.co.za>
Message-ID: <1265415872.18.0.789157656355.issue7799@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Fixed in revision 78010.

----------
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Feb  6 01:31:25 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 06 Feb 2010 00:31:25 +0000
Subject: [issue7780] unittest: allow an 'import_path' as an alternative to
	'top_level_dir' in test discover
In-Reply-To: <1264458689.45.0.447107444877.issue7780@psf.upfronthosting.co.za>
Message-ID: <1265416285.62.0.575078341158.issue7780@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

My suggestion is that test discovery should first try the argument as a directory. If that fails try it as a dotted name by importing it. If the import succeeds discovery can start from the directory containing the imported package.

If a module rather than a package is specified as a dotted name argument to test discovery then we can either just run the tests in that module or raise an error?

----------

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

From report at bugs.python.org  Sat Feb  6 01:32:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Feb 2010 00:32:33 +0000
Subject: [issue7860] 32-bit Python on 64-bit Windows reports incorrect
	architecture
In-Reply-To: <4B6CB024.4000407@egenix.com>
Message-ID: <1265416435.18484.9.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm not sure what such a test would prove, e.g. on 64-bit Mac OS X,
> platform.machine() return 'i386'. That could be mapped to 'x86'...

You're right. There doesn't seem to be much consistency accross
platforms.

> Note that 'x86_64' is just a 'x86' compatible processor with
> the AMD 64-bit extensions, so 'x86' is a superset of 'x86_64'.

Oops, indeed.

----------

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

From report at bugs.python.org  Sat Feb  6 01:52:43 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Feb 2010 00:52:43 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265417563.54.0.812301994695.issue7712@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15951/temp_cwd_decorator_v2.diff

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

From report at bugs.python.org  Sat Feb  6 01:54:21 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Feb 2010 00:54:21 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265417661.41.0.172932170705.issue7712@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
title: Add a context manager to change cwd in test.test_support -> Add a context manager to change cwd in test.test_support and run the test suite in a temp dir.

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

From report at bugs.python.org  Sat Feb  6 02:57:41 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 06 Feb 2010 01:57:41 +0000
Subject: [issue7863] platform module doesn't detect Windows 7
In-Reply-To: <1265412745.93.0.400074024271.issue7863@psf.upfronthosting.co.za>
Message-ID: <1265421461.45.0.975266995718.issue7863@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Here's a patch which fixes this on trunk. 

2.6/3.1 is a different story as there doesn't appear to be a way to get the platform type to differentiate workstation/server. #7766 is what makes it easy on trunk, but it's a new feature and isn't backported. Thoughts?

----------
components: +Windows
keywords: +needs review, patch
Added file: http://bugs.python.org/file16145/issue7863_trunk.diff

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

From report at bugs.python.org  Sat Feb  6 03:03:19 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Feb 2010 02:03:19 +0000
Subject: [issue7853] on __exit__(), exc_value does not contain the exception.
In-Reply-To: <1265276109.88.0.802756804705.issue7853@psf.upfronthosting.co.za>
Message-ID: <1265421799.96.0.656618664829.issue7853@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

BTW, I'm not going to backport this fix, since the implementation does carry over well to 2.6. Additionally, it is probably an unacceptable change of behavior in a bug fix release.

----------

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

From report at bugs.python.org  Sat Feb  6 03:09:18 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Feb 2010 02:09:18 +0000
Subject: [issue7861] 2to3: "import foo" ->  "from . import foo"
In-Reply-To: <1265398652.17.0.813820450189.issue7861@psf.upfronthosting.co.za>
Message-ID: <1265422158.83.0.319190265414.issue7861@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Well, you'll just have to wait for the next version of 2.6 to be released then.

----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Sat Feb  6 03:23:26 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Feb 2010 02:23:26 +0000
Subject: [issue7859] support "with self.assertRaises(SomeException) as exc:"
	syntax
In-Reply-To: <1265389329.54.0.487777722436.issue7859@psf.upfronthosting.co.za>
Message-ID: <1265423006.01.0.758793833088.issue7859@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I'd prefer for the magic context manager to be returned.

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Sat Feb  6 05:14:13 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 06 Feb 2010 04:14:13 +0000
Subject: [issue7501] python -m unittest path_to_suite_function errors
In-Reply-To: <1260742792.63.0.561457576654.issue7501@psf.upfronthosting.co.za>
Message-ID: <1265429653.38.0.219769775348.issue7501@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Sounds like one.

As far as the trial behavior goes, "trial foo.test_suite" won't work, but "trial foo" will call "foo.test_suite", if one is defined.

----------
nosy: +exarkun

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

From report at bugs.python.org  Sat Feb  6 05:15:30 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sat, 06 Feb 2010 04:15:30 +0000
Subject: [issue7588] unittest.TestCase.shortDescription isn't short anymore
In-Reply-To: <1262010641.75.0.70494250568.issue7588@psf.upfronthosting.co.za>
Message-ID: <1265429730.2.0.910638483221.issue7588@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

I agree that changing the result object is a better way to implement this feature: if the results object wants to report things by *name*, not *description*, then it should get the test's *name*, not rely on changing the meaning of the test's description method.

----------

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

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: [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 05:30:55 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Feb 2010 04:30:55 +0000
Subject: [issue7864] Deprecation markers in unittest docs are unclear
In-Reply-To: <1265430256.2.0.586981350141.issue7864@psf.upfronthosting.co.za>
Message-ID: <1265430655.69.0.589120166229.issue7864@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

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

That's exactly what the warning is saying: failUnless() is deprecated since version 3.1.
assertTrue and assert_ are ok.

----------
nosy: +ezio.melotti
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

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


Justin Lebar <starwiz at gmail.com> added the comment:

Oh, I see.

I still think a complete sentence would be helpful here, although now that I understand that the colon doesn't mean "use instead" I suppose I'm less confused...

----------

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

From report at bugs.python.org  Sat Feb  6 05:56:35 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Feb 2010 04:56:35 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265432195.73.0.0744173480264.issue7712@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here is a patch based on the previous patches and some discussion.
I still have to test it better and add a few comments, but it should be almost ok.

----------
Added file: http://bugs.python.org/file16146/issue7712.diff

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

From report at bugs.python.org  Sat Feb  6 06:11:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 06 Feb 2010 05:11:42 +0000
Subject: [issue7728] test_timeout should use "find_unused_port" helper
In-Reply-To: <1263763659.44.0.532251726667.issue7728@psf.upfronthosting.co.za>
Message-ID: <1265433102.54.0.873430533419.issue7728@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks.  Committed in r78014, r78015, r78016, and r78017.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Feb  6 11:09:19 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 06 Feb 2010 10:09:19 +0000
Subject: [issue7864] Deprecation markers in unittest docs are unclear
In-Reply-To: <1265430256.2.0.586981350141.issue7864@psf.upfronthosting.co.za>
Message-ID: <1265450959.74.0.517821793582.issue7864@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I've added "use ... instead" now in r78018.

----------

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

From report at bugs.python.org  Sat Feb  6 11:46:54 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Feb 2010 10:46:54 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265453214.28.0.731544795751.issue7712@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

It looks fine.

Few comments:
 - "{}_python_{}" could be better, to identify the culprit for leftover directories.
 - the warning message may be more specific:
   "warnings.warn('tests may fail, unable to switch to ' + name,
                  RuntimeWarning, stacklevel=3)"
 - style guide recommends two spaces after a sentence-ending period

----------

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

From report at bugs.python.org  Sat Feb  6 13:07:03 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 06 Feb 2010 12:07:03 +0000
Subject: [issue7588] unittest.TestCase.shortDescription isn't short anymore
In-Reply-To: <1262010641.75.0.70494250568.issue7588@psf.upfronthosting.co.za>
Message-ID: <1265458023.48.0.537629876693.issue7588@psf.upfronthosting.co.za>


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


----------
nosy: +gregory.p.smith

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

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: [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 14:11:16 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 06 Feb 2010 13:11:16 +0000
Subject: [issue7857] test_logging fails
In-Reply-To: <1265378336.27.0.807146257248.issue7857@psf.upfronthosting.co.za>
Message-ID: <1265461876.63.0.280586734057.issue7857@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
priority: critical -> normal

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

From report at bugs.python.org  Sat Feb  6 16:11:11 2010
From: report at bugs.python.org (Meador Inge)
Date: Sat, 06 Feb 2010 15:11:11 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1265469071.17.0.565126548901.issue5211@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> if complex were made 'new-style' in 2.7, then it *would* be possible to > write fairly obvious code (not using coerce or __coerce__) that operated > in the same way in both 2.7 and 3.2.  So I still think it's worth 
> considering.

Agreed.  I have attached a patch with src, test, and doc changes.

----------
Added file: http://bugs.python.org/file16148/issue-5211-patch

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

From report at bugs.python.org  Sat Feb  6 16:23:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Feb 2010 15:23:33 +0000
Subject: [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: <1265469813.19.0.406122513302.issue7829@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Merwok

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

From report at bugs.python.org  Sat Feb  6 16:47:23 2010
From: report at bugs.python.org (Meador Inge)
Date: Sat, 06 Feb 2010 15:47:23 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265471243.01.0.941566221443.issue6877@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> Can you please try inserting that include <stdlib.h> and see if 10.5 
> builds readline?

This does not work out of trunk for me:

euclid:trunk minge$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.5.7
BuildVersion:	9J61
euclid:trunk minge$ svn diff
Index: Modules/readline.c
===================================================================
--- Modules/readline.c	(revision 78019)
+++ Modules/readline.c	(working copy)
@@ -6,6 +6,7 @@
 
 /* Standard definitions */
 #include "Python.h"
+#include <stdlib.h>
 #include <setjmp.h>
 #include <signal.h>
 #include <errno.h>
euclid:trunk minge$ make
-----------------------------------------------
Modules/Setup.dist is newer than Modules/Setup;
check to make sure you have all the updates you
need in your Modules/Setup file.
Usually, copying Modules/Setup.dist to Modules/Setup will work.
-----------------------------------------------
running build
running build_ext
building dbm using ndbm
building 'readline' extension
gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/minge/Research/Languages/python/trunk/Mac/Include -IInclude -I./Include -I/usr/local/include -I/Users/minge/Research/Languages/python/trunk/Include -I. -c /Users/minge/Research/Languages/python/trunk/Modules/readline.c -o build/temp.macosx-10.4-i386-2.7/Users/minge/Research/Languages/python/trunk/Modules/readline.o
/Users/minge/Research/Languages/python/trunk/Modules/readline.c:42: error: conflicting types for ?completion_matches?
/usr/include/readline/readline.h:172: error: previous declaration of ?completion_matches? was here
/Users/minge/Research/Languages/python/trunk/Modules/readline.c: In function ?py_remove_history?:
/Users/minge/Research/Languages/python/trunk/Modules/readline.c:379: warning: passing argument 1 of ?free? discards qualifiers from pointer target type
/Users/minge/Research/Languages/python/trunk/Modules/readline.c: In function ?py_replace_history?:
/Users/minge/Research/Languages/python/trunk/Modules/readline.c:416: warning: passing argument 1 of ?free? discards qualifiers from pointer target type
/Users/minge/Research/Languages/python/trunk/Modules/readline.c: In function ?call_readline?:
/Users/minge/Research/Languages/python/trunk/Modules/readline.c:1033: warning: assignment discards qualifiers from pointer target type
/Users/minge/Research/Languages/python/trunk/Modules/readline.c:1036: warning: assignment discards qualifiers from pointer target type

Python build finished, but the necessary bits to build these modules were not found:
_bsddb             gdbm               linuxaudiodev   
ossaudiodev        spwd               sunaudiodev     
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
readline                                              

running build_scripts

I am more than happy to run more tests with respect to this issue.  I am tired of seeing this build break everyday :)

----------
nosy: +minge

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

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


Mezhenin Artyom <a.mezhenin at gmail.com> added the comment:

Same text here:
http://docs.python.org/library/unittest.html#basic-example

----------

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

From report at bugs.python.org  Sat Feb  6 16:58:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Feb 2010 15:58:09 +0000
Subject: [issue7866] it looks like a typo in unittest
In-Reply-To: <1265471710.93.0.463543374636.issue7866@psf.upfronthosting.co.za>
Message-ID: <1265471889.76.0.434813553717.issue7866@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

?Ran? is the preterite form of ?run?. It is used here because at the time of the print, the tests are done, it?s past.

Regards

----------
nosy: +Merwok

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

From report at bugs.python.org  Sat Feb  6 17:00:29 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Feb 2010 16:00:29 +0000
Subject: [issue7866] it looks like a typo in unittest
In-Reply-To: <1265471710.93.0.463543374636.issue7866@psf.upfronthosting.co.za>
Message-ID: <1265472029.33.0.471810081481.issue7866@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

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


Mezhenin Artyom <a.mezhenin at gmail.com> added the comment:

Sorry, I'm from Russia.

P.S. http://translate.google.com/ sucks =)

----------

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

From report at bugs.python.org  Sat Feb  6 17:06:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Feb 2010 16:06:54 +0000
Subject: [issue7866] it looks like a typo in unittest
In-Reply-To: <1265471710.93.0.463543374636.issue7866@psf.upfronthosting.co.za>
Message-ID: <1265472414.35.0.429130624488.issue7866@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

No problem, I?m from France :)

And yes, automatic translation does not work. Or at least not gratis.

Cheers

----------

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

From report at bugs.python.org  Sat Feb  6 18:50:31 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Feb 2010 17:50:31 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265478631.04.0.795383563132.issue7712@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch which fixes the "relative import" issue.

 ~ $ cd Lib/
 ~ $ ../python -m test.regrtest


Note: There are some 2-spaces indents for patch readability.
      Change them before commit.

----------
versions:  -Python 2.6, Python 3.1
Added file: http://bugs.python.org/file16150/issue7712_context_manager_v2.diff

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

From report at bugs.python.org  Sat Feb  6 18:54:41 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Feb 2010 17:54:41 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265478881.24.0.818198335039.issue7712@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15956/issue7712_context_manager.diff

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

From report at bugs.python.org  Sat Feb  6 19:47:14 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 06 Feb 2010 18:47:14 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1265482034.7.0.621214522402.issue5341@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, committed as r78024, r78025, respectively.

----------
status: open -> closed

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

From report at bugs.python.org  Sat Feb  6 20:00:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Feb 2010 19:00:04 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265482804.65.0.241040993321.issue7712@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Slightly more readable, without 2-spaces indent.

----------
Added file: http://bugs.python.org/file16151/issue7712_context_manager_v3.diff

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

From report at bugs.python.org  Sat Feb  6 20:01:51 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 06 Feb 2010 19:01:51 +0000
Subject: [issue7347] Add {Create|Delete}KeyEx to _winreg, doc and test updates
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1265482911.32.0.885680562284.issue7347@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

This needs #7860 for properly figuring out the machine architecture for some 32-bit Python on 64-bit Windows tests.

----------
dependencies: +32-bit Python on 64-bit Windows reports incorrect architecture

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

From report at bugs.python.org  Sat Feb  6 20:09:22 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 06 Feb 2010 19:09:22 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265483362.63.0.307208359877.issue6877@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

@Meador: confirmed.  This does not fix the 10.5 build.

----------

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

From report at bugs.python.org  Sat Feb  6 20:10:02 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Feb 2010 19:10:02 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265483402.09.0.427273645587.issue7712@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16150/issue7712_context_manager_v2.diff

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

From report at bugs.python.org  Sat Feb  6 20:17:47 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Feb 2010 19:17:47 +0000
Subject: [issue4978] allow unicode keyword args
In-Reply-To: <1232233645.86.0.929697154925.issue4978@psf.upfronthosting.co.za>
Message-ID: <1265483867.19.0.619795161989.issue4978@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Done in r78027.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Feb  6 20:44:44 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Feb 2010 19:44:44 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265485484.42.0.868509876449.issue7712@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16151/issue7712_context_manager_v3.diff

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

From report at bugs.python.org  Sat Feb  6 20:45:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 06 Feb 2010 19:45:20 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265485520.63.0.334940365085.issue7712@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

There were syntax errors in the previous patch. Sorry.

----------
Added file: http://bugs.python.org/file16152/issue7712_context_manager_v3a.diff

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

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: [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 22:16:41 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 06 Feb 2010 21:16:41 +0000
Subject: [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: <1265491001.79.0.721360029419.issue7867@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Wasn't the description of Python's semantics being 'pass by value where the value is a reference' actually very controversial indeed? Do you have a link to the discussion on c.l.p?

----------
nosy: +michael.foord

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

From report at bugs.python.org  Sat Feb  6 22:26:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 06 Feb 2010 21:26:16 +0000
Subject: [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: <1265491576.87.0.736455228151.issue7867@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, the discussion was *long* and more than a bit contentious.  This is my own personal summary.  Here is a message I found somewhere in the middle of the thread:

http://mail.python.org/pipermail/python-list/2009-January/1187126.html

Do you have a pointer to where "pass by value where the value is a reference" was controversial?  (Other than that thread :)

----------

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

From report at bugs.python.org  Sat Feb  6 22:34:05 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Feb 2010 21:34:05 +0000
Subject: [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: <1265492045.19.0.363892689235.issue7867@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The 4-point list at the beginning is in my opinion very clear (for people with some background in C or similar languages). I think that the following part is not really clear, and the example should focus better on the difference about mutable and immutable objects.

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Sat Feb  6 22:37:40 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 06 Feb 2010 21:37:40 +0000
Subject: [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: <1265492260.84.0.0455348564068.issue7867@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, the thrust of the second part is to make it clear that there *are* no differences between mutable and immutable objects as far as the assignment semantics are concerned.  All objects in Python are treated the same.  What is different is what is on the left hand side of the assignment, and yes, it would probably be helpful to point that out explicitly.

----------

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

From report at bugs.python.org  Sat Feb  6 22:45:08 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 06 Feb 2010 21:45:08 +0000
Subject: [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: <1265492708.49.0.22105481849.issue7867@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Over 122 messages so I'm not going to search exhaustively. In this part of the thread you can see Fredrik Lundh and Aahz disputing "call-by-value-where-the-value-is-a-reference" as a useful way of describing Python calling semantices:

http://groups.google.com/group/comp.lang.python/browse_thread/thread/37e00ba1a5200b9b/1d68c7686a9d5417

----------

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

From report at bugs.python.org  Sat Feb  6 22:47:12 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Feb 2010 21:47:12 +0000
Subject: [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: <1265492832.49.0.733920956096.issue7867@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The difference is that mutable objects may give the illusion of a pass-by-reference (because changes made inside the function are visible outside) whereas immutable objects give the illusion of pass-by-value (because you can't affect the original object in any way). This is also related to the confusion about assignment and what it really does.

----------

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

From report at bugs.python.org  Sat Feb  6 23:03:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 06 Feb 2010 22:03:04 +0000
Subject: [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: <1265493784.28.0.619974491099.issue7867@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Michael: I didn't read the whole thread, but it has definite echos of the thread in which I was involved.  While I agree that in pure computer-science terms it may be imprecise to say that python is 'call by value where values are pointers to objects", my goal in the FAQ entry is to give people coming from C a mental model that *works* in practical terms to help them understand what Python does.

The second half is then an attempt to provide a new mental model, one independent of any implementation details, that *better* explains what Python does.

But apparently, given Ezio's responses, I didn't succeed in the second part :(

Ezio: I've added another paragraph to the end to try to make the point I'm trying to get across clearer, but I'm not sure the additional words really do that.

----------
Added file: http://bugs.python.org/file16154/passbyx.txt

_______________________________________
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: [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  Sat Feb  6 23:09:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Feb 2010 22:09:58 +0000
Subject: [issue7868] add a loggerClass attribute to Manager
In-Reply-To: <1265493992.57.0.579633737056.issue7868@psf.upfronthosting.co.za>
Message-ID: <1265494198.37.0.161528810944.issue7868@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

I know the internal style (or lack thereof :) of logging forces you to use unReadableNames, but could the ocde use ?cls? instead of ?class?, as per PEP?8?

Kind regards

----------
nosy: +Merwok

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

From report at bugs.python.org  Sat Feb  6 23:10:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Feb 2010 22:10:21 +0000
Subject: [issue7868] add a loggerClass attribute to Manager
In-Reply-To: <1265493992.57.0.579633737056.issue7868@psf.upfronthosting.co.za>
Message-ID: <1265494221.6.0.468003603649.issue7868@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

s/ocde/code/

----------

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

From report at bugs.python.org  Sat Feb  6 23:13:05 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 06 Feb 2010 22:13:05 +0000
Subject: [issue7347] Add {Create|Delete}KeyEx to _winreg, doc and test updates
In-Reply-To: <1258566495.76.0.636986979508.issue7347@psf.upfronthosting.co.za>
Message-ID: <1265494385.99.0.596966589418.issue7347@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Attached is what I believe is the complete patch. You'll need to apply the patch on #7860 for proper test coverage of a 32-bit Python running on 64-bit Windows.

Here's a summary of what's contained:

1. Documented and tested the previously undocumented and untested *ReflectionKey functions
2. Added, documented, and tested CreateKeyEx
3. Added, documented, and tested DeleteKeyEx
4. Fixed QueryReflectionKey to return the key state rather than the return value of the underlying Windows call.

Overall the theme is to better our support of 64-bit Windows.

The testing scenario becomes a bit more involved given the spread of Windows versions supported and their varying level of support of some of the APIs being exposed. I think the tests are documented well enough to explain what scenarios are available and which are being tested, but let me know if more detail is needed.

I've tested this on the following machines with success:
1. Windows XP SP2 32-bit
2. Windows Server 2003 32-bit
3. Windows Server 2003 64-bit with 32 and 64-bit Python
4. Windows 7 64-bit with 32 and 64-bit Python

----------
components: +Windows
keywords: +64bit, needs review
stage: test needed -> patch review
versions: +Python 3.2
Added file: http://bugs.python.org/file16156/issue7347.diff

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

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


Georg Brandl <georg at python.org> added the comment:

You mean, instead of "klass"?  It is used in the other setLoggerClass(), and therefore consistent.

----------

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

From report at bugs.python.org  Sat Feb  6 23:15:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Feb 2010 22:15:25 +0000
Subject: [issue7868] add a loggerClass attribute to Manager
In-Reply-To: <1265493992.57.0.579633737056.issue7868@psf.upfronthosting.co.za>
Message-ID: <1265494525.67.0.362133455982.issue7868@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I meant ?klass?, right. My fingers are trained not to write it, it seems.

Ok, it?s already used elsewhere in the module. Too bad.

Kind regards

----------

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

From report at bugs.python.org  Sat Feb  6 23:15:55 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 06 Feb 2010 22:15:55 +0000
Subject: [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: <1265494555.65.0.235378852349.issue7867@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

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

From report at bugs.python.org  Sat Feb  6 23:50:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Feb 2010 22:50:08 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1265496608.95.0.555640030298.issue7301@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Merwok

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

From report at bugs.python.org  Sun Feb  7 00:20:36 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 06 Feb 2010 23:20:36 +0000
Subject: [issue4194] default subprocess.Popen buffer size
In-Reply-To: <18690.3034.472764.227788@montanaro-dyndns-org.local>
Message-ID: <1265498436.71.0.18475859402.issue4194@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Tested it on mac OSX (Snow leopard)

Shashwat-Anands-MacBook-Pro:Desktop l0nwlf$ python2.5 popentest.py 
time with os.popen :  0.0342061519623
time with subprocess.Popen :  0.0421631336212
Shashwat-Anands-MacBook-Pro:Desktop l0nwlf$ python2.6 --version
Python 2.6.1
Shashwat-Anands-MacBook-Pro:Desktop l0nwlf$ python2.6 popentest.py 
time with os.popen :  0.0282561779022
time with subprocess.Popen :  0.0366630554199


Python 2.5.4s os.popen was faster than subprocess.Popen, the same being the case with Python 2.6.1 I do not think it is a mac issue.

----------
nosy: +l0nwlf

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

From report at bugs.python.org  Sun Feb  7 00:26:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 06 Feb 2010 23:26:59 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1265498819.2.0.986491032481.issue5211@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks.  I'll try to find time to look at this tomorrow.

----------
assignee:  -> mark.dickinson

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

From report at bugs.python.org  Sun Feb  7 00:32:38 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 06 Feb 2010 23:32:38 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1265499158.67.0.46105768746.issue7301@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Removed file: http://bugs.python.org/file15889/issue7301.diff

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

From report at bugs.python.org  Sun Feb  7 00:33:41 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 06 Feb 2010 23:33:41 +0000
Subject: [issue7301] Add environment variable $PYTHONWARNINGS
In-Reply-To: <1257865531.11.0.841786263832.issue7301@psf.upfronthosting.co.za>
Message-ID: <1265499221.68.0.832240390081.issue7301@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Updated patch, tests weren't working.

----------
Added file: http://bugs.python.org/file16157/issue7301.diff

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

From report at bugs.python.org  Sun Feb  7 01:16:42 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 07 Feb 2010 00:16:42 +0000
Subject: [issue7250] wsgiref.handlers.CGIHandler caches os.environ,
	leaking info between requests
In-Reply-To: <1257147245.14.0.668660104401.issue7250@psf.upfronthosting.co.za>
Message-ID: <1265501802.42.0.201604761325.issue7250@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Marking this as release blocker to ensure the (one-line) fix makes it into 2.7 and 3.2.

----------
priority: high -> release blocker
resolution:  -> accepted

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

From report at bugs.python.org  Sun Feb  7 01:44:49 2010
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 07 Feb 2010 00:44:49 +0000
Subject: [issue4037] doctest.py should include method descriptors when looking
	inside a class __dict__
In-Reply-To: <1223079206.04.0.17382541424.issue4037@psf.upfronthosting.co.za>
Message-ID: <1265503489.63.0.817541691842.issue4037@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

The patch you suggest is *not* sufficient, at least not by my testing.

However, the attached patch does work, according to my tests.

----------
nosy: +stevenjd
Added file: http://bugs.python.org/file16158/patch

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

From report at bugs.python.org  Sun Feb  7 02:07:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 07 Feb 2010 01:07:19 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1265504839.43.0.450399789093.issue2775@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Merwok

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

From report at bugs.python.org  Sun Feb  7 02:10:07 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 07 Feb 2010 01:10:07 +0000
Subject: [issue7857] test_logging fails
In-Reply-To: <1265378336.27.0.807146257248.issue7857@psf.upfronthosting.co.za>
Message-ID: <1265505007.19.0.825593701074.issue7857@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Tests now seem to be fine. Thanks, Benjamin Peterson, for the fix.

----------
status: open -> closed

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

From report at bugs.python.org  Sun Feb  7 02:38:14 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 07 Feb 2010 01:38:14 +0000
Subject: [issue7868] add a loggerClass attribute to Manager
In-Reply-To: <1265493992.57.0.579633737056.issue7868@psf.upfronthosting.co.za>
Message-ID: <1265506694.53.0.226660099024.issue7868@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Patch applied to trunk (r78055).

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Feb  7 03:07:32 2010
From: report at bugs.python.org (Meador Inge)
Date: Sun, 07 Feb 2010 02:07:32 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265508452.43.0.332373532133.issue6877@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> If not, then we need to make a choice of #ifdef __FreeBSD__ as I 
> suggested in issue4204, or #ifndef __APPLE__ as I used in my first 
> personal version of the patch.

In the off chance that this same problem were to occur on another platform, wouldn't be better to test for 'completion_matches' in configure?  Perhaps something like the attached patch? (fixes the issue for me on OS X 10.5 in the Python trunk)

----------
Added file: http://bugs.python.org/file16159/issue-6877.patch

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

From report at bugs.python.org  Sun Feb  7 03:08:23 2010
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Sun, 07 Feb 2010 02:08:23 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265508503.72.0.319137858997.issue6877@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

OK, so issue4204 patch is causing problems.
As I mentioned before we could choose to #ifdef __FreeBSD__ or check whether __APPLE__ is not defined.

I'm attaching a new patch for 2.6.5 (2.6 branch) that uses the __APPLE__ check.

----------
Added file: http://bugs.python.org/file16160/readline-libedit-2.6.5-1.patch

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

From report at bugs.python.org  Sun Feb  7 03:13:28 2010
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Sun, 07 Feb 2010 02:13:28 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265508808.75.0.906436183582.issue6877@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

The patch with the same correction against trunk is attached so that Meador can test it.

----------
Added file: http://bugs.python.org/file16161/readline-libedit-trunk.patch

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

From report at bugs.python.org  Sun Feb  7 03:23:30 2010
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Sun, 07 Feb 2010 02:23:30 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265509410.09.0.639279004097.issue6877@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

Meador, I just looked at your patch (it seems we were posting patches at about the same time).

That's a good fix too.

Barry it's your call.

----------

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

From report at bugs.python.org  Sun Feb  7 04:04:58 2010
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Sun, 07 Feb 2010 03:04:58 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265511898.83.0.698234755873.issue6877@psf.upfronthosting.co.za>


Changes by Zvezdan Petkovic <zvezdan at zope.com>:


Removed file: http://bugs.python.org/file16160/readline-libedit-2.6.5-1.patch

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

From report at bugs.python.org  Sun Feb  7 04:05:10 2010
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Sun, 07 Feb 2010 03:05:10 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265511910.85.0.0451128996226.issue6877@psf.upfronthosting.co.za>


Changes by Zvezdan Petkovic <zvezdan at zope.com>:


Removed file: http://bugs.python.org/file16161/readline-libedit-trunk.patch

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

From report at bugs.python.org  Sun Feb  7 04:07:01 2010
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Sun, 07 Feb 2010 03:07:01 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265512021.03.0.289790604234.issue6877@psf.upfronthosting.co.za>


Changes by Zvezdan Petkovic <zvezdan at zope.com>:


Added file: http://bugs.python.org/file16162/readline-libedit-2.6.5-fix1.patch

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

From report at bugs.python.org  Sun Feb  7 04:07:58 2010
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Sun, 07 Feb 2010 03:07:58 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265512078.28.0.217252900948.issue6877@psf.upfronthosting.co.za>


Changes by Zvezdan Petkovic <zvezdan at zope.com>:


Added file: http://bugs.python.org/file16163/readline-libedit-trunk.patch

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

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


INADA Naoki <songofacandy at gmail.com> added the comment:

This patch shows filename and lineno.
I can specify my wrong logging code with this patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file16164/logging_show_file_and_line.patch

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

From report at bugs.python.org  Sun Feb  7 06:53:06 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 07 Feb 2010 05:53:06 +0000
Subject: [issue4037] doctest.py should include method descriptors when looking
	inside a class __dict__
In-Reply-To: <1223079206.04.0.17382541424.issue4037@psf.upfronthosting.co.za>
Message-ID: <1265521986.15.0.959197915798.issue4037@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am not sure whether this would be considered a bugfix or a new feature.
(ie, whether it would apply to 2.6 and 3.1 or not)

But the change is needed for 3.x also.

I am not sure whether the doc needs changing. A testcase should be added to doctest-test.

----------
nosy: +tjreedy
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Feb  7 09:20:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Feb 2010 08:20:07 +0000
Subject: [issue7869] traceback from logging is unusable.
In-Reply-To: <1265519418.35.0.0585940634416.issue7869@psf.upfronthosting.co.za>
Message-ID: <1265530807.85.0.0760786233697.issue7869@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +vinay.sajip
priority:  -> normal
stage:  -> patch review
type: behavior -> feature request
versions:  -Python 2.5

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

From report at bugs.python.org  Sun Feb  7 10:02:10 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 07 Feb 2010 09:02:10 +0000
Subject: [issue7868] add a loggerClass attribute to Manager
In-Reply-To: <1265493992.57.0.579633737056.issue7868@psf.upfronthosting.co.za>
Message-ID: <1265533330.48.0.319101062405.issue7868@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks!

----------

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

From report at bugs.python.org  Sun Feb  7 10:12:43 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 07 Feb 2010 09:12:43 +0000
Subject: [issue7859] support "with self.assertRaises(SomeException) as exc:"
	syntax
In-Reply-To: <1265389329.54.0.487777722436.issue7859@psf.upfronthosting.co.za>
Message-ID: <1265533963.86.0.284624231484.issue7859@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Why not the un-magic context manager, which has an exc_value attribute with the exception?

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Sun Feb  7 10:33:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 07 Feb 2010 09:33:11 +0000
Subject: [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: <1265535191.22.0.93706661307.issue7848@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: open -> closed

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

From report at bugs.python.org  Sun Feb  7 10:36:30 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 07 Feb 2010 09:36:30 +0000
Subject: [issue7835] Minor bug in 2.6.4 related to cleanup at end of program
Message-ID: <1265535390.16.0.918883953812.issue7835@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'd say go ahead and commit without test.

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Sun Feb  7 10:37:34 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 07 Feb 2010 09:37:34 +0000
Subject: [issue7826] support caching for 2to3
In-Reply-To: <1264985952.93.0.779639488883.issue7826@psf.upfronthosting.co.za>
Message-ID: <1265535454.19.0.0407680844458.issue7826@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

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

From report at bugs.python.org  Sun Feb  7 10:48:22 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Feb 2010 09:48:22 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265536102.85.0.797590897875.issue6877@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

re: msg98913

The addition of an #include of stdlib.h is unnecessary because Python.h already does that. 


re: msg98908

Building against with a 10.3 deployment target should be harmless. A universal build targets 10.3 on purpose because that results in binaries that work on all supported OSX platforms.

BTW. I've pruned the list of python versions, this patch will never be applied to 2.4.

BTW2. I'll do the backport later today.

----------
versions:  -Python 2.4

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

From report at bugs.python.org  Sun Feb  7 11:26:54 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 07 Feb 2010 10:26:54 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265538414.0.0.233993999017.issue7712@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16152/issue7712_context_manager_v3a.diff

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

From report at bugs.python.org  Sun Feb  7 11:28:08 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 07 Feb 2010 10:28:08 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265538488.53.0.670310907676.issue7712@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Removed the dummy CM hack.
Now it should be ready for final review.

----------
Added file: http://bugs.python.org/file16165/issue7712_context_manager_v4.diff

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

From report at bugs.python.org  Sun Feb  7 11:32:41 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Feb 2010 10:32:41 +0000
Subject: [issue7812] Call to gestalt('sysu') on OSX can lead to freeze in
	wxPython apps
In-Reply-To: <1264867064.8.0.669245922526.issue7812@psf.upfronthosting.co.za>
Message-ID: <1265538761.4.0.664815963959.issue7812@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Two short notes:

1) The call to gestalt('sysu') is basicly dead code and will be removed

2) Running the GUI runloop in a thread that is not the main thread is AFAIK not supported by Apple. I'm not 100% sure about the Carbon libraries, but in Cocoa the main thread has special significance.

----------

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

From report at bugs.python.org  Sun Feb  7 12:35:58 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Feb 2010 11:35:58 +0000
Subject: [issue7812] Call to gestalt('sysu') on OSX can lead to freeze in
	wxPython apps
In-Reply-To: <1264867064.8.0.669245922526.issue7812@psf.upfronthosting.co.za>
Message-ID: <1265542558.1.0.61317511825.issue7812@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Removed the call to gestalt('sysu') in r78056 (trunk), r78057 (2.6), r78058 (3.x), r78060 (3.1)

(Also changing the type to 'behavior' instead of 'crash' because this is not a crashing bug in python).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

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

From report at bugs.python.org  Sun Feb  7 12:40:33 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Feb 2010 11:40:33 +0000
Subject: [issue7807] test_macostools fails on OS X 10.6: no attribute 'FSSpec'
In-Reply-To: <1264787865.0.0.0322335198663.issue7807@psf.upfronthosting.co.za>
Message-ID: <1265542833.12.0.852333866462.issue7807@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've disabled the tests (and updated documentation) in r78061 (trunk), r78062 (2.6)

The root cause is that the implemention of macostools uses FSSpecs to implement the failing APIs and those aren't available in 64-bit code. I haven't reimplemented the failing APIs because the modern replacements aren't wrapped in the Carbon module.

----------

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

From report at bugs.python.org  Sun Feb  7 12:40:59 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Feb 2010 11:40:59 +0000
Subject: [issue7807] test_macostools fails on OS X 10.6: no attribute 'FSSpec'
In-Reply-To: <1264787865.0.0.0322335198663.issue7807@psf.upfronthosting.co.za>
Message-ID: <1265542859.71.0.51070303674.issue7807@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Feb  7 12:41:44 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Feb 2010 11:41:44 +0000
Subject: [issue7437] OS X 2.6.4 installer fails on 10.3 with two
	corrupted	file names, ignored on 10.4
In-Reply-To: <1259977222.8.0.535522735801.issue7437@psf.upfronthosting.co.za>
Message-ID: <1265542904.79.0.744256679499.issue7437@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

TJ: thanks for testing on 10.3.9.

----------
stage: test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Feb  7 12:54:12 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Feb 2010 11:54:12 +0000
Subject: [issue7714] configure GCC version detection fix for Darwin
In-Reply-To: <1263659111.9.0.539414753247.issue7714@psf.upfronthosting.co.za>
Message-ID: <1265543652.4.0.116454830573.issue7714@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Ported to 2.6 (r78065),  3.x (r78066) and 3.1 (r78068)

----------
status: open -> closed

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

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


Changes by Georg Brandl <georg at python.org>:


----------
versions: +Python 2.7

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

From report at bugs.python.org  Sun Feb  7 13:53:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 07 Feb 2010 12:53:25 +0000
Subject: [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 13:59:27 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 07 Feb 2010 12:59:27 +0000
Subject: [issue7869] traceback from logging is unusable.
In-Reply-To: <1265519418.35.0.0585940634416.issue7869@psf.upfronthosting.co.za>
Message-ID: <1265547567.76.0.485521755978.issue7869@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Fix (slightly modified version of patch) checked into trunk (r78081), thanks Inada Naoki!

----------
resolution:  -> fixed
status: open -> closed

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

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


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looks like I accidentally truncated that traceback.  Here's the full version:

Python 2.7a2+ (trunk:78008M, Feb  5 2010, 23:39:39) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> '%0.116x' % 1
'00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001'
[34971 refs]
>>> '%0.117x' % 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: formatted integer is too long (precision too large?)
[35003 refs]

----------

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

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


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, michael.foord
priority:  -> normal
stage:  -> test needed
versions: +Python 2.6, Python 2.7, Python 3.2

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

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


Mark Dickinson <dickinsm at gmail.com> added the comment:

Removing 3.2 from the versions:  the OverflowError appears to be specific to 2.x ints:

>>> '%0.117x' % 1L
'000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001'

----------
versions:  -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:15:09 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 07 Feb 2010 14:15:09 +0000
Subject: [issue7872] Incorrect error raised on importing invalid module via
	unittest
In-Reply-To: <1265548769.63.0.955560962057.issue7872@psf.upfronthosting.co.za>
Message-ID: <1265552109.69.0.180355262981.issue7872@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Duplicate of issue 7559.

----------
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Feb  7 15:18:23 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 07 Feb 2010 14:18:23 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265552303.73.0.603264451022.issue7712@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16165/issue7712_context_manager_v4.diff

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

From report at bugs.python.org  Sun Feb  7 15:19:27 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 07 Feb 2010 14:19:27 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265552367.74.0.29900223834.issue7712@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Let's fix some other tests.

----------
Added file: http://bugs.python.org/file16167/issue7712_context_manager_v5.diff

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

From report at bugs.python.org  Sun Feb  7 15:51:44 2010
From: report at bugs.python.org (Tobias)
Date: Sun, 07 Feb 2010 14:51:44 +0000
Subject: [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 16:21:23 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 07 Feb 2010 15:21:23 +0000
Subject: [issue7859] support "with self.assertRaises(SomeException) as exc:"
	syntax
In-Reply-To: <1265533963.86.0.284624231484.issue7859@psf.upfronthosting.co.za>
Message-ID: <1afaf6161002070721o21796641g62ddb69d1ac2038c@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/2/7 Georg Brandl <report at bugs.python.org>:
>
> Georg Brandl <georg at python.org> added the comment:
>
> Why not the un-magic context manager, which has an exc_value attribute with the exception?

That's what I meant, but our perceptions of magic are clearly different. :)

----------

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

From report at bugs.python.org  Sun Feb  7 16:43:15 2010
From: report at bugs.python.org (Serge)
Date: Sun, 07 Feb 2010 15:43:15 +0000
Subject: [issue6171] Class Browser selection in Ubuntu
In-Reply-To: <1243903612.81.0.195499978214.issue6171@psf.upfronthosting.co.za>
Message-ID: <1265557395.1.0.868545894837.issue6171@psf.upfronthosting.co.za>


Serge <sergredko at gmail.com> added the comment:

TreeNode class which is used in IDLE class browser create a window for a text label on each single click and apparently under Ubuntu tcl looses first left button click and therefore doesn't generate left buttond double click event. 

In this patch I make changes to the TreeNode class so it creates a window for a text label only when needed (i.e. during initialization or when it was delete after "collapse" command)

----------
components: +IDLE
keywords: +patch
nosy: +Serge
Added file: http://bugs.python.org/file16168/idle_classbrowser.patch

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

From report at bugs.python.org  Sun Feb  7 17:52:50 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 07 Feb 2010 16:52:50 +0000
Subject: [issue7859] support "with self.assertRaises(SomeException) as exc:"
	syntax
In-Reply-To: <1265389329.54.0.487777722436.issue7859@psf.upfronthosting.co.za>
Message-ID: <1265561570.05.0.808844387288.issue7859@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Just use the context manager and the exception is available as exc_value.

----------
nosy: +michael.foord
resolution:  -> rejected
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Feb  7 17:59:24 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 07 Feb 2010 16:59:24 +0000
Subject: [issue7874] logging.basicConfig should raise warning/exception on
	second call
In-Reply-To: <1265554303.97.0.0565819398913.issue7874@psf.upfronthosting.co.za>
Message-ID: <1265561964.26.0.335487394438.issue7874@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Library (Lib) -2to3 (2.x to 3.0 conversion tool)
nosy: +vinay.sajip
priority:  -> normal
stage:  -> test needed
versions: +Python 3.1 -Python 2.5

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

From report at bugs.python.org  Sun Feb  7 18:03:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 07 Feb 2010 17:03:36 +0000
Subject: [issue7870] Duplicate test methods in test_memoryio
In-Reply-To: <1265546873.41.0.795914089262.issue7870@psf.upfronthosting.co.za>
Message-ID: <1265562216.66.0.531733386424.issue7870@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior
versions: +Python 3.2

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

From report at bugs.python.org  Sun Feb  7 19:29:58 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 07 Feb 2010 18:29:58 +0000
Subject: [issue7859] support "with self.assertRaises(SomeException) as exc:"
	syntax
In-Reply-To: <1265389329.54.0.487777722436.issue7859@psf.upfronthosting.co.za>
Message-ID: <1265567398.5.0.451837436429.issue7859@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Thank you for this answer. The "exception" argument could be useful.
But it does not work as documented on r77999...

Btw, the documentation explains the behaviour I expect...

----------
status: closed -> pending

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

From report at bugs.python.org  Sun Feb  7 19:49:36 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 07 Feb 2010 18:49:36 +0000
Subject: [issue7859] support "with self.assertRaises(SomeException) as exc:"
	syntax
In-Reply-To: <1265389329.54.0.487777722436.issue7859@psf.upfronthosting.co.za>
Message-ID: <1265568576.87.0.351899686519.issue7859@psf.upfronthosting.co.za>


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


----------
status: pending -> closed

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

From report at bugs.python.org  Sun Feb  7 19:50:12 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 07 Feb 2010 18:50:12 +0000
Subject: [issue7859] support "with self.assertRaises(SomeException) as exc:"
	syntax
In-Reply-To: <1265389329.54.0.487777722436.issue7859@psf.upfronthosting.co.za>
Message-ID: <1265568612.11.0.572256935832.issue7859@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Fixed (with tests) in r78094. Thank you Michael.

----------

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

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: [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 20:04:06 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 07 Feb 2010 19:04:06 +0000
Subject: [issue7875] test_multiprocessing / importlib failure
In-Reply-To: <1265569366.45.0.612808621772.issue7875@psf.upfronthosting.co.za>
Message-ID: <1265569446.25.0.683835633704.issue7875@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
keywords: +buildbot

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

From report at bugs.python.org  Sun Feb  7 20:26:53 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 07 Feb 2010 19:26:53 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265570813.64.0.949468787558.issue6877@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Zvezdan, your "fix1" patch works perfectly for me in Python 2.6 on both OS X 10.5 and 10.6.  Great work!

I approve applying this patch for Python 2.6.5.  Ronald, would you like to do the honors?

----------
assignee:  -> ronaldoussoren
resolution: fixed -> accepted

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

From report at bugs.python.org  Sun Feb  7 21:05:27 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Feb 2010 20:05:27 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265573127.5.0.835385382898.issue6877@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I have a question about this bit of the patch:

@@ -38,10 +38,31 @@
 #if defined(_RL_FUNCTION_TYPEDEF)
 extern char **completion_matches(char *, rl_compentry_func_t *);
 #else
+#if !defined(__APPLE__)
 extern char **completion_matches(char *, CPFunction *);
 #endif
 #endif
+#endif

That bit is not in the trunk, should it be forward ported to the trunk?

The actual prototype on 10.5 and 10.6 is:

char           **completion_matches(const char *, CPFunction *);

Wouldn't it be better to change the prototype in readline.c to match?

As that's not a critical change I've committed the fix1 patch as is in r78096.

----------

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

From report at bugs.python.org  Sun Feb  7 21:07:30 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Feb 2010 20:07:30 +0000
Subject: [issue7658] OS X pythonw.c compile error with 10.4 or earlier
	deployment target: no spawn.h
In-Reply-To: <1262941566.99.0.894621937515.issue7658@psf.upfronthosting.co.za>
Message-ID: <1265573250.72.0.93947404693.issue7658@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is now fixed in the 3.2 branch as well.

----------
status: open -> closed

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

From report at bugs.python.org  Sun Feb  7 21:23:16 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 07 Feb 2010 20:23:16 +0000
Subject: [issue7874] logging.basicConfig should raise warning/exception on
	second call
In-Reply-To: <1265554303.97.0.0565819398913.issue7874@psf.upfronthosting.co.za>
Message-ID: <1265574196.2.0.694699956708.issue7874@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The fact that the second call will do nothing is specifically documented:

http://docs.python.org/dev/library/logging.html#logging.basicConfig

"This function does nothing if the root logger already has handlers configured for it."

This behaviour is by design, and not an accident caused by "bad coding style". Please check the documentation before posting issues which are not real issues. Thanks.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sun Feb  7 21:24:59 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 07 Feb 2010 20:24:59 +0000
Subject: [issue6003] ZipFile.writestr "compression_type" argument
In-Reply-To: <1242121006.26.0.494386960881.issue6003@psf.upfronthosting.co.za>
Message-ID: <1265574299.27.0.606284368021.issue6003@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Committed in r78097 (trunk) and r78098 (3.2). This includes the documentation change suggested in msg88437

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Feb  7 21:29:06 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 07 Feb 2010 20:29:06 +0000
Subject: [issue7875] test_multiprocessing / importlib failure
In-Reply-To: <1265569366.45.0.612808621772.issue7875@psf.upfronthosting.co.za>
Message-ID: <1265574546.83.0.936659036004.issue7875@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I don't know who is doing this, but from what I can tell it isn't test_imoprtlib; running with -i shows __import__ to still be the built-in one along with no new sys.path_hooks entries or stale entries in sys.path_importer_cache. Same goes for when I run test_multiprocessing after test_importlib.

I will probably have to modify regrtest to check for new values in some key places to see who the culprit is.

----------

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

From report at bugs.python.org  Sun Feb  7 21:29:18 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 07 Feb 2010 20:29:18 +0000
Subject: [issue7875] test_multiprocessing / importlib failure
In-Reply-To: <1265569366.45.0.612808621772.issue7875@psf.upfronthosting.co.za>
Message-ID: <1265574558.81.0.495110598176.issue7875@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
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: [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 21:52:09 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 07 Feb 2010 20:52:09 +0000
Subject: [issue7876] unittest docs use deprecated method in code example
In-Reply-To: <1265575599.07.0.775312626866.issue7876@psf.upfronthosting.co.za>
Message-ID: <1265575929.64.0.719458723578.issue7876@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks for the report, this is fixed in r77999 and r78000 in trunk and py3k, but it needs to be backported to 3.1.

----------
nosy: +ezio.melotti
priority:  -> normal

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

From report at bugs.python.org  Sun Feb  7 22:02:05 2010
From: report at bugs.python.org (Meador Inge)
Date: Sun, 07 Feb 2010 21:02:05 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1265573127.5.0.835385382898.issue6877@psf.upfronthosting.co.za>
Message-ID: <4095897c1002071302p3e8124eenc6523bad600a4363@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

> That bit is not in the trunk, should it be forward ported to the trunk?

FWIW, I would really like to have it.

> The actual prototype on 10.5 and 10.6 is:
>
> char           **completion_matches(const char *, CPFunction *);
>
> Wouldn't it be better to change the prototype in readline.c to match?

I may have missed something, but the patch is actually *excluding* the
prototype on OS X, i.e. #if *not* defined.  Thus the 'const char*' prototype
that comes in with 'readline.h' is the one that will be used.

On the other hand, if you are proposing to make them 'match' just to avoid
the redefinition conflict, then this may break on other systems where 'char
*' is used.

Regards,

-- Meador

----------
Added file: http://bugs.python.org/file16169/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________
-------------- next part --------------
<div><div>&gt;??That bit is not in the trunk, should it be forward ported to the trunk?</div><div><br></div><div>FWIW, I would really like to have it.</div><div><br></div><div>&gt; The actual prototype on 10.5 and 10.6 is:<br>
&gt;<br>&gt; char ?? ?? ?? ?? ?? **completion_matches(const char *, CPFunction *);<br>&gt;<br>&gt; Wouldn&#39;t it be better to change the prototype in readline.c to match?</div><div><br></div><div>I may have missed something, but the patch is actually *excluding* the prototype on OS X, i.e. #if *not* defined. ??Thus the &#39;const char*&#39; prototype that comes in with &#39;readline.h&#39; is the one that will be used.</div>
<div><br></div><div>On the other hand, if you are proposing to make them &#39;match&#39; just to avoid the??redefinition??conflict, then this may break on other systems where &#39;char *&#39; is used.</div><div><br></div><div>
Regards,</div><div><br><div class="gmail_quote">-- Meador</div>
</div></div>

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: [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:39:51 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 07 Feb 2010 21:39:51 +0000
Subject: [issue7501] python -m unittest path_to_suite_function errors
In-Reply-To: <1260742792.63.0.561457576654.issue7501@psf.upfronthosting.co.za>
Message-ID: <1265578791.66.0.872783270793.issue7501@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Is this needed as well as the load_tests protocol?

If a test module defines a load_tests function that returns a test suite then the following creates the test suite from load_tests and executes that:

    python -m unittest modulename

I don't think we need a test_suite protocol as well.

----------

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

From report at bugs.python.org  Sun Feb  7 22:48:12 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 07 Feb 2010 21:48:12 +0000
Subject: [issue7875] test_multiprocessing / importlib failure
In-Reply-To: <1265569366.45.0.612808621772.issue7875@psf.upfronthosting.co.za>
Message-ID: <1265579292.0.0.0711201165111.issue7875@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

OK, I figured this one out. Someone is using importlib.import_module() which uses importlib itself to do the import and not builtins.__import__. That has the side-effect of importlib replacing all None entries in sys.path_importer_cache with the finder that importlib creates (an optimization so that importlib doesn't have to re-construct the finder constantly and to slowly drop the use of None).

There are three ways to fix this. One is to not insert the new finders into sys.path_importer_cache. Two is to have importlib.import_module use __import__. Three is to leave it as-is (and to obviously fix the problem importlib is triggering).

>From a selfish perspective I like option 3 since it helps weed out bugs in importlib, but that is unfair to __import__ for testing plus it slows down the test suite overall from importlib being slower. And I won't do option 1 since that would make importlib perform even worse. So I guess that leaves option 2 unless people are actually okay with option 3.

----------

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

From report at bugs.python.org  Sun Feb  7 22:48:51 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 07 Feb 2010 21:48:51 +0000
Subject: [issue7875] test_multiprocessing / importlib failure
In-Reply-To: <1265569366.45.0.612808621772.issue7875@psf.upfronthosting.co.za>
Message-ID: <1265579331.75.0.314468748683.issue7875@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
dependencies: +importlib not checking bytecode length

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

From report at bugs.python.org  Sun Feb  7 22:52:05 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 07 Feb 2010 21:52:05 +0000
Subject: [issue7361] importlib not checking bytecode length
In-Reply-To: <1258658288.16.0.0772350847135.issue7361@psf.upfronthosting.co.za>
Message-ID: <1265579525.66.0.311429429043.issue7361@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

issue #7875 brought up the original failure that caused the creation of this bug again and led to me finally diagnosing the problem.

----------

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

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: [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:01:37 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 07 Feb 2010 22:01:37 +0000
Subject: [issue7361] importlib not checking bytecode length
In-Reply-To: <1258658288.16.0.0772350847135.issue7361@psf.upfronthosting.co.za>
Message-ID: <1265580097.24.0.609692173983.issue7361@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

A quick check of things shows that a totally empty file, a missing timestamp, or no marshalled code triggers the use of source. I still need to check what happens when the magic number is truncated by a byte or so along with the timestamp.

Any screw-up with the marshalled code should still be an error.

----------

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

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: [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:13 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 07 Feb 2010 23:22:13 +0000
Subject: [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 00:26:18 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 07 Feb 2010 23:26:18 +0000
Subject: [issue7880] sysconfig does not like symlinks
In-Reply-To: <1265584932.48.0.89611557521.issue7880@psf.upfronthosting.co.za>
Message-ID: <1265585178.76.0.0727602977898.issue7880@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
priority: normal -> high

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

From report at bugs.python.org  Mon Feb  8 00:28:45 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 07 Feb 2010 23:28:45 +0000
Subject: [issue7880] sysconfig does not like symlinks
In-Reply-To: <1265584932.48.0.89611557521.issue7880@psf.upfronthosting.co.za>
Message-ID: <1265585325.14.0.432731413373.issue7880@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Here's the traceback, I'll look at the problem asap

'import site' failed; traceback:
Traceback (most recent call last):
  File "/MacDev/svn.python.org/python-trunk/Lib/site.py", line 530, in <module>
    main()
  File "/MacDev/svn.python.org/python-trunk/Lib/site.py", line 509, in main
    addbuilddir()
  File "/MacDev/svn.python.org/python-trunk/Lib/site.py", line 118, in addbuilddir
    s = "build/lib.%s-%.3s" % (get_platform(), sys.version)
  File "/MacDev/svn.python.org/python-trunk/Lib/sysconfig.py", line 577, in get_platform
    cfgvars = get_config_vars()
  File "/MacDev/svn.python.org/python-trunk/Lib/sysconfig.py", line 402, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/MacDev/svn.python.org/python-trunk/Lib/sysconfig.py", line 255, in _init_posix
    raise IOError(msg)
IOError: invalid Python installation: unable to open /usr/local/lib/python2.7/config/Makefile (No such file or directory)

----------

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

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


Florent Xicluna <laxyf at yahoo.fr> added the comment:

proposed fix.

----------
keywords: +patch
Added file: http://bugs.python.org/file16172/issue7880_sysconfig.diff

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

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


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
stage:  -> patch review

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

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


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16172/issue7880_sysconfig.diff

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

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


Florent Xicluna <laxyf at yahoo.fr> added the comment:

actually realpath == abspath on most platforms where symlink is not implemented.

Changed.

----------
Added file: http://bugs.python.org/file16173/issue7880_sysconfig.diff

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

From report at bugs.python.org  Mon Feb  8 00:59:18 2010
From: report at bugs.python.org (Zvezdan Petkovic)
Date: Sun, 07 Feb 2010 23:59:18 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265587158.09.0.0178794269328.issue6877@psf.upfronthosting.co.za>


Zvezdan Petkovic <zvezdan at zope.com> added the comment:

Ronald,

> That bit is not in the trunk, should it be forward ported to the trunk?

Yes, that should be applied to trunk and 3.x to make it work on Mac OS X 10.5 (Leopard).  I indicated that in msg98979.

The explanation why that part is needed is given in msg98978 and msg98913.
That ultimately points to re-declaration of completion_matches() inserted in a patch in issue4204 (see my comments in the last two messages there).

We must *avoid* the duplicate declaration on Mac OS X, because the same declaration is already in /usr/include/readline/readline.h.
Hence #if !defined(__APPLE__) is used.

So, the readline-libedit-trunk.patch I attached yesterday should be applied to trunk (2.7) and 3.x.

> As that's not a critical change I've committed the fix1 patch as is in r78096.

It seems that you forgot to

        svn add Lib/test/test_readline.py

before committing.
If you run svn status on that checkout I bet it will show with '?' in the left column.

P.S.
FWIW, you are right about #include <stdlib.h>.  I removed it from the patch yesterday (notice attachment, removal, and a new attachment in the history).

----------

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

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: [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 01:48:01 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 08 Feb 2010 00:48:01 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265590081.0.0.897052584821.issue7712@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Almost completed patch, the code should be OK, I just have to add a few comments and check that it works fine in all the situations.

----------
Added file: http://bugs.python.org/file16175/issue7712v2.diff

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

From report at bugs.python.org  Mon Feb  8 02:01:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Feb 2010 01:01:10 +0000
Subject: [issue5341] A selection of spelling errors and typos throughout source
In-Reply-To: <1235244250.3.0.963079671793.issue5341@psf.upfronthosting.co.za>
Message-ID: <1265590870.35.0.216137913693.issue5341@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I should have seen this when changing one use of ?builtin?. Applies only to py3k, since the glossary for trunk does not mention the `next` function.

----------
Added file: http://bugs.python.org/file16176/typo.diff

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

From report at bugs.python.org  Mon Feb  8 04:05:42 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Mon, 08 Feb 2010 03:05:42 +0000
Subject: [issue7843] python-dev archives are not updated
In-Reply-To: <1265178890.74.0.190962980731.issue7843@psf.upfronthosting.co.za>
Message-ID: <1265598342.32.0.253389227161.issue7843@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

As of Feb 2, 2010, archives seem to be functioning as expected ;-)

----------
status: open -> closed

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

From report at bugs.python.org  Mon Feb  8 04:14:26 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 08 Feb 2010 03:14:26 +0000
Subject: [issue5802] The security descriptors of python binaries in Windows
	are not strict enough
In-Reply-To: <1240245750.84.0.391245943129.issue5802@psf.upfronthosting.co.za>
Message-ID: <1265598866.93.0.78611451721.issue5802@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
stage:  -> test needed

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

From report at bugs.python.org  Mon Feb  8 04:29:09 2010
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 08 Feb 2010 03:29:09 +0000
Subject: [issue7881] Hardcoded path, unsafe tempfile in test_logging
In-Reply-To: <1265587590.8.0.102752265888.issue7881@psf.upfronthosting.co.za>
Message-ID: <1265599749.99.0.196232988804.issue7881@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

In addition, the /tmp/tmp.txt file is only writeable by the user that created it.  On the buildbot machine I'm admin'ing, the buildslave user created the file and user neal's run of build.sh on the trunk fails because it can't write the file.  Also, to avoid clutter in /tmp, the file should not only be created safely as Neil suggests, but removed when the test is complete.

----------
nosy: +kbk

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

From report at bugs.python.org  Mon Feb  8 07:31:46 2010
From: report at bugs.python.org (Hong Chen)
Date: Mon, 08 Feb 2010 06:31:46 +0000
Subject: [issue5802] The security descriptors of python binaries in Windows
	are not strict enough
In-Reply-To: <1265598867.01.0.00874173720179.issue5802@psf.upfronthosting.co.za>
Message-ID: <3ec02ba21002072231o30353177s168d640c3aced0dd@mail.gmail.com>


Hong Chen <cn.hongchen at gmail.com> added the comment:

Thanks for the reply.  I can log in as a non-admin user and replace
python.exe with another binary.  Does that serve as an attack example?

Hong

On Sun, Feb 7, 2010 at 7:14 PM, Brian Curtin <report at bugs.python.org> wrote:
>
> Changes by Brian Curtin <curtin at acm.org>:
>
>
> ----------
> stage: ?-> test needed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5802>
> _______________________________________
>

----------

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

From report at bugs.python.org  Mon Feb  8 07:51:23 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 08 Feb 2010 06:51:23 +0000
Subject: [issue7881] Hardcoded path, unsafe tempfile in test_logging
In-Reply-To: <1265587590.8.0.102752265888.issue7881@psf.upfronthosting.co.za>
Message-ID: <1265611883.46.0.291344196131.issue7881@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Sorry for the goof; that line was unintentionally left in. Now removed (r78103).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
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: [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 10:20:07 2010
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Mon, 08 Feb 2010 09:20:07 +0000
Subject: [issue7876] unittest docs use deprecated method in code example
In-Reply-To: <1265575599.07.0.775312626866.issue7876@psf.upfronthosting.co.za>
Message-ID: <1265620807.25.0.777958239661.issue7876@psf.upfronthosting.co.za>


Bernt R?skar Brenna <bernt.brenna at gmail.com> added the comment:

Sorry, forgot to check svn, I was looking at the 3.1.1 release tarball.

----------

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

From report at bugs.python.org  Mon Feb  8 11:17:37 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Feb 2010 10:17:37 +0000
Subject: [issue2777] subprocess unit tests for kill, term and send_signal flaky
In-Reply-To: <1210117255.49.0.763796854564.issue2777@psf.upfronthosting.co.za>
Message-ID: <1265624257.89.0.433164785789.issue2777@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
nosy: +flox

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

From report at bugs.python.org  Mon Feb  8 12:18:32 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Feb 2010 11:18:32 +0000
Subject: [issue2777] subprocess unit tests for kill, term and send_signal flaky
In-Reply-To: <1210117255.49.0.763796854564.issue2777@psf.upfronthosting.co.za>
Message-ID: <1265627912.09.0.892227396611.issue2777@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The patch looks fine.
+1 to enable on trunk and follow the buildbots' behavior.

----------

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

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: [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: [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 14:00:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Feb 2010 13:00:44 +0000
Subject: [issue7857] test_logging fails
In-Reply-To: <1265378336.27.0.807146257248.issue7857@psf.upfronthosting.co.za>
Message-ID: <1265634044.33.0.69392978482.issue7857@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There are still random failures:

test test_logging failed -- Traceback (most recent call last):
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/test/test_logging.py", line 1612, in test_listen_config_10_ok
    ], stream=output)
  File "/home2/buildbot/slave/trunk.loewis-sun/build/Lib/test/test_logging.py", line 116, in assert_log_lines
    self.assertEquals(len(actual_lines), len(expected_values))
AssertionError: 0 != 2

See http://www.python.org/dev/buildbot/trunk/builders/sparc%20solaris10%20gcc%20trunk/builds/348

----------

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

From report at bugs.python.org  Mon Feb  8 15:07:35 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 08 Feb 2010 14:07:35 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1265638055.92.0.848174524203.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file15933/windows symlink draft 19.patch

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

From report at bugs.python.org  Mon Feb  8 15:07:44 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 08 Feb 2010 14:07:44 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1265638064.34.0.778296449316.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file16003/windows symlink draft 20.patch

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

From report at bugs.python.org  Mon Feb  8 15:13:32 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 08 Feb 2010 14:13:32 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1265638412.28.0.996982913337.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Added file: http://bugs.python.org/file16178/windows symlink draft 21.patch

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

From report at bugs.python.org  Mon Feb  8 15:13:40 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 08 Feb 2010 14:13:40 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1265638420.62.0.867798779749.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file16174/windows symlink draft 21.patch

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

From report at bugs.python.org  Mon Feb  8 15:53:47 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 08 Feb 2010 14:53:47 +0000
Subject: [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: <1265640827.04.0.132072083623.issue7884@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> test needed
type: crash -> behavior

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

From report at bugs.python.org  Mon Feb  8 16:21:26 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 08 Feb 2010 15:21:26 +0000
Subject: [issue7857] test_logging fails
In-Reply-To: <1265634044.33.0.69392978482.issue7857@psf.upfronthosting.co.za>
Message-ID: <19629.7206.qm@web25807.mail.ukl.yahoo.com>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

----- Original Message ----

> From: Antoine Pitrou <report at bugs.python..org>
> 
> There are still random failures:
> 

Ouch. I'm not sure that I can debug this quickly, because the tests work on all platforms I've got access to (Windows XP, Linux Jaunty) and even where they fail, the verbose re-test often succeeds. Perhaps I should just re-enable skipping of those tests for now to avoid problems on the buildbots, and see if I can get a reproducible error on the systems I have access to.

Any suggestions gratefully received :-)

----------

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

From report at bugs.python.org  Mon Feb  8 16:23:04 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 08 Feb 2010 15:23:04 +0000
Subject: [issue5802] The security descriptors of python binaries in Windows
	are not strict enough
In-Reply-To: <1240245750.84.0.391245943129.issue5802@psf.upfronthosting.co.za>
Message-ID: <1265642584.58.0.729329564395.issue5802@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Is the situation any different if you install Python to "C:\Program Files"? This seems to be at least part of the reason IronPython installs to "C:\Program Files", which was discussed on the IronPython list [1] a few months ago.


[1] http://lists.ironpython.com/pipermail/users-ironpython.com/2009-October/011345.html

----------
nosy: +brian.curtin

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

From report at bugs.python.org  Mon Feb  8 16:38:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 08 Feb 2010 15:38:41 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265643521.11.0.918139694297.issue6877@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
nosy: +Alexander.Belopolsky

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

From report at bugs.python.org  Mon Feb  8 16:47:27 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 08 Feb 2010 15:47:27 +0000
Subject: [issue7883] CallTips.py _find_constructor does not work
In-Reply-To: <1265631103.87.0.399117397925.issue7883@psf.upfronthosting.co.za>
Message-ID: <1265644047.35.0.979144116164.issue7883@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

That change works for me.

----------
nosy: +brian.curtin
priority:  -> normal
stage:  -> test needed

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

From report at bugs.python.org  Mon Feb  8 17:12:32 2010
From: report at bugs.python.org (Tim Golden)
Date: Mon, 08 Feb 2010 16:12:32 +0000
Subject: [issue7877] Iterators over _winreg EnumKey and EnumValue results
In-Reply-To: <1265578300.82.0.0744515010877.issue7877@psf.upfronthosting.co.za>
Message-ID: <4B7037E9.8070101@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
WindowsError: [Error 6] The handle is invalid

I suspect that .iterkeys / .itervalues would be more
acceptable spellings as those mirror the dict methods.
Whether the idea of extending _winreg beyond the absolute
basics will fly I'm not sure. I don't often use it, but
this would be useful if I did...

#
On 07/02/2010 21:31, Brian Curtin wrote:
>
> 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>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/mail%40timgolden.me.uk

----------
nosy: +tim.golden

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

From report at bugs.python.org  Mon Feb  8 17:16:46 2010
From: report at bugs.python.org (Tim Golden)
Date: Mon, 08 Feb 2010 16:16:46 +0000
Subject: [issue7877] Iterators over _winreg EnumKey and EnumValue results
In-Reply-To: <4B7037E9.8070101@timgolden.me.uk>
Message-ID: <4B7038DF.8040409@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Sorry; the email interface messed that up. The code
which triggered the error was:

import _winreg
list (
     _winreg.IterValue (
         _winreg.OpenKey (_winreg.HKEY_CURRENT_USER, "Console")
      )
)

----------

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

From report at bugs.python.org  Mon Feb  8 17:20:12 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 08 Feb 2010 16:20:12 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265646012.44.0.340655805547.issue7712@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Final version of the patch, with the temp_cwd context manager added to test_support and used in test_regrtest to run the test suite in a temporary directory. It also includes a fix for test_subprocess that was failing when the tests are not run in the original cwd.

----------
Added file: http://bugs.python.org/file16179/issue7712v3.diff

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

From report at bugs.python.org  Mon Feb  8 17:25:39 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 08 Feb 2010 16:25:39 +0000
Subject: [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: <1265646339.8.0.338688675654.issue7884@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Duplicate of #1028 (and #6920).

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Feb  8 17:35:27 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 08 Feb 2010 16:35:27 +0000
Subject: [issue7877] Iterators over _winreg EnumKey and EnumValue results
In-Reply-To: <1265578300.82.0.0744515010877.issue7877@psf.upfronthosting.co.za>
Message-ID: <1265646927.57.0.382315866216.issue7877@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Interesting, I'll take a look and see why that's happening.

Good point about the names.

----------

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

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: [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 18:07:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Feb 2010 17:07:45 +0000
Subject: [issue7875] test_multiprocessing / importlib failure
In-Reply-To: <1265569366.45.0.612808621772.issue7875@psf.upfronthosting.co.za>
Message-ID: <1265648865.59.0.418808164875.issue7875@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That would be test_support.import_module, which at your recommendation I changed to use importlib.import_module at the last pycon sprint :)

I'm not clear on why option 3 would interfere with __import__ getting tested?

----------
nosy: +r.david.murray

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

From report at bugs.python.org  Mon Feb  8 18:08:40 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Feb 2010 17:08:40 +0000
Subject: [issue7875] test_multiprocessing / importlib failure
In-Reply-To: <1265569366.45.0.612808621772.issue7875@psf.upfronthosting.co.za>
Message-ID: <1265648920.03.0.301404880242.issue7875@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I meant test.support for py3k, of course.

----------

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

From report at bugs.python.org  Mon Feb  8 18:22:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Feb 2010 17:22:45 +0000
Subject: [issue7875] test_multiprocessing / importlib failure
In-Reply-To: <1265569366.45.0.612808621772.issue7875@psf.upfronthosting.co.za>
Message-ID: <1265649765.42.0.932420880633.issue7875@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> That would be test_support.import_module, which at your recommendation 
> I changed to use importlib.import_module at the last pycon sprint :)

I don't think it's the culprit. According to the traceback, importlib is triggered by a simple "import xmlrpc.client as xmlrpclib".

----------

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

From report at bugs.python.org  Mon Feb  8 18:32:50 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 08 Feb 2010 17:32:50 +0000
Subject: [issue7875] test_multiprocessing / importlib failure
In-Reply-To: <1265569366.45.0.612808621772.issue7875@psf.upfronthosting.co.za>
Message-ID: <1265650370.51.0.164363726219.issue7875@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So option 3 would marginalize __import__ testing as importlib's finders and loaders as pulled from sys.path_importer_cache would be used over __import__'s own implicit importers that it contains.

As for test.support.import_module being the culprit, it is. The reason the traceback shows an import statement as the trigger is that __import__ is using a loader as defined by importlib.

----------

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

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: [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  Mon Feb  8 20:04:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Feb 2010 19:04:03 +0000
Subject: [issue7875] test_multiprocessing / importlib failure
In-Reply-To: <1265569366.45.0.612808621772.issue7875@psf.upfronthosting.co.za>
Message-ID: <1265655843.77.0.340074506179.issue7875@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Option 3 is ok with me.

There could also be option 4: add a special flag (or environment var) to regrtest so as to run all tests with __import__ pulled from importlib. Then we can setup a buildbot with that flag / env var.

----------

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

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


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

list.reverse() reverses the list *in place* and returns None, and "for item in None: ..." correctly raises a TypeError because None is not iterable.

You either want 
for item in reversed(mylist): ...
or
mylist.reverse()
for item in mylist: ...

----------
nosy: +ezio.melotti
priority:  -> low
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Feb  8 20:12:51 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 08 Feb 2010 19:12:51 +0000
Subject: [issue7875] test_multiprocessing / importlib failure
In-Reply-To: <1265569366.45.0.612808621772.issue7875@psf.upfronthosting.co.za>
Message-ID: <1265656371.16.0.580210209071.issue7875@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Importlib actually already can do this: importlib.test.regrtest. It runs regrtest after importlib has been set for __import__. It also skips tests known to fail for stupid reasons (typically they don't expect __loader__ to be defined). You can also run the importlib tests using __import__; importlib.test --builtin.

Anyway, seems like people are fine with option 3, and since that's the easiest that's what I will go with.

----------

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

From report at bugs.python.org  Mon Feb  8 20:15:59 2010
From: report at bugs.python.org (Otto)
Date: Mon, 08 Feb 2010 19:15:59 +0000
Subject: [issue7296] OverflowError: signed integer is greater than maximum on
	mips64
In-Reply-To: <1257807734.54.0.518943570242.issue7296@psf.upfronthosting.co.za>
Message-ID: <1265656559.02.0.254844246035.issue7296@psf.upfronthosting.co.za>


Otto <otto at drijf.net> added the comment:

This problem has been diagnosed as a problem in the mips64 port of OpenBSD. mips64 systems need to emulate some floating point instructions in software, depending on the cpu type. In this case we hit an instruction for which the emulation was incomplete. The floating point exception actually signals this.

Work is being done to fix this.

----------
nosy: +omoerbeek

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

From report at bugs.python.org  Mon Feb  8 20:34:43 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 08 Feb 2010 19:34:43 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1265657683.48.0.315277966707.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This latest patch (22) does some refactoring in test_posixpath to reduce nesting, limit duplicated code, and skip failing tests on Windows.

The only task now is to address the failing tests in a limited user account.

----------
Added file: http://bugs.python.org/file16180/windows symlink draft 22.patch

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

From report at bugs.python.org  Mon Feb  8 20:34:54 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 08 Feb 2010 19:34:54 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and
	os.path.islink()	support for Windows
Message-ID: <1265657694.24.0.758489101275.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file16178/windows symlink draft 21.patch

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

From report at bugs.python.org  Mon Feb  8 20:39:32 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Feb 2010 19:39:32 +0000
Subject: [issue7878] regrtest should check for changes in import machinery
In-Reply-To: <1265579778.81.0.993838177381.issue7878@psf.upfronthosting.co.za>
Message-ID: <1265657972.77.0.480870150904.issue7878@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
nosy: +flox

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

From report at bugs.python.org  Mon Feb  8 20:56:33 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Feb 2010 19:56:33 +0000
Subject: [issue6366] rare assertion failure in test_multiprocessing
In-Reply-To: <1246282026.12.0.299929398487.issue6366@psf.upfronthosting.co.za>
Message-ID: <1265658993.03.0.858674733039.issue6366@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
resolution:  -> duplicate
superseder:  -> Transient error in multiprocessing

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

From report at bugs.python.org  Mon Feb  8 20:57:31 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Feb 2010 19:57:31 +0000
Subject: [issue6366] rare assertion failure in test_multiprocessing
In-Reply-To: <1246282026.12.0.299929398487.issue6366@psf.upfronthosting.co.za>
Message-ID: <1265659051.3.0.398442652139.issue6366@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Closed as duplicate.

----------
nosy: +flox
stage: needs patch -> 
status: open -> closed

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

From report at bugs.python.org  Mon Feb  8 20:59:35 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Feb 2010 19:59:35 +0000
Subject: [issue6747] test test_multiprocessing failed
In-Reply-To: <1250813386.91.0.61030699326.issue6747@psf.upfronthosting.co.za>
Message-ID: <1265659175.29.0.869099490051.issue6747@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

See #5930.

----------
nosy: +flox
resolution:  -> duplicate
stage: test needed -> 
status: open -> closed
superseder:  -> Transient error in multiprocessing

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

From report at bugs.python.org  Mon Feb  8 21:01:15 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 08 Feb 2010 20:01:15 +0000
Subject: [issue5930] Transient error in multiprocessing
In-Reply-To: <1241472804.71.0.981647805709.issue5930@psf.upfronthosting.co.za>
Message-ID: <1265659275.2.0.935180514785.issue5930@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
components: +Tests
stage: needs patch -> test needed
versions: +Python 3.2

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

From report at bugs.python.org  Mon Feb  8 21:31:52 2010
From: report at bugs.python.org (Thomas Spura)
Date: Mon, 08 Feb 2010 20:31:52 +0000
Subject: [issue7861] 2to3: "import foo" ->  "from . import foo"
In-Reply-To: <1265398652.17.0.813820450189.issue7861@psf.upfronthosting.co.za>
Message-ID: <1265661112.84.0.46112778185.issue7861@psf.upfronthosting.co.za>


Thomas Spura <tomspur at fedoraproject.org> added the comment:

The commit I'm talking about was 22 months ago (r61755), python 2.6.2 was released April 14, 2009.

At least strange, that this is not jet in there, but if you think, it will in the next version...

----------

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

From report at bugs.python.org  Mon Feb  8 21:59:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 08 Feb 2010 20:59:35 +0000
Subject: [issue7296] OverflowError: signed integer is greater than maximum on
	mips64
In-Reply-To: <1257807734.54.0.518943570242.issue7296@psf.upfronthosting.co.za>
Message-ID: <1265662775.51.0.0686959654068.issue7296@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Many thanks for the update.  I'll close this as not a Python bug, then.
(Unless there's an easy and nonintrusive workaround...)

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Mon Feb  8 23:08:46 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 08 Feb 2010 22:08:46 +0000
Subject: [issue7876] unittest docs use deprecated method in code example
In-Reply-To: <1265575599.07.0.775312626866.issue7876@psf.upfronthosting.co.za>
Message-ID: <1265666926.86.0.00542056721043.issue7876@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed on 3.1 in r78111.

----------
assignee: georg.brandl -> ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Feb  8 23:16:34 2010
From: report at bugs.python.org (Brian Harring)
Date: Mon, 08 Feb 2010 22:16:34 +0000
Subject: [issue7826] support caching for 2to3
In-Reply-To: <1264985952.93.0.779639488883.issue7826@psf.upfronthosting.co.za>
Message-ID: <1265667394.32.0.187772865522.issue7826@psf.upfronthosting.co.za>


Brian Harring <ferringb at gmail.com> added the comment:

Contributor agreement form is enroute via snail mail... kind of wish y'all accepted pdf's via email though ;)

As for the print("cache hit"), that should be punted- not very useful in it's current form (doesn't indicate what 'hit') and slipped in accidentally.

----------

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

From report at bugs.python.org  Tue Feb  9 00:31:55 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 08 Feb 2010 23:31:55 +0000
Subject: [issue7032] Make assertMultilineEqual default for unicode string
	comparison in
In-Reply-To: <1254436185.92.0.46884038882.issue7032@psf.upfronthosting.co.za>
Message-ID: <1265671915.92.0.140221678361.issue7032@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Revision 78116.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Feb  9 00:46:01 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Mon, 08 Feb 2010 23:46:01 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1265672761.49.0.985130696061.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Hi, thanks for the update! 
Just for the unlikely case, it hasn't been noticed sofar, using python  2.6.4 or 2.5.4 with the regexp build issue2636-20100204.zip
I am getting the following easy-to-fix error:

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 regex
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python26\lib\regex.py", line 2003
    print "Header file written at %s\n" % os.path.abspath(header_file.name))
                                                                           ^
SyntaxError: invalid syntax

After removing the extra closing paren in regex.py, line 2003, everything seems ok.
   vbr

----------

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

From report at bugs.python.org  Tue Feb  9 00:46:43 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 08 Feb 2010 23:46:43 +0000
Subject: [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: <1265672803.12.0.0812380832009.issue7855@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Does this need committing? Dino - do you have checkin rights?

----------

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

From report at bugs.python.org  Tue Feb  9 00:46:58 2010
From: report at bugs.python.org (Jordan Apgar)
Date: Mon, 08 Feb 2010 23:46:58 +0000
Subject: [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 00:58:02 2010
From: report at bugs.python.org (Dino Viehland)
Date: Mon, 08 Feb 2010 23:58:02 +0000
Subject: [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: <1265673482.51.0.420241919898.issue7855@psf.upfronthosting.co.za>


Dino Viehland <dinov at microsoft.com> added the comment:

Brett Cannon was going to try and look at it and commit it.  If you think it looks good you can commit it :)

I do not yet have commit privledges simply because I need to gen my SSH key and send that off to Brett.  I'm also hoping to get a little hand holding on the 1st few check-ins.

----------

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

From report at bugs.python.org  Tue Feb  9 00:59:11 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 08 Feb 2010 23:59:11 +0000
Subject: [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: <1265673551.41.0.232890278422.issue7855@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Well, probably better for you to get the commit bit and DIY then. :-)

----------

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

From report at bugs.python.org  Tue Feb  9 01:15:15 2010
From: report at bugs.python.org (Michael Newman)
Date: Tue, 09 Feb 2010 00:15:15 +0000
Subject: [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: [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 01:22:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 00:22:43 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265674963.59.0.821995690304.issue7712@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

With the latest patch I get one failure: test_bufio. I piped that test to a file and attached the results here. There are numerous "Permission denied: @test" IOErrors.

----------
Added file: http://bugs.python.org/file16181/test_bufio.stdout.txt

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

From report at bugs.python.org  Tue Feb  9 01:50:36 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 00:50:36 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265676636.56.0.553507712438.issue7712@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Brian, is it the only one failing?
Did you have some test running before? Which one? (alphabetic order?)

Do you reproduce the error when running this test alone?
  "-m test.regrtest -uall test_bufio"

----------

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

From report at bugs.python.org  Tue Feb  9 02:25:48 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Feb 2010 01:25:48 +0000
Subject: [issue7826] support caching for 2to3
In-Reply-To: <1264985952.93.0.779639488883.issue7826@psf.upfronthosting.co.za>
Message-ID: <1265678748.57.0.247871743774.issue7826@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I'm apprehensive about accepting this patch for several reasons. First of all, it has no tests. Secondly, and more importantly, I dislike the hacks that it adds. I would prefer 2to3 to grow a more general plugin API, which people could use to add new fixer etc as well and customizes behavior like this.

----------
keywords:  -needs review
priority: normal -> low

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

From report at bugs.python.org  Tue Feb  9 02:31:54 2010
From: report at bugs.python.org (tormen)
Date: Tue, 09 Feb 2010 01:31:54 +0000
Subject: [issue7886] reverse on an empty list returns None
In-Reply-To: <1265655823.9.0.9257468855.issue7886@psf.upfronthosting.co.za>
Message-ID: <1265679114.74.0.430331947013.issue7886@psf.upfronthosting.co.za>


tormen <tormen at gmx.net> added the comment:

Thanks for your nice feedback even though my bug report was so stupid!

----------

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

From report at bugs.python.org  Tue Feb  9 04:02:19 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 03:02:19 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265684539.95.0.0601468441371.issue7712@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Yep, that's the only one failing. The output I attached is the result of running the test alone.

----------

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

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: [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 04:17:16 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 09 Feb 2010 03:17:16 +0000
Subject: [issue7889] random produces different output on different
	architectures
In-Reply-To: <1265674553.33.0.380899973746.issue7889@psf.upfronthosting.co.za>
Message-ID: <1265685435.99.0.490745081165.issue7889@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Would you like to work on a patch?

----------
nosy: +loewis

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

From report at bugs.python.org  Tue Feb  9 04:22:34 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 09 Feb 2010 03:22:34 +0000
Subject: [issue7890] equal unicode/str objects can have unequal hash
In-Reply-To: <1265684782.83.0.641089509966.issue7890@psf.upfronthosting.co.za>
Message-ID: <1265685754.04.0.659560196541.issue7890@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is not a bug in Python, but in your code. sys.setdefaultencoding is only supported when setting the default encoding to either latin-1, or ascii, or 'undefined'. Setting it to any other value will have undesirable consequences like the one you report. Likewise, changing it after any Unicode objects have been created is not supported, either.

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Tue Feb  9 07:52:14 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 09 Feb 2010 06:52:14 +0000
Subject: [issue7889] random produces different output on different
	architectures
In-Reply-To: <1265674553.33.0.380899973746.issue7889@psf.upfronthosting.co.za>
Message-ID: <1265698334.51.0.0950016582173.issue7889@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Hmm, this may be difficult to fix without breaking somebody's expectation of repeating sequences they've already generated.

The code is in random_getrandbits():

http://svn.python.org/view/python/trunk/Modules/_randommodule.c?revision=72344&view=markup

----------
assignee:  -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Tue Feb  9 08:11:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 07:11:04 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265699464.21.0.945998289753.issue7712@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Ok, it may be not related directly with this patch.

Can you diagnose if it something like #7443?

----------

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

From report at bugs.python.org  Tue Feb  9 08:15:55 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 07:15:55 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1265699755.73.0.20535111755.issue7443@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Another report of something looking very similar on #7712.

----------
nosy: +brian.curtin, flox
priority: low -> high

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

From report at bugs.python.org  Tue Feb  9 08:18:06 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 07:18:06 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265699886.58.0.562809082015.issue7712@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

And you could try the patch attached to #7443, and see if it fixes the test_bufio issue.

----------

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

From report at bugs.python.org  Tue Feb  9 08:40:13 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 07:40:13 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265701213.23.0.015342131357.issue7712@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The command line used to run the tests is important.
If you run through "test.regrtest", it should "chdir" to a sandbox directory to run the test. If you call directly the test_bufio.py file, it runs in the current directory (as before the patch).
And the permission of the current directory may give a difference in the 2nd case.

Variants:
 python.exe -m test.regrtest test_bufio
 python.exe Lib/test/regrtest.py test_bufio
 python.exe Lib/test/test_bufio.py    (fail if home directory is RO)

And another full run:
 python.exe -m test.regrtest

Try some of these variants, it may help diagnose the windows issue.

(Note: maybe some antivirus or other software may be related to the race condition described on #7443)

----------

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

From report at bugs.python.org  Tue Feb  9 09:05:32 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 09 Feb 2010 08:05:32 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1265702732.07.0.406626241473.issue7582@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

So, is that right that even if time.daylight specifies the offset, this doesn't mean that this offset is active?

MS documentation you referenced is unclear: "The _get_daylight function retrieves the number of hours in daylight saving time as an integer. If daylight saving time is in effect, the default offset is one hour."

>From this description it is easy to assume that if DST is not in effect then default offset would be 0.

----------

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

From report at bugs.python.org  Tue Feb  9 09:05:51 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 08:05:51 +0000
Subject: [issue7443] test.support.unlink issue on Windows platform
In-Reply-To: <1260026404.41.0.635406889881.issue7443@psf.upfronthosting.co.za>
Message-ID: <1265702751.91.0.499227243418.issue7443@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Note: the fix in test_linecache.py is useless.

The "with open(source_name, 'w') as source:" context manager is in charge of closing the file on __exit__.

----------

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

From report at bugs.python.org  Tue Feb  9 09:08:37 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 08:08:37 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265702917.23.0.347861884806.issue7712@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16167/issue7712_context_manager_v5.diff

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

From report at bugs.python.org  Tue Feb  9 09:11:19 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Feb 2010 08:11:19 +0000
Subject: [issue7887] errno 107 socket.recv issure
In-Reply-To: <1265672817.82.0.408353055509.issue7887@psf.upfronthosting.co.za>
Message-ID: <1265703079.15.0.142477584217.issue7887@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The issue tracker is not to a place to find problems in your code (network programming is difficult, even with python).
Please ask your questions on the comp.lang.python newsgroup, where many people will be ready to help you.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Tue Feb  9 09:40:36 2010
From: report at bugs.python.org (WK.)
Date: Tue, 09 Feb 2010 08:40:36 +0000
Subject: [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: <1265704836.16.0.954370874177.issue7882@psf.upfronthosting.co.za>


WK. <wolf.st.kappesser at gmx.de> added the comment:

Should use setup.py instead of make.

----------
status: open -> closed

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

From report at bugs.python.org  Tue Feb  9 09:44:30 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 09 Feb 2010 08:44:30 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1265705070.41.0.13908807034.issue7582@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

You are right.
----[pydst.py]------
import time

print time.asctime()
print time.localtime().tm_isdst
print time.daylight
--------------------

Tue Feb 09 10:31:47 2010
0
1

Sun May 09 10:33:20 2010
1
1


There is already an issue #7229 to correct the docs. I'll adjust my patch accordingly. Thanks for collaboration.

----------

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

From report at bugs.python.org  Tue Feb  9 09:51:17 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 09 Feb 2010 08:51:17 +0000
Subject: [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: <1265705477.12.0.221951959847.issue7882@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I don't understand the second message: you should use make instead of setup.py during the build/installation of python from source.

The build warnings are harmless, although you aren't building what you think you are.

The configure line should be "./configure --enable-universalsdk=/ --with-universal-archs=64-bit", the with-universal-archs option is ignored without enabling the universalsdk.   

Note that 2.7 and 3.2 (an possibly 2.6.5) will complain when you specify  --with-universal-archs without specifying --enable-universalsdk.

(Keeping the issue closed because there doesn't seem to be a real issue)

----------
resolution:  -> works for me

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

From report at bugs.python.org  Tue Feb  9 10:05:10 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 09 Feb 2010 09:05:10 +0000
Subject: [issue7852] [PATCH] Drop "Computer" from "Apple Computer" in plistlib
In-Reply-To: <1265274130.06.0.273637901356.issue7852@psf.upfronthosting.co.za>
Message-ID: <1265706310.97.0.218336058441.issue7852@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
assignee:  -> ronaldoussoren

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

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: [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 10:32:40 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 09 Feb 2010 09:32:40 +0000
Subject: [issue7229] [PATCH] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1265707960.91.0.557975851511.issue7229@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Run into the same problem in issue #7582. Patch attached, but wording can be improved.

http://docs.python.org/library/time.html#time.daylight

----------
keywords: +patch
nosy: +techtonik
title: Manual entry for time.daylight can be misleading -> [PATCH] Manual entry for time.daylight can be misleading
type: feature request -> behavior
Added file: http://bugs.python.org/file16182/issue7229_daylight_doc_misleading.diff

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

From report at bugs.python.org  Tue Feb  9 11:08:55 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 10:08:55 +0000
Subject: [issue7808] test_bsddb3 leaks references
In-Reply-To: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>
Message-ID: <1265710135.51.0.904238516924.issue7808@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16039/issue7808_bsddb3_refleak.diff

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

From report at bugs.python.org  Tue Feb  9 11:10:10 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 10:10:10 +0000
Subject: [issue7808] test_bsddb3 leaks references
In-Reply-To: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>
Message-ID: <1265710210.47.0.00589108361336.issue7808@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch updated for latest trunk.

----------
Added file: http://bugs.python.org/file16183/issue7808_bsddb3_refleak_v2.diff

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

From report at bugs.python.org  Tue Feb  9 11:17:50 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 10:17:50 +0000
Subject: [issue5930] Transient error in multiprocessing
In-Reply-To: <1241472804.71.0.981647805709.issue5930@psf.upfronthosting.co.za>
Message-ID: <1265710670.19.0.359897428898.issue5930@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Closed duplicate reports #6366 and #6747.

----------
nosy: +flox

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

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


lplatypus <luke at deller.id.au> added the comment:

Okay thanks, but in that case might I suggest that this limitation be mentioned in the documentation for sys.setdefaultencoding?  It currently reads as if any available encoding is acceptable. Perhaps even a warning or exception should be produced when calling it wrongly?

Other places that may need review include:
- the programming FAQ on python.org which presents the option of calling setdefaultencoding('mbcs') on windows ( http://www.python.org/doc/faq/programming/#what-does-unicodeerror-ascii-decoding-encoding-error-ordinal-not-in-range-128-mean )
- the comments in site.py which provoke changing the default encoding
- PEP100 which suggests enabling this code in site.py

BTW would patches ever be considered to fix issues such as this with using other encodings as default encodings, or is there some objection to the concept?

----------

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

From report at bugs.python.org  Tue Feb  9 11:56:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Feb 2010 10:56:23 +0000
Subject: [issue6608] asctime causing python to crash
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1265712983.73.0.692721351489.issue6608@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brett.cannon, lemburg
priority: normal -> release blocker

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

From report at bugs.python.org  Tue Feb  9 11:57:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 09 Feb 2010 10:57:38 +0000
Subject: [issue7889] random produces different output on different
	architectures
In-Reply-To: <1265674553.33.0.380899973746.issue7889@psf.upfronthosting.co.za>
Message-ID: <1265713058.22.0.182740110483.issue7889@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Tue Feb  9 12:02:08 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 09 Feb 2010 11:02:08 +0000
Subject: [issue7229] [PATCH] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1265713328.89.0.75165231496.issue7229@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Perhaps altzone() documentation is also wrong.  Brian, can you comment on this? 

http://docs.python.org/library/time.html#time.altzone

----------
nosy: +brian.curtin

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

From report at bugs.python.org  Tue Feb  9 12:14:54 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 09 Feb 2010 11:14:54 +0000
Subject: [issue7890] equal unicode/str objects can have unequal hash
In-Reply-To: <1265711894.31.0.637310808217.issue7890@psf.upfronthosting.co.za>
Message-ID: <4B7143A9.7080207@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

lplatypus wrote:
> 
> lplatypus <luke at deller.id.au> added the comment:
> 
> Okay thanks, but in that case might I suggest that this limitation be mentioned in the documentation for sys.setdefaultencoding?  It currently reads as if any available encoding is acceptable. Perhaps even a warning or exception should be produced when calling it wrongly?
> 
> Other places that may need review include:
> - the programming FAQ on python.org which presents the option of calling setdefaultencoding('mbcs') on windows ( http://www.python.org/doc/faq/programming/#what-does-unicodeerror-ascii-decoding-encoding-error-ordinal-not-in-range-128-mean )
> - the comments in site.py which provoke changing the default encoding
> - PEP100 which suggests enabling this code in site.py
> 
> BTW would patches ever be considered to fix issues such as this with using other encodings as default encodings, or is there some objection to the concept?

No, Python 2.x's Unicode implementation only supports ASCII as default
encoding. In Python 3.x, UTF-8 is used as default encoding.

Note that this limitation only affects cases where you mix string
and Unicode objects used as keys in a dictionary. If you avoid
this situation, there are no dictionary problems with using
different default encoding. However, you may run into other problems.

----------
nosy: +lemburg

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

From report at bugs.python.org  Tue Feb  9 12:16:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Feb 2010 11:16:42 +0000
Subject: [issue7889] random produces different output on different
	architectures
In-Reply-To: <1265674553.33.0.380899973746.issue7889@psf.upfronthosting.co.za>
Message-ID: <1265714202.05.0.211968488701.issue7889@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It's not only getrandbits():

** x86 **
>>> random.seed(b'foo')
>>> random.random()
0.95824312997798622

** x86_64 **
>>> random.seed(b'foo')
>>> random.random()
0.88694660946819537

----------
nosy: +pitrou

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

From report at bugs.python.org  Tue Feb  9 12:18:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Feb 2010 11:18:47 +0000
Subject: [issue7889] random produces different output on different
	architectures
In-Reply-To: <1265674553.33.0.380899973746.issue7889@psf.upfronthosting.co.za>
Message-ID: <1265714327.55.0.488022340317.issue7889@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It works when seeding from a single integer, though:
>>> import random
>>> random.seed(123)
>>> random.random()
0.052363598850944326

So I guess it's the seeding-from-an-array which is buggy.

----------

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

From report at bugs.python.org  Tue Feb  9 12:25:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Feb 2010 11:25:25 +0000
Subject: [issue7889] random produces different output on different
	architectures
In-Reply-To: <1265674553.33.0.380899973746.issue7889@psf.upfronthosting.co.za>
Message-ID: <1265714725.48.0.631646722813.issue7889@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, it's simple really. When seeding from something else than an integer, seed() takes the hash of the object (instead of considering all its bytes, which might be considered a weakness since you lose entropy -- also, Python hash() is not supposed to be cryptographically strong). The hash is different in 32-bit and 64-bit mode (although the lower 32 bits are the same, at least for a bytes object), and since all the bits are taken into account the initial state is different.

So the easy workaround for the OP is to seed with an integer rather a bytes object.

----------

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

From report at bugs.python.org  Tue Feb  9 12:27:23 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 09 Feb 2010 11:27:23 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1265714843.27.0.31376869447.issue7582@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Finally! (I really hope so)

----------
Added file: http://bugs.python.org/file16184/diff.py_iso_timestamps_true_with_true_dst.diff

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

From report at bugs.python.org  Tue Feb  9 12:31:55 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 09 Feb 2010 11:31:55 +0000
Subject: [issue7889] random produces different output on different
	architectures
In-Reply-To: <1265674553.33.0.380899973746.issue7889@psf.upfronthosting.co.za>
Message-ID: <1265715115.48.0.991021092199.issue7889@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

If we aren't going to fix it, should we document the limitation?

----------
nosy: +michael.foord

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

From report at bugs.python.org  Tue Feb  9 12:43:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Feb 2010 11:43:50 +0000
Subject: [issue7889] random produces different output on different
	architectures
In-Reply-To: <1265674553.33.0.380899973746.issue7889@psf.upfronthosting.co.za>
Message-ID: <1265715830.92.0.470878100189.issue7889@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, ideally we should drop the automatic hash() and only accept:
1) ints/longs
2) buffer-like objects

(and tell people to hash() explicitly if they want to)

If that's too disruptive, we should document it.
And, for 3.x, provide the following recipe to hash from a bytes object without losing entropy, and keeping the same results under 32-bit and 64-bit builds:

>>> import random
>>> random.seed(int.from_bytes(b'foo', 'little'))
>>> random.random()
0.08384169414918807

----------
versions: +Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Feb  9 13:02:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 09 Feb 2010 12:02:35 +0000
Subject: [issue7889] random produces different output on different
	architectures
In-Reply-To: <1265674553.33.0.380899973746.issue7889@psf.upfronthosting.co.za>
Message-ID: <1265716955.76.0.999991700093.issue7889@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Antoine]
> >>> random.seed(int.from_bytes(b'foo', 'little'))

+1 for either documenting this useful trick, or modifying init_by_array to do this automatically for buffer-like objects.

Disallowing other types of input for the seed sounds dangerous, though.

----------

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

From report at bugs.python.org  Tue Feb  9 13:05:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Feb 2010 12:05:49 +0000
Subject: [issue7880] sysconfig does not like symlinks
In-Reply-To: <1265584932.48.0.89611557521.issue7880@psf.upfronthosting.co.za>
Message-ID: <1265717149.51.0.450759980877.issue7880@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why would sys.executable be a directory?

----------
nosy: +pitrou

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

From report at bugs.python.org  Tue Feb  9 13:15:05 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 09 Feb 2010 12:15:05 +0000
Subject: [issue7880] sysconfig does not like symlinks
In-Reply-To: <1265584932.48.0.89611557521.issue7880@psf.upfronthosting.co.za>
Message-ID: <1265717705.05.0.818587584662.issue7880@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Antoine, see http://bugs.python.org/issue7774

----------

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

From report at bugs.python.org  Tue Feb  9 13:19:26 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 12:19:26 +0000
Subject: [issue7880] sysconfig does not like symlinks
In-Reply-To: <1265584932.48.0.89611557521.issue7880@psf.upfronthosting.co.za>
Message-ID: <1265717966.97.0.854240148444.issue7880@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Yes, it is the issue #7774.

The patch proposed on msg98284 should fix sys.executable being a directory.

Tarek, if you implement the patch for sysconfig, add a note regarding the dir hack:
  # XXX : see issue 7774

----------

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

From report at bugs.python.org  Tue Feb  9 13:31:52 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 12:31:52 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1265718712.42.0.757410670202.issue7774@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
components: +Interpreter Core -Library (Lib)
stage: test needed -> needs patch

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

From report at bugs.python.org  Tue Feb  9 14:26:51 2010
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 09 Feb 2010 13:26:51 +0000
Subject: [issue4037] doctest.py should include method descriptors when looking
	inside a class __dict__
In-Reply-To: <1223079206.04.0.17382541424.issue4037@psf.upfronthosting.co.za>
Message-ID: <1265722011.42.0.272833958261.issue4037@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Attached is a simple test script for the patch I submitted. I have tested it with Python 2.6 both before and after applying the patch. Run it from the command line.

With the unpatched doctest module, it prints:

"Expected 2 doctests, but only found 1"

After the patch, it finds and runs both doctests, and prints nothing.

----------
Added file: http://bugs.python.org/file16185/doctest_test.py

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

From report at bugs.python.org  Tue Feb  9 14:28:21 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 09 Feb 2010 13:28:21 +0000
Subject: [issue7808] test_bsddb3 leaks references
In-Reply-To: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>
Message-ID: <1265722101.79.0.0331902069548.issue7808@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Tue Feb  9 15:08:17 2010
From: report at bugs.python.org (Jordan Apgar)
Date: Tue, 09 Feb 2010 14:08:17 +0000
Subject: [issue7887] errno 107 socket.recv issure
In-Reply-To: <1265672817.82.0.408353055509.issue7887@psf.upfronthosting.co.za>
Message-ID: <1265724497.48.0.772969947943.issue7887@psf.upfronthosting.co.za>


Jordan Apgar <twistedphrame at gmail.com> added the comment:

Sorry I was under the impression this was an issue with the socket module

----------

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

From report at bugs.python.org  Tue Feb  9 15:23:51 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 14:23:51 +0000
Subject: [issue3562] Intermitent failure in
	test_multiprocessing.test_number_of_objects
In-Reply-To: <1218834536.55.0.521559442827.issue3562@psf.upfronthosting.co.za>
Message-ID: <1265725431.63.0.801306539984.issue3562@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Duplicate of #5009. Applied in r68839.

----------
nosy: +flox
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> multiprocessing: failure in manager._debug_info()

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

From report at bugs.python.org  Tue Feb  9 15:27:55 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 14:27:55 +0000
Subject: [issue7808] test_bsddb3 leaks references
In-Reply-To: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>
Message-ID: <1265725675.58.0.572400732294.issue7808@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
nosy: +pitrou

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

From report at bugs.python.org  Tue Feb  9 15:33:18 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 14:33:18 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1265725998.03.0.000143218649722.issue6615@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

It should be closed now.

----------
priority:  -> normal
stage:  -> committed/rejected
status: open -> pending

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

From report at bugs.python.org  Tue Feb  9 15:33:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 14:33:47 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1265726027.89.0.718657114255.issue6615@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
status: pending -> open
versions:  -Python 2.6, Python 3.1

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

From report at bugs.python.org  Tue Feb  9 15:34:28 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 14:34:28 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1265726068.38.0.41466016166.issue6615@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
status: open -> pending

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

From report at bugs.python.org  Tue Feb  9 15:36:18 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 14:36:18 +0000
Subject: [issue5596] memory leaks in py3k
In-Reply-To: <1238336388.84.0.581148968517.issue5596@psf.upfronthosting.co.za>
Message-ID: <1265726178.07.0.652610914772.issue5596@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
status: open -> closed

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

From report at bugs.python.org  Tue Feb  9 15:36:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 14:36:47 +0000
Subject: [issue7808] test_bsddb3 leaks references
In-Reply-To: <1264790727.06.0.606025946843.issue7808@psf.upfronthosting.co.za>
Message-ID: <1265726207.12.0.813076274662.issue7808@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
type: performance -> resource usage

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

From report at bugs.python.org  Tue Feb  9 15:47:20 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 09 Feb 2010 14:47:20 +0000
Subject: [issue6615] multiprocessing logging support test
In-Reply-To: <1249142946.71.0.252587161842.issue6615@psf.upfronthosting.co.za>
Message-ID: <1265726840.05.0.777400812617.issue6615@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution: accepted -> fixed
status: pending -> closed

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

From report at bugs.python.org  Tue Feb  9 15:56:36 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 09 Feb 2010 14:56:36 +0000
Subject: [issue7662] time.utcoffset()
In-Reply-To: <1263057341.16.0.947515103763.issue7662@psf.upfronthosting.co.za>
Message-ID: <1265727396.57.0.430573262472.issue7662@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Updated Python code according to discussion from aforementioned issue #7582. Unfortunately, I can't find Python source for `time` module to make a proper patch out of it.

def time.utcoffset():
  """Return current UTC offset in seconds"""
  isdst = time.localtime().tm_isdst
  if (time.daylight and isdst):
    return -time.altzone
  else:
    return -time.timezone

----------

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

From report at bugs.python.org  Tue Feb  9 16:48:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Feb 2010 15:48:17 +0000
Subject: [issue7662] time.utcoffset()
In-Reply-To: <1263057341.16.0.947515103763.issue7662@psf.upfronthosting.co.za>
Message-ID: <1265730497.67.0.537541042092.issue7662@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The `time` module is written in C, in Modules/timemodule.c.
If this is too bothersome to write in C, the function could perhaps be added to the datetime module instead.
In any case, we need a proper patch, including unit tests if possible.

(and I agree that anything making the time stuff easier to use is welcome)

----------
nosy: +brett.cannon, pitrou

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

From report at bugs.python.org  Tue Feb  9 17:08:56 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Feb 2010 16:08:56 +0000
Subject: [issue7216] low performance of zipfile readline()
In-Reply-To: <1256627631.57.0.724869251337.issue7216@psf.upfronthosting.co.za>
Message-ID: <1265731736.49.0.514193296612.issue7216@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Already fixed with issue7610.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed
superseder:  -> Cannot use both read and readline method in same ZipExtFile object

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

From report at bugs.python.org  Tue Feb  9 17:28:37 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 16:28:37 +0000
Subject: [issue7229] [PATCH] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1265732917.68.0.930505840726.issue7229@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I don't think altzone was incorrect, but it could also use a little rewording. Attached is a patch which rewords daylight and altzone. Thoughts?

----------
keywords: +needs review
priority:  -> normal
stage:  -> patch review
versions:  -Python 2.4, Python 2.5, Python 3.0
Added file: http://bugs.python.org/file16186/time_reword.diff

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

From report at bugs.python.org  Tue Feb  9 17:33:31 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 16:33:31 +0000
Subject: [issue3771] test_httpservers intermittent failure
In-Reply-To: <1220489239.6.0.433848845577.issue3771@psf.upfronthosting.co.za>
Message-ID: <1265733211.1.0.131457625723.issue3771@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
type: crash -> behavior

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

From report at bugs.python.org  Tue Feb  9 17:34:47 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 16:34:47 +0000
Subject: [issue4713] Installing sgmlop can crash xmlrpclib
In-Reply-To: <1229895007.0.0.481278630748.issue4713@psf.upfronthosting.co.za>
Message-ID: <1265733287.92.0.368152548195.issue4713@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
type: crash -> behavior

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

From report at bugs.python.org  Tue Feb  9 17:39:25 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 16:39:25 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1265733565.69.0.982029953137.issue1533@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
type: crash -> behavior
versions: +Python 3.1, Python 3.2 -Python 3.0

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

From report at bugs.python.org  Tue Feb  9 17:40:10 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 09 Feb 2010 16:40:10 +0000
Subject: [issue7889] random produces different output on different
	architectures
In-Reply-To: <1265674553.33.0.380899973746.issue7889@psf.upfronthosting.co.za>
Message-ID: <1265733610.88.0.971955438701.issue7889@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I will update the documentation.

----------
components: +Documentation -Library (Lib)
versions:  -Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Feb  9 17:40:20 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 16:40:20 +0000
Subject: [issue4891] formatwarning function signature change breaks code
In-Reply-To: <1231499341.14.0.968854878286.issue4891@psf.upfronthosting.co.za>
Message-ID: <1265733620.99.0.890078543133.issue4891@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> test needed
type: crash -> behavior

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

From report at bugs.python.org  Tue Feb  9 17:43:07 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 16:43:07 +0000
Subject: [issue6815] UnicodeDecodeError in os.path.expandvars
In-Reply-To: <1251791477.43.0.253856390345.issue6815@psf.upfronthosting.co.za>
Message-ID: <1265733787.55.0.0130435358621.issue6815@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> test needed
type: crash -> behavior

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

From report at bugs.python.org  Tue Feb  9 17:43:57 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 16:43:57 +0000
Subject: [issue5223] infinite recursion in PyErr_WriteUnraisable
In-Reply-To: <1234412915.77.0.527314714811.issue5223@psf.upfronthosting.co.za>
Message-ID: <1265733837.92.0.492625522626.issue5223@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> patch review

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

From report at bugs.python.org  Tue Feb  9 17:45:56 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 16:45:56 +0000
Subject: [issue5527] multiprocessing won't work with Tkinter (under Linux)
In-Reply-To: <1237574081.02.0.0677822756927.issue5527@psf.upfronthosting.co.za>
Message-ID: <1265733956.63.0.966431873249.issue5527@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> needs patch
type: crash -> behavior

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

From report at bugs.python.org  Tue Feb  9 17:47:09 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 16:47:09 +0000
Subject: [issue4918] Windows installer created with Python 2.5 does not work
	with Python 2.6.1
In-Reply-To: <1231738106.14.0.212121765754.issue4918@psf.upfronthosting.co.za>
Message-ID: <1265734029.77.0.95547044888.issue4918@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
type: crash -> behavior

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

From report at bugs.python.org  Tue Feb  9 17:49:21 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 16:49:21 +0000
Subject: [issue6270] Menu deletecommand fails if command is already deleted
In-Reply-To: <1244754580.13.0.801057820447.issue6270@psf.upfronthosting.co.za>
Message-ID: <1265734161.77.0.537471324305.issue6270@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> patch review
type: crash -> behavior
versions: +Python 3.2 -Python 2.5, Python 3.0

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

From report at bugs.python.org  Tue Feb  9 17:49:49 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 16:49:49 +0000
Subject: [issue6470] Tkinter import fails when running Python.exe from a
	network share
In-Reply-To: <1247430164.29.0.0724763544583.issue6470@psf.upfronthosting.co.za>
Message-ID: <1265734189.25.0.57057764221.issue6470@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
type: crash -> behavior

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

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: [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 17:53:21 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 16:53:21 +0000
Subject: [issue6476] MSVCRT's spawnve/spawnvpe are not thread safe
In-Reply-To: <1247505068.9.0.23655949974.issue6476@psf.upfronthosting.co.za>
Message-ID: <1265734401.2.0.420309883145.issue6476@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
type: crash -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.4, Python 2.5

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

From report at bugs.python.org  Tue Feb  9 17:54:14 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 16:54:14 +0000
Subject: [issue6668] locale.py: can't parse sr_RS@latin locale
In-Reply-To: <1249655674.35.0.635015975428.issue6668@psf.upfronthosting.co.za>
Message-ID: <1265734454.0.0.280140147425.issue6668@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
type: crash -> behavior

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

From report at bugs.python.org  Tue Feb  9 17:55:32 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 16:55:32 +0000
Subject: [issue6863] Wrong linker command if CXX set to "ccache g++"
In-Reply-To: <1252415139.67.0.192610915526.issue6863@psf.upfronthosting.co.za>
Message-ID: <1265734532.98.0.718129111575.issue6863@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
type: crash -> behavior

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

From report at bugs.python.org  Tue Feb  9 17:56:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Feb 2010 16:56:27 +0000
Subject: [issue6233] ElementTree (py3k) doesn't properly encode characters
	that can't be represented in the specified encoding
In-Reply-To: <1244410260.68.0.534028988218.issue6233@psf.upfronthosting.co.za>
Message-ID: <1265734587.4.0.594706011072.issue6233@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r78123 (py3k) and r78124 (3.1). I've also removed _escape_cdata() since it wasn't used anymore. Thanks Jerry for the patch.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Feb  9 18:01:05 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 17:01:05 +0000
Subject: [issue5504] ctypes should work with systems where mmap can't
	be	PROT_WRITE and PROT_EXEC
In-Reply-To: <1237348531.28.0.513167073983.issue5504@psf.upfronthosting.co.za>
Message-ID: <1265734865.44.0.72264486487.issue5504@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
priority:  -> normal
stage:  -> patch review
type: crash -> behavior

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

From report at bugs.python.org  Tue Feb  9 18:03:56 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 17:03:56 +0000
Subject: [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: <1265735036.61.0.473026597697.issue7892@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The 3.x merge.

----------
Added file: http://bugs.python.org/file16188/patch_dict_assertRaises_py3k.diff

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

From report at bugs.python.org  Tue Feb  9 18:05:26 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 17:05:26 +0000
Subject: [issue7505] ctypes not converting None to Null in 64-bit system
In-Reply-To: <1260810641.87.0.854694050504.issue7505@psf.upfronthosting.co.za>
Message-ID: <1265735126.05.0.0948162866201.issue7505@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

What is the output of your example? I'm not on Linux at the moment, but I'm trying to see if this is actually a crash.

----------
nosy: +brian.curtin
priority:  -> normal
stage:  -> test needed
versions:  -Python 2.5

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

From report at bugs.python.org  Tue Feb  9 18:06:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Feb 2010 17:06:03 +0000
Subject: [issue5223] infinite recursion in PyErr_WriteUnraisable
In-Reply-To: <1265733838.0.0.800938522202.issue5223@psf.upfronthosting.co.za>
Message-ID: <1265735248.3346.2.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

As already mentioned, the backport patch isn't up to date.

----------

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

From report at bugs.python.org  Tue Feb  9 18:06:13 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 17:06:13 +0000
Subject: [issue6895] locale._parse_localename fails when localename does not
	contain encoding information
In-Reply-To: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za>
Message-ID: <1265735173.56.0.422167807432.issue6895@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
type: crash -> behavior

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

From report at bugs.python.org  Tue Feb  9 18:07:14 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 17:07:14 +0000
Subject: [issue7424] segmentation fault in listextend during install
In-Reply-To: <1259729838.45.0.563962594728.issue7424@psf.upfronthosting.co.za>
Message-ID: <1265735234.72.0.448954212596.issue7424@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
priority:  -> normal
stage:  -> test needed

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

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: [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 18:26:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Feb 2010 17:26:53 +0000
Subject: [issue2746] ElementTree ProcessingInstruction uses character entities
	in content
In-Reply-To: <1209827546.16.0.534568490293.issue2746@psf.upfronthosting.co.za>
Message-ID: <1265736413.9.0.201674936502.issue2746@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed the patch in r78125 (trunk) and r78126 (py3k). I'm not sure I want to backport it to 2.6/3.1, since it might bite people who relied on the old behaviour.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> pending
versions:  -Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Feb  9 18:29:18 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 17:29:18 +0000
Subject: [issue4713] Installing sgmlop causes xmlrpclib error
In-Reply-To: <1229895007.0.0.481278630748.issue4713@psf.upfronthosting.co.za>
Message-ID: <1265736558.53.0.495129014954.issue4713@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The patch could use a test (which doesn't require sgmlop).

----------
keywords: +needs review
nosy: +brian.curtin
priority:  -> normal
stage:  -> test needed
title: Installing sgmlop can crash xmlrpclib -> Installing sgmlop causes xmlrpclib error

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

From report at bugs.python.org  Tue Feb  9 18:38:04 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Tue, 09 Feb 2010 17:38:04 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1265737084.71.0.952600205268.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

I'd like to add another issue I encountered with the latest version of regex - issue2636-20100204.zip

It seems, that there is an error in handling some quantifiers in python 2.5

on
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] on win32

I get e.g.:

>>> regex.findall(ur"q*", u"qqwe")

Traceback (most recent call last):
  File "<pyshell#35>", line 1, in <module>
    regex.findall(ur"q*", u"qqwe")
  File "C:\Python25\lib\regex.py", line 213, in findall
    return _compile(pattern, flags).findall(string, overlapped=overlapped)
  File "C:\Python25\lib\regex.py", line 633, in _compile
    p = _regex.compile(pattern, info.global_flags | info.local_flags, code, info.group_index, index_group)
RuntimeError: invalid RE code

There is the same error for other possibly "infinite" quantifiers like "q+", "q{0,}" etc. with their non-greedy and possesive variants.

On python 2.6 and 3.1 all these patterns works without errors.

vbr

----------

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

From report at bugs.python.org  Tue Feb  9 18:44:36 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 17:44:36 +0000
Subject: [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: <1265737476.04.0.500878693798.issue7892@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16188/patch_dict_assertRaises_py3k.diff

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

From report at bugs.python.org  Tue Feb  9 18:44:38 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 17:44:38 +0000
Subject: [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: <1265737478.66.0.65553418983.issue7892@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed 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:45:12 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 17:45:12 +0000
Subject: [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: <1265737512.74.0.585351582613.issue7892@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file16189/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:45:59 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Feb 2010 17:45:59 +0000
Subject: [issue7893] unittest: have to subclass TextTestRunner to use
	alternative TestResult
In-Reply-To: <1265735504.12.0.0790484553518.issue7893@psf.upfronthosting.co.za>
Message-ID: <1265737559.94.0.091193153614.issue7893@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin

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

From report at bugs.python.org  Tue Feb  9 18:46:40 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 17:46:40 +0000
Subject: [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: <1265737600.83.0.720889833946.issue7892@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

I missed an "assertEqual(hasattr(...), False)". Fixed.

----------
Added file: http://bugs.python.org/file16190/patch_dict_assertRaises_py3k.diff

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

From report at bugs.python.org  Tue Feb  9 18:53:40 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 09 Feb 2010 17:53:40 +0000
Subject: [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: <1265738020.11.0.513774986973.issue7892@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Tue Feb  9 19:04:05 2010
From: report at bugs.python.org (Venkateswaran)
Date: Tue, 09 Feb 2010 18:04:05 +0000
Subject: [issue7505] ctypes not converting None to Null in 64-bit system
In-Reply-To: <1260810641.87.0.854694050504.issue7505@psf.upfronthosting.co.za>
Message-ID: <1265738645.18.0.356826388771.issue7505@psf.upfronthosting.co.za>


Venkateswaran <wenkat.s at gmail.com> added the comment:

The output was a valid pointer which was not null. I did not investigate further on this issue, because I had a work around i.e I used ctypes.POINTER(ctypes.c_cint)() instead of None.

----------

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

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: [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: [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  Tue Feb  9 21:41:06 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 20:41:06 +0000
Subject: [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: <1265748066.99.0.307087807163.issue7895@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
priority:  -> normal
title: Mac 10.6 mac_ver() crashes with USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER -> Mac 10.6 mac_ver() crashes with USING_FORK_WITHOUT_EXEC_IS _NOT_SUPPORTED_BY_FILE_MANAGER

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

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


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
title: [patch] refactor "test_dict.py" using new assertRaises context manager. -> refactor "test_dict.py" using new assertRaises context manager.

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

From report at bugs.python.org  Tue Feb  9 23:22:10 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 22:22:10 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1265754130.9.0.0235684756508.issue6472@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15468/issue6472_upstream.diff

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

From report at bugs.python.org  Tue Feb  9 23:22:16 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 22:22:16 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1265754136.37.0.209208003015.issue6472@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file15552/issue6472_upstream_py3k_v2.diff

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

From report at bugs.python.org  Tue Feb  9 23:28:23 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 22:28:23 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1265754503.43.0.0306654545289.issue6472@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch updated, with upstream packages:
 * ElementTree 1.3a3-20070912
 * cElementTree 1.0.6-20090110

Now all tests are identical for the ElementTree part:
 - ElementTree 2.x
 - cElementTree 2.x
 - ElementTree 3.x
 - cElementTree 3.x

Waiting for some developer kind enough to review and merge in 2.7 and 3.2.

----------
Added file: http://bugs.python.org/file16191/issue6472_etree_upstream_v2.diff

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

From report at bugs.python.org  Tue Feb  9 23:29:17 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 22:29:17 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1265754557.81.0.902949704495.issue6472@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file16192/issue6472_etree_upstream_py3k_v2.diff

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

From report at bugs.python.org  Tue Feb  9 23:33:53 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 09 Feb 2010 22:33:53 +0000
Subject: [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: <1265754833.19.0.701821239339.issue7895@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
versions: +Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Feb 10 00:22:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Feb 2010 23:22:22 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1265757742.18.0.122228556892.issue6472@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Given the size of the patch, it's very difficult to review properly.
In any case, could you upload it to http://codereview.appspot.com/ ?

----------

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

From report at bugs.python.org  Wed Feb 10 00:31:54 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 23:31:54 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1265758314.49.0.500108166229.issue6472@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Ok, will do the upload to rietveld.

In addition to the straight review of the patch itself, you could:
 - diff against the upstream source code (very few changes)
 - diff between 2.x and 3.x
 - review the test_suite (there's only additions, no real change)
 - hunt refleaks

Btw, I've backported the last tests (#2746, #6233) to all 4 test files (ET and cET, 2.x and 3.x).

----------

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

From report at bugs.python.org  Wed Feb 10 00:51:21 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 09 Feb 2010 23:51:21 +0000
Subject: [issue6472] Inconsistent use of "iterator" in ElementTree doc & diff
	between Py and C modules
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1265759481.3.0.922977184437.issue6472@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Here it is:
 * http://codereview.appspot.com/207048/show

----------

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

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: [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 00:54:37 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 09 Feb 2010 23:54:37 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1265759677.84.0.617521175449.issue1578269@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This new patch (23) renames support.has_symlink and support.skip_unless_has_symlink to "can_symlink". This more accurately reflects the functionality.

----------
title: Add os.link() and os.symlink() and os.path.islink()	support for Windows -> Add os.link() and os.symlink() and os.path.islink() support for Windows
Added file: http://bugs.python.org/file16193/windows symlink draft 23.patch

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

From report at bugs.python.org  Wed Feb 10 01:03:42 2010
From: report at bugs.python.org (John-Michael Glenn)
Date: Wed, 10 Feb 2010 00:03:42 +0000
Subject: [issue3646] MacOS X framework install to non-standard directory fails
In-Reply-To: <1219392826.4.0.166247537114.issue3646@psf.upfronthosting.co.za>
Message-ID: <1265760222.29.0.230346315681.issue3646@psf.upfronthosting.co.za>


John-Michael Glenn <j-m15 at hotmail.com> added the comment:

I'm using Python 2.6.4 on OSX 10.6 and I first used the mv command to rename the original python.framework. Then I was able to install 2.6 as the new python.framework. These are the commands:

rename it:
sudo mv /Library/Frameworks/Python.framework /Library/Frameworks/Python_old.framework

install new python:
./configure --enable-framework --with-framework-name=Python --enable-universalsdk=/ --with-universal-archs=intel

----------
nosy: +phyreman

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

From report at bugs.python.org  Wed Feb 10 01:39:47 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 10 Feb 2010 00:39:47 +0000
Subject: [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: <1265762387.32.0.83216641539.issue7896@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
assignee:  -> ronaldoussoren
components: +Macintosh
nosy: +ronaldoussoren

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

From report at bugs.python.org  Wed Feb 10 01:53:58 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 10 Feb 2010 00:53:58 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265763238.31.0.277839582404.issue7712@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

With Ezio's latest patch (sent via IRC), test_bufio still fails and additionally test_mailbox fails.

If I apply the patch on #7443 along with Ezio's patch, everything looks fine. I haven't thoroughly looked at that issue, but on the surface it looks similar (same setup, same result).

----------

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

From report at bugs.python.org  Wed Feb 10 02:31:48 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 10 Feb 2010 01:31:48 +0000
Subject: [issue4037] doctest.py should include method descriptors when looking
	inside a class __dict__
In-Reply-To: <1223079206.04.0.17382541424.issue4037@psf.upfronthosting.co.za>
Message-ID: <1265765508.56.0.240892388498.issue4037@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Can you add your test(s) in Lib/test/test_doctest.py ? That way it will be run with the Python regression suite. Ideally a documentation update would come with the patch. Also, line length should ideally be capped at 79 characters (re: PEP-8).

Might as well move the valname string building outside of both if-tests since it's common to both of them.


Terry: this looks like a feature rather than a bug, removing 2.6/3.1.

----------
keywords: +needs review, patch
nosy: +brian.curtin
priority:  -> normal
stage:  -> patch review
type:  -> feature request
versions:  -Python 2.6, Python 3.1

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

From report at bugs.python.org  Wed Feb 10 03:11:28 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 10 Feb 2010 02:11:28 +0000
Subject: [issue7418] hashlib : the names of the different hash algorithms
In-Reply-To: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>
Message-ID: <1265767888.68.0.634596124523.issue7418@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'll be taking a look at this patch during the sprints at Pycon.  Will get back to you soonish :-)

----------

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

From report at bugs.python.org  Wed Feb 10 03:20:08 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 10 Feb 2010 02:20:08 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1265768408.99.0.183248713677.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20100210.zip is a new version of the regex module.

The reported bugs appear to be fixed now.

----------
Added file: http://bugs.python.org/file16195/issue2636-20100210.zip

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

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: [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 04:00:15 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 10 Feb 2010 03:00:15 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1265770815.83.0.117778809991.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file15932/failures.txt

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

From report at bugs.python.org  Wed Feb 10 04:00:24 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 10 Feb 2010 03:00:24 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1265770824.81.0.368518415835.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file16180/windows symlink draft 22.patch

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

From report at bugs.python.org  Wed Feb 10 04:00:31 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 10 Feb 2010 03:00:31 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1265770831.03.0.311456720019.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file16193/windows symlink draft 23.patch

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

From report at bugs.python.org  Wed Feb 10 04:00:37 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 10 Feb 2010 03:00:37 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1265770837.49.0.989363030193.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file16194/windows symlink draft 24.patch

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

From report at bugs.python.org  Wed Feb 10 04:00:44 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 10 Feb 2010 03:00:44 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1265770844.21.0.885405726569.issue1578269@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file16197/smime.p7s

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

From report at bugs.python.org  Wed Feb 10 04:22:50 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 10 Feb 2010 03:22:50 +0000
Subject: [issue1160] Medium size regexp crashes python
In-Reply-To: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za>
Message-ID: <1265772170.62.0.16136308443.issue1160@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

As stated in msg73781, this is being addressed in issue #2636.

My regex module handles the test case without complaint:

>>> import regex
>>> r = regex.compile('|'.join('%d'%x for x in range(7000)))
>>> r.match("1000")
<_regex.REGEX_Match object at 0x015D2920>
>>> r.match("6999")
<_regex.REGEX_Match object at 0x016DDC20>

----------
nosy: +mrabarnett

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

From report at bugs.python.org  Wed Feb 10 04:43:31 2010
From: report at bugs.python.org (David Fischer)
Date: Wed, 10 Feb 2010 03:43:31 +0000
Subject: [issue3819] urllib2 sends Basic auth across redirects
In-Reply-To: <1220973164.56.0.503421072226.issue3819@psf.upfronthosting.co.za>
Message-ID: <1265773411.99.0.865394819549.issue3819@psf.upfronthosting.co.za>


David Fischer <dfischer at ucsdmail.com> added the comment:

I believe this bug affects urllib2 when it talks to the corporate single-sign-on solution Siteminder. Siteminder usually is installed as a web server module. When a request is made to the server (origin server), Siteminder issues a 302 redirect to a central authentication server running SSL passing the original request URL of the origin server. The central server responds with a 401 basic authentication challenge. Urllib2 responds with the password from the HTTPPasswordMgr. The central server sets some cookies and responds with a 302 redirect to the origin server on the original URL. Urllib2 then sends the authentication and cookies to the origin server which is virtually always unprotected. Browsers do not send the authentication to the origin server -- only the cookies.

----------
nosy: +dfischer
Added file: http://bugs.python.org/file16198/siteminder_3819.py

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

From report at bugs.python.org  Wed Feb 10 04:54:53 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 10 Feb 2010 03:54:53 +0000
Subject: [issue3819] urllib2 sends Basic auth across redirects
In-Reply-To: <1220973164.56.0.503421072226.issue3819@psf.upfronthosting.co.za>
Message-ID: <1265774093.84.0.293989620674.issue3819@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Ok, in order to fix this bug, urllib2 should only send the cookies and not send the auth info across the the redirects. Yup, let me take this up.

----------
assignee:  -> orsenthil
resolution:  -> accepted

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

From report at bugs.python.org  Wed Feb 10 05:20:41 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 10 Feb 2010 04:20:41 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1265775641.62.0.698581723432.issue1578269@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

With patch #25, I get 6 test failures: test_glob, test_os, test_platform, test_posixpath, test_shutil, and test_tarfile. 

This is interesting because the failures are different depending on how I compile Python. Running in WOW64 (32-bit Python on 64-bit Windows), the tests fail for not having the required privilege. Running a 64-bit Python, the tests fail various asserts (see attached patch25results_python64.txt).

I haven't looked into why the behavior is different in WOW64 mode, but I'll try to take a look in the next day or so.

----------
Added file: http://bugs.python.org/file16199/patch25results_python64.txt

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

From report at bugs.python.org  Wed Feb 10 06:21:27 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 10 Feb 2010 05:21:27 +0000
Subject: [issue7418] hashlib : the names of the different hash algorithms
In-Reply-To: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>
Message-ID: <1265779287.24.0.49237382498.issue7418@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'll be taking a look at this patch during the sprints at Pycon.  Will get back to you soonish :-)

----------

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

From report at bugs.python.org  Wed Feb 10 08:06:53 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 10 Feb 2010 07:06:53 +0000
Subject: [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: <1265785613.7.0.883978413357.issue7896@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Do you use your an installer from python.org or your own build? The crashlog seems to indicate the latter (because of the Code Type).

Which version of Tk are you using? Which OS release?

I know there are issues with the system Tk 8.5 on OSX 10.6, although this is a new type of problem and and probably unrelated to the other ones.

Something what might give us further information: start IDLE by running "/Applications/Python 2.6/IDLE.app/Contents/MacOS/IDLE" from a terminal window (including the quotes). That will show any output from the IDLE process in the terminal window, where it is easier to collect it than from the system log.   With some luck this will show that IDLE is doing something that it shouldn't.

----------

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

From report at bugs.python.org  Wed Feb 10 08:53:19 2010
From: report at bugs.python.org (Terrence Cole)
Date: Wed, 10 Feb 2010 07:53:19 +0000
Subject: [issue7889] random produces different output on different
	architectures
In-Reply-To: <1265674553.33.0.380899973746.issue7889@psf.upfronthosting.co.za>
Message-ID: <1265788399.85.0.0952737592611.issue7889@psf.upfronthosting.co.za>


Terrence Cole <terrence at zettabytestorage.com> added the comment:

Thank you for all the help!  I'm glad to see that the use of hash() on buffer compatible objects is an actual gotcha and not just me being obtuse.

Also, for those googling who, like me, won't be able to use 3.2's from_bytes until 3.2 is released in December, here is code to convert a bytes to an int:
>>> n = 0
>>> off = 0
>>> data = b'\xfc\x00'
>>> for c in data[::-1]:
...     n += c << off
...     off += 8
... 
>>> print(n)
64512

Or, if you prefer the functional style:
>>> sum([c<<off for c,off in zip(data[::-1],range(0,len(data)*8+1,8))])
64512

----------

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

From report at bugs.python.org  Wed Feb 10 09:05:14 2010
From: report at bugs.python.org (John-Michael Glenn)
Date: Wed, 10 Feb 2010 08:05:14 +0000
Subject: [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: <1265789114.08.0.296201208973.issue7896@psf.upfronthosting.co.za>


John-Michael Glenn <j-m15 at hotmail.com> added the comment:

I compiled it myself.

"I know there are issues with the system Tk 8.5 on OSX 10.6, although this is a new type of problem and and probably unrelated to the other ones."

...crap, I have 8.5 on 10.6.2

"...start IDLE by running "/Applications/Python 2.6/IDLE.app/Contents/MacOS/IDLE" from a terminal window (including the quotes). That will show any output from the IDLE process in the terminal window, where it is easier to collect it than from the system log.   With some luck this will show that IDLE is doing something that it shouldn't."

When I try to open a file it crashes and only spits out "Segmentation fault". When I try to test a module it just hangs and keeps me from doing anything at all but stare at my code. But it only does this once for each file that I try to test. So if I force quit it and open that same file again and test the module, it'll work just fine.

----------

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

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: [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 10:00:37 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 10 Feb 2010 09:00:37 +0000
Subject: [issue7863] platform module doesn't detect Windows 7
In-Reply-To: <1265421461.45.0.975266995718.issue7863@psf.upfronthosting.co.za>
Message-ID: <4B7275B1.9020003@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Brian Curtin wrote:
> 
> Brian Curtin <curtin at acm.org> added the comment:
> 
> Here's a patch which fixes this on trunk. 
> 
> 2.6/3.1 is a different story as there doesn't appear to be a way to get the platform type to differentiate workstation/server. #7766 is what makes it easy on trunk, but it's a new feature and isn't backported. Thoughts?

We can't backport #7766, so unless there's some win32 or OS env var trick
that we could apply, I'm not sure whether Windows 7 support can be
added to 2.6/3.1.

I don't have access to a Windows 7 installation, so can't really
test this on that version. Have you tested the patch on other
Windows versions ?

Esp. the csd change looks like it could break on older versions.

----------

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

From report at bugs.python.org  Wed Feb 10 10:28:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 10 Feb 2010 09:28:14 +0000
Subject: [issue7418] hashlib : the names of the different hash algorithms
In-Reply-To: <1259676268.37.0.504298003404.issue7418@psf.upfronthosting.co.za>
Message-ID: <1265794094.99.0.901929514495.issue7418@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +gps

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

From report at bugs.python.org  Wed Feb 10 11:29:22 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 10 Feb 2010 10:29:22 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1265797762.21.0.904988313581.issue7897@psf.upfronthosting.co.za>


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


----------
assignee:  -> michael.foord
nosy: +michael.foord

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

From report at bugs.python.org  Wed Feb 10 12:51:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 10 Feb 2010 11:51:20 +0000
Subject: [issue7898] rlcompleter add "real tab" when text is empty feature
In-Reply-To: <1265789959.13.0.400404108309.issue7898@psf.upfronthosting.co.za>
Message-ID: <1265802680.63.0.821094862209.issue7898@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

On the one hand, it makes sense for the common case of completing using the Tab key.
On the other hand, it will appear quite bizarre to people who have another, dedicated key for auto-completion.

By the way, rather than inserting a tab character, it should probably insert 4 spaces instead.

----------

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

From report at bugs.python.org  Wed Feb 10 13:03:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 10 Feb 2010 12:03:07 +0000
Subject: [issue7505] ctypes not converting None to Null in 64-bit system
In-Reply-To: <1260810641.87.0.854694050504.issue7505@psf.upfronthosting.co.za>
Message-ID: <1265803387.01.0.583371768735.issue7505@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It works in 64-bit mode under Mandriva Linux (gcc 4.4.1), with Python 2.6, 2.7 and 3.2.

$ python issue7505.py 
b = (nil)
a = 7, c = 7, d = 7, e = 7, f = 7, g = 7, h = 7, i = 7, j = 7, k = 7,  l = 7

I also works with a hand-compiled Python (2.6, 2.7, 3.2) under a 64-bit Ubuntu box. However, it fails with the system Python 2.5 shipped with Ubuntu. So perhaps this has to do with how Debian/Ubuntu compile their Pythons, or their libffi.

$ python issue7505.py 
b = 0x7f5300000000
a = 7, c = 7, d = 7, e = 7, f = 7, g = 7, h = 7, i = 7, j = 7, k = 7,  l = 7

----------
nosy: +pitrou

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

From report at bugs.python.org  Wed Feb 10 13:16:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 10 Feb 2010 12:16:40 +0000
Subject: [issue6472] Update ElementTree with upstream changes
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1265804200.3.0.347343139426.issue6472@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
title: Inconsistent use of "iterator" in ElementTree doc & diff between Py and C modules -> Update ElementTree with upstream changes

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

From report at bugs.python.org  Wed Feb 10 15:08:37 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Feb 2010 14:08:37 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1265810917.73.0.333782910126.issue7582@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This seems like a new feature to me so I'm removing 2.6 from the list.  My browser won't let me remove Python 3.1.

----------
nosy: +barry
versions:  -Python 2.6

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

From report at bugs.python.org  Wed Feb 10 15:58:30 2010
From: report at bugs.python.org (Prashanth noble)
Date: Wed, 10 Feb 2010 14:58:30 +0000
Subject: [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:00:48 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 10 Feb 2010 15:00:48 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1265814048.23.0.224564309732.issue7582@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
keywords: +needs review
type: behavior -> feature request
versions:  -Python 3.1

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

From report at bugs.python.org  Wed Feb 10 16:04:59 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 10 Feb 2010 15:04:59 +0000
Subject: [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:38:31 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 10 Feb 2010 15:38:31 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1265816311.45.0.698252362065.issue7582@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I use this tool in instructions how to generate patches on windows, so I am interested to see this fix in the version, that users will likely to use for next couple of years, but I'd be happy to see this committed in any branch.

If it is going to be committed in alpha only them I'd like to propose to change default diff format to unicode as well.

Please, also review http://bugs.python.org/issue7585 that contains more important API change that also prevents diff.py from generating correct patches.

----------

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

From report at bugs.python.org  Wed Feb 10 16:40:41 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 10 Feb 2010 15:40:41 +0000
Subject: [issue7585] [patch] difflib should separate filename from timestamp
	with tab
In-Reply-To: <1261947458.0.0.959368598145.issue7585@psf.upfronthosting.co.za>
Message-ID: <1265816441.28.0.0454979815839.issue7585@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

The reason is to provide a good usage example.

----------

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

From report at bugs.python.org  Wed Feb 10 16:54:44 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 10 Feb 2010 15:54:44 +0000
Subject: [issue7588] unittest.TestCase.shortDescription isn't short anymore
In-Reply-To: <1262010641.75.0.70494250568.issue7588@psf.upfronthosting.co.za>
Message-ID: <1265817284.36.0.670599940618.issue7588@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Fixed revision 78130.

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Feb 10 16:56:22 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 10 Feb 2010 15:56:22 +0000
Subject: [issue7893] unittest: have to subclass TextTestRunner to use
	alternative TestResult
In-Reply-To: <1265735504.12.0.0790484553518.issue7893@psf.upfronthosting.co.za>
Message-ID: <1265817382.49.0.254389098978.issue7893@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Fixed revision 78130.

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

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

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: [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 16:57:35 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 10 Feb 2010 15:57:35 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1265817455.3.0.669056151567.issue7582@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> I'd like to propose to change default diff format to unicode as well
What kind of "unicode" format is it?

----------

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

From report at bugs.python.org  Wed Feb 10 17:00:02 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 10 Feb 2010 16:00:02 +0000
Subject: [issue7901] Add Vista/7  symlink support
In-Reply-To: <1265817407.06.0.421431727357.issue7901@psf.upfronthosting.co.za>
Message-ID: <1265817602.08.0.816444742289.issue7901@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Duplicate of #1578269.

----------
nosy: +ezio.melotti
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Feb 10 17:00:20 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 10 Feb 2010 16:00:20 +0000
Subject: [issue7501] python -m unittest path_to_suite_function errors
In-Reply-To: <1260742792.63.0.561457576654.issue7501@psf.upfronthosting.co.za>
Message-ID: <1265817620.42.0.111093317269.issue7501@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Use load_tests instead.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Wed Feb 10 18:01:21 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 10 Feb 2010 17:01:21 +0000
Subject: [issue7863] platform module doesn't detect Windows 7
In-Reply-To: <1265412745.93.0.400074024271.issue7863@psf.upfronthosting.co.za>
Message-ID: <1265821281.17.0.716546674294.issue7863@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'll look into whatever other trickery could be applied to 2.6/3.1.

The patch against trunk works correctly for Win7, Win 2003 Server SP1, Win XP SP2, and Win 2000 Server SP2. platform.platform() outputs the same info for the latter three OSes whether or not the patch is applied. 

The csd change will work going back to Windows 2000. If we have to support anything prior, which I don't believe we do, then you are correct that it won't work. If that's an issue, I can revert that part of the change.

----------

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

From report at bugs.python.org  Wed Feb 10 18:58:27 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 10 Feb 2010 17:58:27 +0000
Subject: [issue6608] asctime causing python to crash
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1265824707.52.0.862388783548.issue6608@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

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

From report at bugs.python.org  Wed Feb 10 19:09:17 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 10 Feb 2010 18:09:17 +0000
Subject: [issue5492] Error on leaving IDLE with quit() or exit() under Linux
In-Reply-To: <1237121077.76.0.63532373748.issue5492@psf.upfronthosting.co.za>
Message-ID: <1265825357.26.0.0380932664955.issue5492@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

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

From report at bugs.python.org  Wed Feb 10 19:14:42 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 10 Feb 2010 18:14:42 +0000
Subject: [issue6393] OS X: python3 from python-3.1.dmg crashes at startup
In-Reply-To: <1246445517.38.0.373229118664.issue6393@psf.upfronthosting.co.za>
Message-ID: <1265825682.33.0.280724072366.issue6393@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +srid

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

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: [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 20:10:57 2010
From: report at bugs.python.org (ganges master)
Date: Wed, 10 Feb 2010 19:10:57 +0000
Subject: [issue7902] relative import broken
In-Reply-To: <1265828963.53.0.5315107426.issue7902@psf.upfronthosting.co.za>
Message-ID: <1265829057.11.0.542990404187.issue7902@psf.upfronthosting.co.za>


ganges master <gangesmaster at users.sourceforge.net> added the comment:

i believe brett is in charge of this, adding him to the noisy. sorry if it's not you :)

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Wed Feb 10 21:24:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 10 Feb 2010 20:24:56 +0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1265833496.83.0.135585156736.issue1533@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

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

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: [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  Wed Feb 10 22:11:37 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 10 Feb 2010 21:11:37 +0000
Subject: [issue7902] relative import broken
In-Reply-To: <1265828963.53.0.5315107426.issue7902@psf.upfronthosting.co.za>
Message-ID: <1265836297.9.0.429342605491.issue7902@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So doing the import manually through __import__('os', globals(), locals(), ['walk'], 1) does not work. My guess is it has something to do with the IMPORT_FROM opcode (or something related), but I don't have time right now to dig deeper.

----------

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

From report at bugs.python.org  Thu Feb 11 00:03:57 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 10 Feb 2010 23:03:57 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
In-Reply-To: <1265775641.62.0.698581723432.issue1578269@psf.upfronthosting.co.za>
Message-ID: <D67B8A86984F00488D0776065BA56DBD882237DF45@Teach.jaraco.com>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

> With patch #25, I get 6 test failures: test_glob, test_os,
> test_platform, test_posixpath, test_shutil, and test_tarfile.
> 
> This is interesting because the failures are different depending on how
> I compile Python. Running in WOW64 (32-bit Python on 64-bit Windows),
> the tests fail for not having the required privilege.

I'm unable to reproduce this. I'm using an automated script to checkout, patch, build, and test the code. You can probably use the same script as me; it's available as https://svn.jaraco.com/jaraco/python/incubator/test-python-symlink-patch.py . It should work on your system so long as you have 'patch' and 'svn' in the path and Visual Studio 9.0 in the default location. Would you be willing to try it, so at least we can eliminate the technique as a variable?

When I run the script as guest or admin, the 32-bit regression tests all seem to pass (I occasionally get a transient failure in test_os). The 64-bit ones, however, fail even without applying the patch. I haven't yet figured out why this is. There are plenty of failures in the build, so I was guessing the build is broken.

The fact that it's failing for not having the required privilege indicates to me that the lib/test/symlink_support.py isn't loading properly. Can you try 'from lib.test import symlink_support' and let me know what response you get?

> Running a 64-bit
> Python, the tests fail various asserts (see attached
> patch25results_python64.txt).

These asserts look very much like the ones I was seeing early on before I had addressed symlink artifacts in the tests. Why you would experience different behavior in the different architectures is still unclear.

In the meantime, I'm going to try to see if I can find a case where the import of symlink_support would fail unexpectedly.

----------
Added file: http://bugs.python.org/file16202/guest results.zip
Added file: http://bugs.python.org/file16203/admin results.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: guest results.zip
Type: application/x-zip-compressed
Size: 14370 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20100210/65224d34/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: admin results.zip
Type: application/x-zip-compressed
Size: 14219 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20100210/65224d34/attachment-0003.bin>

From report at bugs.python.org  Thu Feb 11 00:24:51 2010
From: report at bugs.python.org (mARK)
Date: Wed, 10 Feb 2010 23:24:51 +0000
Subject: [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 00:25:48 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 10 Feb 2010 23:25:48 +0000
Subject: [issue7903] Configure script incorrect for reasonably recent OpenBSD
In-Reply-To: <1265835897.46.0.381453341475.issue7903@psf.upfronthosting.co.za>
Message-ID: <1265844348.22.0.802454074723.issue7903@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Thanks for reporting. This looks like a duplicate of issue3920.

----------
nosy: +skrah

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

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


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Thanks for the report, could you provide a patch with unit tests?

----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed
versions: +Python 2.6, Python 2.7 -Python 2.5

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

From report at bugs.python.org  Thu Feb 11 01:00:17 2010
From: report at bugs.python.org (David Fischer)
Date: Thu, 11 Feb 2010 00:00:17 +0000
Subject: [issue3819] urllib2 sends Basic auth across redirects
In-Reply-To: <1220973164.56.0.503421072226.issue3819@psf.upfronthosting.co.za>
Message-ID: <1265846417.51.0.671188825649.issue3819@psf.upfronthosting.co.za>


David Fischer <dfischer at ucsdmail.com> added the comment:

I attached a diff of a fix for this bug. This may not be the ideal fix, but hopefully it will give the developer who actually does resolve it a good start.

----------
keywords: +patch
Added file: http://bugs.python.org/file16204/urllib2-3819.diff

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

From report at bugs.python.org  Thu Feb 11 01:29:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Feb 2010 00:29:54 +0000
Subject: [issue7835] Minor bug in 2.6.4 related to cleanup at end of program
Message-ID: <1265848194.37.0.125178090948.issue7835@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed in r78137 to trunk, r78138 py26, r78139 py3k, and r78140 py31.

----------
components: +Library (Lib) -Interpreter Core
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Feb 11 02:09:53 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Thu, 11 Feb 2010 01:09:53 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1265850593.83.0.935392418017.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Thanks for the quick update,
I confirm the fix for both issues;
just another finding (while testing the behaviour mentioned previously - msg91917)

The property name normalisation seem to be much more robust now, I just encountered an encoding error using a rather artificial input (in python 2.5, 2.6):

>>> regex.findall(ur"\p{Uppercase???Letter}", u"QW\p{Uppercase???Letter}as")

Traceback (most recent call last):
  File "<pyshell#4>", line 1, in <module>
    regex.findall(ur"\p{Uppercase???Letter}", u"QW\p{Uppercase???Letter}as")
  File "C:\Python25\lib\regex.py", line 213, in findall
    return _compile(pattern, flags).findall(string, overlapped=overlapped)
  File "C:\Python25\lib\regex.py", line 599, in _compile
    parsed = _parse_pattern(source, info)
  File "C:\Python25\lib\regex.py", line 690, in _parse_pattern
    branches = [_parse_sequence(source, info)]
  File "C:\Python25\lib\regex.py", line 702, in _parse_sequence
    item = _parse_item(source, info)
  File "C:\Python25\lib\regex.py", line 710, in _parse_item
    element = _parse_element(source, info)
  File "C:\Python25\lib\regex.py", line 837, in _parse_element
    return _parse_escape(source, info, False)
  File "C:\Python25\lib\regex.py", line 1098, in _parse_escape
    return _parse_property(source, info, in_set, ch)
  File "C:\Python25\lib\regex.py", line 1240, in _parse_property
    raise error("undefined property name '%s'" % name)
error: <unprintable error object>
>>> 

Not sure, how this would be fixed (i.e. whether the error message should be changed to unicode, if applicable).

Not surprisingly, in python 3.1, there is a correct message at the end:

regex.error: undefined property name 'Uppercase???Letter'

vbr

----------

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

From report at bugs.python.org  Thu Feb 11 02:31:48 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 11 Feb 2010 01:31:48 +0000
Subject: [issue1578269] Add os.link() and os.symlink() and os.path.islink()
	support for Windows
Message-ID: <1265851908.47.0.965830144378.issue1578269@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

False alarm, the failures are my fault. I had a previous version of symlink_support, and applying patch 25 added the contents of symlink_support to the file again, thus causing an ImportError on that file. Sorry about that.

I removed the file, applied patch 25 again, and the tests pass.

----------

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

From report at bugs.python.org  Thu Feb 11 02:43:56 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 11 Feb 2010 01:43:56 +0000
Subject: [issue7903] Configure script incorrect for reasonably recent OpenBSD
In-Reply-To: <1265835897.46.0.381453341475.issue7903@psf.upfronthosting.co.za>
Message-ID: <19315.15251.960126.800358@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

John> Current OpenBSD is at 4.7 with a new release every six months.
    John> diff below:
    ...
    John> -  OpenBSD/2.* | OpenBSD/3.[0123456789] | OpenBSD/4.[0123])
    John> +  OpenBSD/2.* | OpenBSD/3.* | OpenBSD/4.[01234567])

Wouldn't it be better to just use "OpenBSD/4.*" and fix it if/when a new
minor release makes the assumption false?

Skip

----------
nosy: +skip.montanaro

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

From report at bugs.python.org  Thu Feb 11 02:50:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Feb 2010 01:50:35 +0000
Subject: [issue5754] Shelve module writeback parameter does not act as
	advertised
In-Reply-To: <1239728605.41.0.419145925815.issue5754@psf.upfronthosting.co.za>
Message-ID: <1265853035.54.0.957880055991.issue5754@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for the patch.  I applied the doc patch and a slightly simplified version of the test in r78141 (we tend to just let errors bubble up rather than code explicit Fails, since as often as not if you provide a specific message it turns out to be wrong when something breaks the test).
I'll merge the change to the other branches as well.

----------
assignee: aleax -> r.david.murray
nosy: +r.david.murray
priority:  -> normal
resolution:  -> accepted
stage: test needed -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Feb 11 03:16:56 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 11 Feb 2010 02:16:56 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1265854616.82.0.0561793192784.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I've been aware for some time that exception messages in Python 2 can't be Unicode, but I wasn't sure which encoding to use, so I've decided to use that of sys.stdout.

It appears to work OK in IDLE and at the Python prompt.

issue2636-20100211.zip is the new version of the regex module.

----------
Added file: http://bugs.python.org/file16205/issue2636-20100211.zip

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

From report at bugs.python.org  Thu Feb 11 03:17:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Feb 2010 02:17:32 +0000
Subject: [issue7835] Minor bug in 2.6.4 related to cleanup at end of program
Message-ID: <1265854652.27.0.899090293275.issue7835@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Fix modified to catch the case where the shutdown has also deleted module dictionary, at MAL's suggestion, in r78142.

----------

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

From report at bugs.python.org  Thu Feb 11 03:37:52 2010
From: report at bugs.python.org (johns)
Date: Thu, 11 Feb 2010 02:37:52 +0000
Subject: [issue7903] Configure script incorrect for reasonably recent OpenBSD
In-Reply-To: <1265835897.46.0.381453341475.issue7903@psf.upfronthosting.co.za>
Message-ID: <1265855872.8.0.243425765173.issue7903@psf.upfronthosting.co.za>


johns <j0 at cox.net> added the comment:

Yeah or better yet take out the versioning entirely.

----------

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

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: [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 04:17:59 2010
From: report at bugs.python.org (Meador Inge)
Date: Thu, 11 Feb 2010 03:17:59 +0000
Subject: [issue2537] re.compile(r'((x|y+)*)*') should fail
In-Reply-To: <1207157766.7.0.917289707609.issue2537@psf.upfronthosting.co.za>
Message-ID: <1265858279.19.0.734763569521.issue2537@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> Ruby's behavior seems best to me.

We can obtain the Ruby behavior easily.  There is one check in sre_compile.py in the '_simple' function that needs to be removed (see attached patch).  Whether or not the Ruby behavior is the "correct" behavior I am still not sure.  In any case, I think throwing an exception is to aggressive for this case.

----------
keywords: +patch
nosy: +minge
Added file: http://bugs.python.org/file16207/issue-2537.patch

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

From report at bugs.python.org  Thu Feb 11 04:32:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Feb 2010 03:32:44 +0000
Subject: [issue5483] [PATCH]Add FastDbfilenameShelf: shelf nerver sync cache
	even when writeback=True
In-Reply-To: <1236949925.76.0.785103969967.issue5483@psf.upfronthosting.co.za>
Message-ID: <1265859164.42.0.56618196441.issue5483@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I agree that caching for speed is something that should be implemented in another layer.  It certainly is orthogonal to the writeback issue.  The best caching strategy is going to depend on the application, so I don't think caching for speed belongs in Shelve itself.  Closing as rejected.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Feb 11 04:48:23 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 11 Feb 2010 03:48:23 +0000
Subject: [issue7904] urllib.urlparse mishandles novel schemes
In-Reply-To: <1265844290.89.0.139975092944.issue7904@psf.upfronthosting.co.za>
Message-ID: <1265860103.24.0.837164073204.issue7904@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Does s3 stand for the amazon s3 services? urlparse does not have it under its list of known schemes yet. Does s3 have any specifications as such or is aligned towards any of the known schemes (like http or ftp)?

s3 is valid scheme name according to rfc 3986, but urlparse module does not seem to recognize it. If we say, s3 to be much similar to http, then it can be added to list of known schemes. Does Amazon say anything about it?

----------
assignee:  -> orsenthil
nosy: +orsenthil

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

From report at bugs.python.org  Thu Feb 11 05:14:55 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 11 Feb 2010 04:14:55 +0000
Subject: [issue7899] MemoryError While Executing Python Code
In-Reply-To: <1265813909.95.0.996847795707.issue7899@psf.upfronthosting.co.za>
Message-ID: <1265861695.67.0.405221103815.issue7899@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Can you provide a test case which can reproduce the issue? Specifically one which doesn't require the use of your DatabaseLibrary package?

----------
nosy: +brian.curtin
priority:  -> normal
stage:  -> test needed
type: performance -> resource usage

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

From report at bugs.python.org  Thu Feb 11 05:53:13 2010
From: report at bugs.python.org (mARK)
Date: Thu, 11 Feb 2010 04:53:13 +0000
Subject: [issue7904] urllib.urlparse mishandles novel schemes
In-Reply-To: <1265844290.89.0.139975092944.issue7904@psf.upfronthosting.co.za>
Message-ID: <1265863993.37.0.239825291374.issue7904@psf.upfronthosting.co.za>


mARK <python.mbloore at xoxy.net> added the comment:

it's not actually necessary to have a list of known schemes.  any url that has a double slash after the colon is expected to follow that with an authority section (what urlparse calls "netloc"), optionally followed by a path, which starts with a slash.

there are various defined schemes with their own syntax within the URL framework, but one is free to invent new ones with the general form
scheme://netloc/path

----------

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

From report at bugs.python.org  Thu Feb 11 06:36:48 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 11 Feb 2010 05:36:48 +0000
Subject: [issue7903] Configure script incorrect for reasonably recent OpenBSD
In-Reply-To: <1265855872.8.0.243425765173.issue7903@psf.upfronthosting.co.za>
Message-ID: <19315.38752.558708.260009@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

>> Yeah or better yet take out the versioning entirely.

Perhaps.  Is 1.x treated differently than 2, 3 or 4?

S

----------

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

From report at bugs.python.org  Thu Feb 11 06:49:58 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 11 Feb 2010 05:49:58 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1265867398.01.0.119874234697.issue7582@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I am sorry - too much windows to reply. This must be *unified*, of course.

----------

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

From report at bugs.python.org  Thu Feb 11 09:13:40 2010
From: report at bugs.python.org (Prashanth noble)
Date: Thu, 11 Feb 2010 08:13:40 +0000
Subject: [issue7899] MemoryError While Executing Python Code
In-Reply-To: <1265813909.95.0.996847795707.issue7899@psf.upfronthosting.co.za>
Message-ID: <1265876020.4.0.138341356522.issue7899@psf.upfronthosting.co.za>


Prashanth noble <prashanth.bose at gmail.com> added the comment:

please find the testcase i am using

----------
Added file: http://bugs.python.org/file16208/Aura_Test_Scripts_FCT_ACTUSER_EVENT_L.tsv

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

From report at bugs.python.org  Thu Feb 11 09:35:05 2010
From: report at bugs.python.org (Dagobert Michelsen)
Date: Thu, 11 Feb 2010 08:35:05 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1265877305.59.0.763249523101.issue7242@psf.upfronthosting.co.za>


Dagobert Michelsen <dam at opencsw.org> added the comment:

I verified patch_2.diff on Solaris 10 w/SOS11 and it actually resolves a number of issues I had with Mercurial.

----------
nosy: +dagobert Michelsen

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

From report at bugs.python.org  Thu Feb 11 10:51:08 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 11 Feb 2010 09:51:08 +0000
Subject: [issue7774] sys.executable: wrong location if zeroth command argument
	is modified.
In-Reply-To: <1264375402.09.0.657503917056.issue7774@psf.upfronthosting.co.za>
Message-ID: <1265881868.47.0.247170151506.issue7774@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Similar failures with or without argv 0:

 ~ $ sh -c 'exec -a missing ./python -c "import sys; print sys.executable"'
/home/user/dev/python/trunk/

 ~ $ sh -c 'exec -a "" ./python -c "import sys; print sys.executable"'
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
'import site' failed; use -v for traceback
/usr/bin/python

----------

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

From report at bugs.python.org  Thu Feb 11 13:40:53 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 11 Feb 2010 12:40:53 +0000
Subject: [issue4037] doctest.py should include method descriptors when looking
	inside a class __dict__
In-Reply-To: <1223079206.04.0.17382541424.issue4037@psf.upfronthosting.co.za>
Message-ID: <1265892053.83.0.133642242924.issue4037@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ncoghlan

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

From report at bugs.python.org  Thu Feb 11 14:16:44 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 11 Feb 2010 13:16:44 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1252586309.61.0.470595753955.issue6877@psf.upfronthosting.co.za>
Message-ID: <1265894204.64.0.247858309604.issue6877@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've added the tests to the 2.6 branch and have ported the #ifdef guard around the prototype for completion_matches to the trunk and 3.2.

I'm therefore closing the issue.

----------
status: open -> closed

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

From report at bugs.python.org  Thu Feb 11 14:40:21 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 11 Feb 2010 13:40:21 +0000
Subject: [issue7715] Allow use of GNU arch on Darwin
In-Reply-To: <1263659628.27.0.679620015002.issue7715@psf.upfronthosting.co.za>
Message-ID: <1265895621.02.0.569552949238.issue7715@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Ned: I fixed the ARCH_RUN_32BIT definition for 3-way universal builds in r78150. 

Also ported the patch to 2.6, 3.2 and 3.1.

----------
status: open -> closed

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

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: [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:53:20 2010
From: report at bugs.python.org (Meador Inge)
Date: Thu, 11 Feb 2010 13:53:20 +0000
Subject: [issue6877] enable compilation of readline module on Mac OS X 10.5
	and 10.6
In-Reply-To: <1265894204.64.0.247858309604.issue6877@psf.upfronthosting.co.za>
Message-ID: <4095897c1002110553n691ad1d9we97a4360336b0a4e@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

On Thu, Feb 11, 2010 at 7:16 AM, Ronald Oussoren <report at bugs.python.org>wrote:

>
> I've added the tests to the 2.6 branch and have ported the #ifdef guard
> around the prototype for completion_matches to the trunk and 3.2.
>

Verified in trunk.  Thanks Ronald!

----------
Added file: http://bugs.python.org/file16209/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6877>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">On Thu, Feb 11, 2010 at 7:16 AM, Ronald Oussoren <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>I&#39;ve added the tests to the 2.6 branch and have ported the #ifdef guard around the prototype for completion_matches to the trunk and 3.2.</div></blockquote><div><br></div><div>Verified in trunk. ??Thanks Ronald!??</div>
</div><br>-- <br># Meador<br>

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: [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:17:12 2010
From: report at bugs.python.org (Zsolt Cserna)
Date: Thu, 11 Feb 2010 14:17:12 +0000
Subject: [issue1471934] Python libcrypt build problem on Solaris 8, 9,
	10 and OpenSolaris
Message-ID: <1265897832.46.0.120549341723.issue1471934@psf.upfronthosting.co.za>


Changes by Zsolt Cserna <zsolt.cserna at morganstanley.com>:


----------
nosy: +csernazs

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

From report at bugs.python.org  Thu Feb 11 15:28:08 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 11 Feb 2010 14:28:08 +0000
Subject: [issue7907] winreg docs: CreateKeyEx should be CreateKey (minor)
In-Reply-To: <1265896728.51.0.656346450025.issue7907@psf.upfronthosting.co.za>
Message-ID: <1265898488.62.0.300855552305.issue7907@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Windows
keywords: +needs review, patch
priority:  -> normal
stage:  -> patch review
type:  -> behavior
versions: +Python 3.1, Python 3.2 -Python 2.5
Added file: http://bugs.python.org/file16210/issue7907.diff

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

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


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Feb 11 15:36:23 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 11 Feb 2010 14:36:23 +0000
Subject: [issue7906] float("INFI") returns inf on certain platforms
In-Reply-To: <1265895632.82.0.0740289647812.issue7906@psf.upfronthosting.co.za>
Message-ID: <1265898983.67.0.434860625109.issue7906@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith, mark.dickinson

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

From report at bugs.python.org  Thu Feb 11 15:46:34 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 11 Feb 2010 14:46:34 +0000
Subject: [issue7899] MemoryError While Executing Python Code
In-Reply-To: <1265813909.95.0.996847795707.issue7899@psf.upfronthosting.co.za>
Message-ID: <1265899594.74.0.989504620637.issue7899@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Prashanth, I'm not even sure what to do with that file.

Can you provide a Python script which demonstrates your issue? It should be something that myself or others could run on their computer, free of any third party packages. This will isolate the issue to Python and show us how to reproduce what you are seeing.

----------

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

From report at bugs.python.org  Thu Feb 11 15:53:46 2010
From: report at bugs.python.org (johns)
Date: Thu, 11 Feb 2010 14:53:46 +0000
Subject: [issue7903] Configure script incorrect for reasonably recent OpenBSD
In-Reply-To: <1265835897.46.0.381453341475.issue7903@psf.upfronthosting.co.za>
Message-ID: <1265900026.71.0.973889553517.issue7903@psf.upfronthosting.co.za>


johns <j0 at cox.net> added the comment:

Perhaps 1.x was never considered.  OpenBSD 2.0 was released in 1996.  The OS developers only support the current release version and one "minor" release back anyway.  The major release number isn't significant.  It's just incremented after the "minor" release is bumped from 9.  There's a release every six months so the difference in "major" release numbers is 5 years.  No one should even be running 3.x or even early 4.x anymore.

----------

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

From report at bugs.python.org  Thu Feb 11 16:09:45 2010
From: report at bugs.python.org (Arno Bakker)
Date: Thu, 11 Feb 2010 15:09:45 +0000
Subject: [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:10:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Feb 2010 15:10:28 +0000
Subject: [issue7899] MemoryError While Executing Python Code
In-Reply-To: <1265813909.95.0.996847795707.issue7899@psf.upfronthosting.co.za>
Message-ID: <1265901028.55.0.357716881932.issue7899@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If these 8 million records are loaded into memory, it can be normal to get a MemoryError. It depends on the complexity of the records (number of fields) and the way they are kept in memory (tuples? dicts?); and of course of the amount of available RAM in your system.

In any case your description of the problem is not sufficiently detailed for us to now whether it's a problem with Python, a problem with your code, or simply some mismatching expectations on your part.

----------
nosy: +pitrou

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

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


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report, and for the analysis.

I'd call this a bug in the Solaris strtod function (though that doesn't preclude adding a workaround for Python):  the C standards (well, C99, anyway;  I don't have access to C89 at the moment) enumerate clearly which strings are permitted, and "INFI" isn't among them.

string <-> float conversions got significantly reworked for Python 2.7 and 3.1, so there shouldn't be any problem with those versions.  Are you in a position to confirm this?

It would be fairly easy to work around this strtod issue by backporting the _Py_parse_inf_or_nan and case_insensitive match functions (in Python/pystrtod.c) from trunk to Python 2.6, and using those functions in PyOS_ascii_strtod.

----------

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

From report at bugs.python.org  Thu Feb 11 16:17:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Feb 2010 15:17:41 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1265901461.06.0.619217858245.issue7897@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'm not sure what this brings. It is easy to write a loop iterating over test data.
What parametric testing could bring is precise progress and error display (displaying the parameters for each run), but this doesn't seem to be the case here, since you are not making the parameters available to unittest. Your examples just boil down to writing "yield is_smaller(x, y)" instead of "self.assertLess(x, y)"...

----------
nosy: +pitrou

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

From report at bugs.python.org  Thu Feb 11 16:18:45 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 11 Feb 2010 15:18:45 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1265901525.11.0.31174071618.issue7897@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

With paramterized tests *all* the tests are run and *all* failures reported. With testing in a loop the tests stop at the first failure.

----------

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

From report at bugs.python.org  Thu Feb 11 16:22:02 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 11 Feb 2010 15:22:02 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1265901722.32.0.28194759773.issue7897@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

By the way - I have no opinion on whether or not using yield is the right way to support parameterized tests. It may be better for the test method to take arguments, and be decorated as a parameterized test, with the decorator providing the parameters. When I come to look at it I will look at how py.test and nose do it and solicit advice on the Testing in Python list. We had a useful discussion there previously that would be good to refer to.

----------

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

From report at bugs.python.org  Thu Feb 11 16:22:08 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 11 Feb 2010 15:22:08 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1265901728.97.0.29639357185.issue7897@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

> With paramterized tests *all* the tests are run and *all* failures reported. With testing in a loop the tests stop at the first failure.

+1 to this justification.  Parameterized tests are a big win over a simple for loop in a test.

(However, I haven't looked at the IPython code at all, and Antoine's objection seemed to have something in particular to do with the IPython code?)

----------
nosy: +exarkun

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

From report at bugs.python.org  Thu Feb 11 16:26:29 2010
From: report at bugs.python.org (Matthew Russell)
Date: Thu, 11 Feb 2010 15:26:29 +0000
Subject: [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 16:28:23 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 11 Feb 2010 15:28:23 +0000
Subject: [issue7910] immutability w/r to tuple.__add__
In-Reply-To: <1265901988.91.0.740301104543.issue7910@psf.upfronthosting.co.za>
Message-ID: <1265902103.31.0.502317227619.issue7910@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Your output looks fishy.  Anyway, the behavior of += isn't a bug:

>>> a = b = (1, 2)
>>> a += (1, 2, 3)
>>> a
(1, 2, 1, 2, 3)
>>> a is b
False
>>> 

It's confusing, to be sure, but no mutation is going on.  += is only in-place if applied to something that supports mutation this way (by implementing __iadd__).

----------
nosy: +exarkun

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

From report at bugs.python.org  Thu Feb 11 16:32:41 2010
From: report at bugs.python.org (Tim Golden)
Date: Thu, 11 Feb 2010 15:32:41 +0000
Subject: [issue7910] immutability w/r to tuple.__add__
In-Reply-To: <1265901988.91.0.740301104543.issue7910@psf.upfronthosting.co.za>
Message-ID: <4B742315.3080703@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Just think about it for a minute:

t = (1, 2)
print id (t), t
t += (1, 2, 3)
print id (t), t

Not mutating, merely creating a new new object
and giving it the same name

----------
nosy: +tim.golden

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

From report at bugs.python.org  Thu Feb 11 16:33:13 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 11 Feb 2010 15:33:13 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1265902393.0.0.931435775696.issue7897@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

> It may be better for the test method to take arguments, and 
> be decorated as a parameterized test, with the decorator 
> providing the parameters.

+1 on something like this. That's also how NUnit supports parameterized tests.

----------
nosy: +brian.curtin

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

From report at bugs.python.org  Thu Feb 11 16:34:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Feb 2010 15:34:16 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265901728.97.0.29639357185.issue7897@psf.upfronthosting.co.za>
Message-ID: <1265902538.3529.6.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > With paramterized tests *all* the tests are run and *all* failures reported. With testing in a loop the tests stop at the first failure.
> 
> +1 to this justification.  Parameterized tests are a big win over a
> simple for loop in a test.

Ah, thank you. Looks better indeed.

> (However, I haven't looked at the IPython code at all, and Antoine's
> objection seemed to have something in particular to do with the
> IPython code?)

No, it has to do that you need to be able to distinguish the different
runs of your parameterized test (the same way you distinguish between
different test methods by their names, or line numbers, in the test
report).

If I have 500 runs in my parameterized (*) test, and the only failure
reported is that "2 is not greater than 3", I don't know where to start
looking because the traceback won't give me the information of *which*
parameters were currently in use.

(*) (this is horrible to type)

----------

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

From report at bugs.python.org  Thu Feb 11 16:38:11 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 11 Feb 2010 15:38:11 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1265902691.59.0.0175914389688.issue7897@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Antoine: the failure message would include a repr of the parameters used in the particular test that failed. So you can tell which test failed and with what parameters.

----------

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

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


Matthew Russell <matt.horizon5 at gmail.com> added the comment:

Yes, the output is fishy indeed my bad (paste error).

Tim: I hadn't thought for long enough or thought to check with the id builtin - nice catch.

----------
status: open -> closed

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

From report at bugs.python.org  Thu Feb 11 16:53:56 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 11 Feb 2010 15:53:56 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1265903636.49.0.528832145672.issue7897@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

Something else I think it would be nice to consider is what the id() (and shortDescription(), heh) of the resulting tests will be.

It would be great if the id were sufficient to identify a particular test *and* data combination.

In trial, we're trying to use test ids to support distributed test running.  If the above property holds for parameterized tests, then we'll be able to automatically distribute them to different processes or hosts to be run.

----------

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

From report at bugs.python.org  Thu Feb 11 17:19:41 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 11 Feb 2010 16:19:41 +0000
Subject: [issue7908] remove leftover macos9 support code
In-Reply-To: <1265898907.53.0.125133680219.issue7908@psf.upfronthosting.co.za>
Message-ID: <1265905181.74.0.270000155903.issue7908@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
keywords: +needs review

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

From report at bugs.python.org  Thu Feb 11 17:20:57 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 11 Feb 2010 16:20:57 +0000
Subject: [issue7908] remove leftover macos9 support code
In-Reply-To: <1265898907.53.0.125133680219.issue7908@psf.upfronthosting.co.za>
Message-ID: <1265905257.44.0.33596437326.issue7908@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The reason I'd like a patch review is that it affects a lot of files and want a second pair of eyes to check that I haven't been too agressive.

The patch itself doesn't cause regressions in the unittests.

----------

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

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


Zsolt Cserna <zsolt.cserna at morganstanley.com> added the comment:

I was not able to compile 3.1.1 due to issue6236, but with 2.7a3 it raises the expected ValueError, which is correct.

Is there any chance to get those changes you mentioned backported to 2.6?

----------

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

From report at bugs.python.org  Thu Feb 11 18:45:27 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 11 Feb 2010 17:45:27 +0000
Subject: [issue7910] immutability w/r to tuple.__add__
In-Reply-To: <1265901988.91.0.740301104543.issue7910@psf.upfronthosting.co.za>
Message-ID: <1265910327.7.0.708474525879.issue7910@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> invalid

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

From report at bugs.python.org  Thu Feb 11 19:20:39 2010
From: report at bugs.python.org (mARK)
Date: Thu, 11 Feb 2010 18:20:39 +0000
Subject: [issue7904] urlparse.urlsplit mishandles novel schemes
In-Reply-To: <1265844290.89.0.139975092944.issue7904@psf.upfronthosting.co.za>
Message-ID: <1265912439.14.0.87600094873.issue7904@psf.upfronthosting.co.za>


mARK <python.mbloore at xoxy.net> added the comment:

i have attached an svn diff of my (very simple!) fix and added unit test for python 2.7.

----------
title: urllib.urlparse mishandles novel schemes -> urlparse.urlsplit mishandles novel schemes
Added file: http://bugs.python.org/file16212/fix7904.txt

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

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: [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: [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:44:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Feb 2010 18:44:21 +0000
Subject: [issue7912] Error in additon of decimal numbers
In-Reply-To: <1265913617.65.0.207561633263.issue7912@psf.upfronthosting.co.za>
Message-ID: <1265913861.67.0.866586633597.issue7912@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Read this:

http://docs.python.org/tutorial/floatingpoint.html?highlight=rounding

And then perhaps take a look at the Decimal package.

----------
nosy: +r.david.murray
priority:  -> low
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Feb 11 19:48:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 11 Feb 2010 18:48:55 +0000
Subject: [issue7906] float("INFI") returns inf on certain platforms
In-Reply-To: <1265895632.82.0.0740289647812.issue7906@psf.upfronthosting.co.za>
Message-ID: <1265914135.15.0.754309801865.issue7906@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Is there any chance to get those changes you mentioned backported to 2.6?

Actually, to be honest, I'm not sure that backporting these changes to the release branch is a good idea.  Is this bug causing problems in real code (besides the test suite)?

It seems to me that this bug is fairly harmless, and the backport of the 2.7 behaviour could have unintended consequences (seems unlikely, but it's always difficult to be sure :);  I'm tempted suggest closing it as a 'won't fix', especially given that it's already fixed in 2.7.

----------

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

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: [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 19:58:48 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 11 Feb 2010 18:58:48 +0000
Subject: [issue7906] float("INFI") returns inf on certain platforms
In-Reply-To: <1265895632.82.0.0740289647812.issue7906@psf.upfronthosting.co.za>
Message-ID: <1265914728.78.0.938184305598.issue7906@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I concur with Mark.

----------
nosy: +rhettinger
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Thu Feb 11 19:59:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Feb 2010 18:59:22 +0000
Subject: [issue6608] asctime causing python to crash
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1265914762.59.0.809304163641.issue6608@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Retrograding to critical after popular python-dev demand.

----------
nosy: +pitrou
priority: release blocker -> critical

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

From report at bugs.python.org  Thu Feb 11 20:08:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Feb 2010 19:08:37 +0000
Subject: [issue7911] unittest.TestCase.longMessage should default to True in
	Python 3.2
In-Reply-To: <1265915317.63.0.548370408241.issue7911@psf.upfronthosting.co.za>
Message-ID: <1265915317.63.0.548370408241.issue7911@psf.upfronthosting.co.za>


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

+1

----------
nosy: +r.david.murray
priority:  -> normal
type:  -> feature request

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

From report at bugs.python.org  Thu Feb 11 21:49:46 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 11 Feb 2010 20:49:46 +0000
Subject: [issue2537] re.compile(r'((x|y+)*)*') should fail
In-Reply-To: <1207157766.7.0.917289707609.issue2537@psf.upfronthosting.co.za>
Message-ID: <1265921386.57.0.457109107816.issue2537@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

The re module is addressed in issue #2636.

BTW, my regex module behaves like Ruby:

>>> regex.sub(r"((x|y)*)*", "(\\1, \\2)", "xyyzy", count=1)
'(, y)zy'
>>> regex.sub(r"((x|y+)*)*", "(\\1, \\2)", "xyyzy", count=1)
'(, yy)zy'

----------
nosy: +mrabarnett

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

From report at bugs.python.org  Thu Feb 11 22:20:21 2010
From: report at bugs.python.org (Nick)
Date: Thu, 11 Feb 2010 21:20:21 +0000
Subject: [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  Thu Feb 11 22:48:03 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 11 Feb 2010 21:48:03 +0000
Subject: [issue7863] platform module doesn't detect Windows 7
In-Reply-To: <1265821281.17.0.716546674294.issue7863@psf.upfronthosting.co.za>
Message-ID: <4B747B10.9060800@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Brian Curtin wrote:
> 
> Brian Curtin <curtin at acm.org> added the comment:
> 
> I'll look into whatever other trickery could be applied to 2.6/3.1.
> 
> The patch against trunk works correctly for Win7, Win 2003 Server SP1, Win XP SP2, and Win 2000 Server SP2. platform.platform() outputs the same info for the latter three OSes whether or not the patch is applied. 
> 
> The csd change will work going back to Windows 2000. If we have to support anything prior, which I don't believe we do, then you are correct that it won't work. If that's an issue, I can revert that part of the change.

Python 2.7 doesn't support Windows NT, so we should be fine if the
patch can handle Windows 2000 and later.

See http://www.python.org/dev/peps/pep-0011/

----------

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

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


Nick <nick.allgood at gmail.com> added the comment:

Ok this was my own mistake and not a bug.. really sorry about this.

Moving the following code ABOVE the IntVar() calls allows it to work:

app = Tk()
app.title("TESTING")
app.geometry('300x100+200+100')

See revised attached

----------
status: open -> closed
Added file: http://bugs.python.org/file16215/intvar-POC.py

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

From report at bugs.python.org  Thu Feb 11 22:50:55 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 11 Feb 2010 21:50:55 +0000
Subject: [issue7863] platform module doesn't detect Windows 7
In-Reply-To: <4B747B10.9060800@egenix.com>
Message-ID: <4B747BBC.7020907@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Marc-Andre Lemburg wrote:
> 
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> 
> Brian Curtin wrote:
>>
>> Brian Curtin <curtin at acm.org> added the comment:
>>
>> I'll look into whatever other trickery could be applied to 2.6/3.1.
>>
>> The patch against trunk works correctly for Win7, Win 2003 Server SP1, Win XP SP2, and Win 2000 Server SP2. platform.platform() outputs the same info for the latter three OSes whether or not the patch is applied. 
>>
>> The csd change will work going back to Windows 2000. If we have to support anything prior, which I don't believe we do, then you are correct that it won't work. If that's an issue, I can revert that part of the change.
> 
> Python 2.7 doesn't support Windows NT, so we should be fine if the
> patch can handle Windows 2000 and later.
> 
> See http://www.python.org/dev/peps/pep-0011/

Hmm, then again: platform.py supports more than just the latest
Python release, so it's better to only use the new csd
approach for Python versions that do support the new windows
version named tuple return value and fallback to the old style
on all other versions.

----------

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

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


Changes by Brian Curtin <curtin at acm.org>:


----------
resolution:  -> invalid
type: compile error -> behavior

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

From report at bugs.python.org  Thu Feb 11 23:17:22 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 11 Feb 2010 22:17:22 +0000
Subject: [issue7885] test_distutils fails if Python built in separate directory
In-Reply-To: <1265647953.87.0.513905112062.issue7885@psf.upfronthosting.co.za>
Message-ID: <1265926642.94.0.888582208786.issue7885@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

r78136 completely broke this build.
before was enough to add "old workdir" in first place as library directory to make test_get_outputs happy

----------
nosy: +rpetrov

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

From report at bugs.python.org  Fri Feb 12 00:41:05 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 11 Feb 2010 23:41:05 +0000
Subject: [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: <1265931665.9.0.893510824823.issue7909@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed
type:  -> behavior

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

From report at bugs.python.org  Fri Feb 12 00:48:45 2010
From: report at bugs.python.org (Fernando Perez)
Date: Thu, 11 Feb 2010 23:48:45 +0000
Subject: [issue7897] Support parametrized tests in unittest
In-Reply-To: <1265768482.24.0.694001982317.issue7897@psf.upfronthosting.co.za>
Message-ID: <1265932125.77.0.101493183864.issue7897@psf.upfronthosting.co.za>


Fernando Perez <fdo.perez at gmail.com> added the comment:

I should probably have clarified better our reasons for using this type of code.  The first is the one Michael pointed out, where such parametric tests all execute; it's very common in scientific computing to have algorithms that only fail for certain values, so it's important to identify these points of failure easily while still running the entire test suite.  

The second is that the approach nose uses produces on failure the nose stack, not the stack of the test. Nose consumes the test generators at test discovery time, and then simply calls the stored assertions at test execution time.  If a test fails, you see a nose traceback which is effectively useless for debugging and with which using --pdb for interactive debugging doesn't help much (all you can do is print the values, as your own stack is gone).  This code, in contrast, evaluates the full test at execution time, so a failure can be inspected 'live'.  In practice this makes an enormous difference in a test suite being actively useful for ongoing development where changes may send you into debugging often.

I hope this helps clarify the intent of the code better, I'd be happy to provide further details.

----------

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

From report at bugs.python.org  Fri Feb 12 01:14:00 2010
From: report at bugs.python.org (Mathew Martineau)
Date: Fri, 12 Feb 2010 00:14:00 +0000
Subject: [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: <1265933640.02.0.711195878574.issue7834@psf.upfronthosting.co.za>


Mathew Martineau <mat at martineau.name> added the comment:

I can submit a patch, but my employer has an involved process for doing this (even for small fixes like this).  It will take a few more days to get to a point where I can post the patch, but I will do so as soon as I can.

----------

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

From report at bugs.python.org  Fri Feb 12 01:33:18 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Feb 2010 00:33:18 +0000
Subject: [issue7907] winreg docs: CreateKeyEx should be CreateKey (minor)
In-Reply-To: <1265896728.51.0.656346450025.issue7907@psf.upfronthosting.co.za>
Message-ID: <1265934798.27.0.271244646819.issue7907@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r78162 (trunk), r78163 (release26-maint), r78164 (py3k) and r78165 (release31-maint), thanks for the report and the patch!

----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

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


Brian Harring <ferringb at gmail.com> added the comment:

@benjamin:

Tests can be written; the reason this patch doesn't bundle tests up front is that I wasn't going to burn the time till I knew they were needed since I expected the concept to require some debate.

As for the hacks angle, there isn't anything hackish there- hackish is what you have to do w/out either of these patches (http://www.pkgcore.org/trac/pkgcore/browser/snakeoil/snakeoil/caching_2to3.py).  I understand not everyone likes classes mixed on the fly, but it's a perfectly valid technique w/ many, many valid uses.

Converting the innards of 2to3 over to a generalized plugin interface frankly is overkill from where I'm standing- being able to plugin new fixers is one thing (very useful in my opinion but orthogonal to what this ticke tis about), being able to plugin on the fly different refactoring outputers is another thing.

Personally what's in place w/in allow_alternate_output_tools.patch is more than enough for the crazy ideas I've got kicking around.

If you've got a specific complaint in the patch, an area that is dodgy/hacky, state it please- I'm more than open to actionable criticisms.

----------

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

From report at bugs.python.org  Fri Feb 12 03:09:13 2010
From: report at bugs.python.org (Craig McQueen)
Date: Fri, 12 Feb 2010 02:09:13 +0000
Subject: [issue4617] SyntaxError when free variable name is also an exception
	target
In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za>
Message-ID: <1265940553.34.0.0766783336387.issue4617@psf.upfronthosting.co.za>


Craig McQueen <python at craig.mcqueen.id.au> added the comment:

There's also this one which caught me out:

def outer():
  x = 0
  y = (x for i in range(10))
  del x  # SyntaxError

----------
nosy: +cmcqueen1975

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

From report at bugs.python.org  Fri Feb 12 03:12:26 2010
From: report at bugs.python.org (Meador Inge)
Date: Fri, 12 Feb 2010 02:12:26 +0000
Subject: [issue2537] re.compile(r'((x|y+)*)*') should fail
In-Reply-To: <1207157766.7.0.917289707609.issue2537@psf.upfronthosting.co.za>
Message-ID: <1265940746.61.0.782243660806.issue2537@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> The re module is addressed in issue #2636.

Wow, that issue thread is massive...  What about the 're' module is addressed?  Is 'regex' replacing 're'?  Is 'regex' being rolled into 're'?  Are they both going to exist?

----------
components: +Regular Expressions
type:  -> behavior

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

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: [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 03:22:55 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Feb 2010 02:22:55 +0000
Subject: [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: <1265941375.02.0.0235889848256.issue7915@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Could you provide the list in another format (e.g. in a plain .py script or as a .txt file)?

----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed
versions:  -Python 2.5

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

From report at bugs.python.org  Fri Feb 12 03:23:11 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Feb 2010 02:23:11 +0000
Subject: [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: <1265941391.23.0.638714746891.issue7915@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed 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 03:27:18 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 12 Feb 2010 02:27:18 +0000
Subject: [issue2537] re.compile(r'((x|y+)*)*') should fail
In-Reply-To: <1207157766.7.0.917289707609.issue2537@psf.upfronthosting.co.za>
Message-ID: <1265941638.4.0.177186958646.issue2537@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

The issue started about updating the re module and adding features that other languages already possess in their regex implementations (the last time any significant work was done on it was in 2003).

The hope is that the new regex implementation will eventually replace the existing one, and putting it initially in a module called 'regex' allows it to be tested more easily.

You can do:

import regex as re

and existing code should still work.

----------

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

From report at bugs.python.org  Fri Feb 12 03:27:46 2010
From: report at bugs.python.org (Alex Coventry)
Date: Fri, 12 Feb 2010 02:27:46 +0000
Subject: [issue7915] A lists which list.sort seems to leave out of order.
In-Reply-To: <1265941375.02.0.0235889848256.issue7915@psf.upfronthosting.co.za>
	(Ezio Melotti's message of "Fri, 12 Feb 2010 02:22:55 +0000")
Message-ID: <etdhbpn428y.fsf@biohazard-cafe.mit.edu>


Alex Coventry <throwaway at mit.edu> added the comment:

No.  It's 10M, gzipped.  It's constructed from genome-wide association
data, which is also huge, intrinsically complex, and protected by rules
regarding research on humans.  If the bug tracker won't take it do I
have any other options?

----------

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

From report at bugs.python.org  Fri Feb 12 03:28:34 2010
From: report at bugs.python.org (Alex Coventry)
Date: Fri, 12 Feb 2010 02:28:34 +0000
Subject: [issue7915] A lists which list.sort seems to leave out of order.
In-Reply-To: <1265941375.02.0.0235889848256.issue7915@psf.upfronthosting.co.za>
	(Ezio Melotti's message of "Fri, 12 Feb 2010 02:22:55 +0000")
Message-ID: <etdd40b427m.fsf@biohazard-cafe.mit.edu>


Alex Coventry <throwaway at mit.edu> added the comment:

Oh, I guess I could make it a gzipped text file.  Hang on.

----------

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

From report at bugs.python.org  Fri Feb 12 03:29:20 2010
From: report at bugs.python.org (Thomas Wouters)
Date: Fri, 12 Feb 2010 02:29:20 +0000
Subject: [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: <1265941760.06.0.168417743171.issue7915@psf.upfronthosting.co.za>


Thomas Wouters <thomas at python.org> added the comment:

You have a nan in your list of tuples, which screws up the sorting. After the first sort, elements 580395-7 are:

(0.99257340581672904, 551095), 
(nan, 551371),
(6.6494600485570754e-14, 551526),

----------
nosy: +twouters
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Fri Feb 12 03:30:21 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Feb 2010 02:30:21 +0000
Subject: [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: <1265941821.23.0.290754627231.issue7915@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage: test needed -> committed/rejected

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

From report at bugs.python.org  Fri Feb 12 03:30:53 2010
From: report at bugs.python.org (Alex Coventry)
Date: Fri, 12 Feb 2010 02:30:53 +0000
Subject: [issue7915] A lists which list.sort seems to leave out of order.
In-Reply-To: <1265941760.06.0.168417743171.issue7915@psf.upfronthosting.co.za>
	(Thomas Wouters's message of "Fri, 12 Feb 2010 02:29:20 +0000")
Message-ID: <etd6363423q.fsf@biohazard-cafe.mit.edu>


Alex Coventry <throwaway at mit.edu> added the comment:

Ah, I guess I *was* on crack.  Thanks for the explanation.

----------

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

From report at bugs.python.org  Fri Feb 12 03:35:21 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Feb 2010 02:35:21 +0000
Subject: [issue7888] turtle "settiltangle" should be marked deprecated,
	not "tiltangle"
In-Reply-To: <1265674514.67.0.740398455539.issue7888@psf.upfronthosting.co.za>
Message-ID: <1265942121.33.0.507225644756.issue7888@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
priority:  -> normal
stage:  -> needs patch

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

From report at bugs.python.org  Fri Feb 12 03:58:49 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 12 Feb 2010 02:58:49 +0000
Subject: [issue7904] urlparse.urlsplit mishandles novel schemes
In-Reply-To: <1265844290.89.0.139975092944.issue7904@psf.upfronthosting.co.za>
Message-ID: <1265943529.97.0.834699277018.issue7904@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Hello Mark, 
Thanks for the patch.

However there are reasons why the check is:

"if scheme in uses_netloc and url[:2] == '//':"
It cannot be replaced by just url[:2] == '//' as in your patch.

Different protocols have different parsing requirements. (for e.g. some wish to consider (or act as if), after the scheme, the rest is their path)

The better way is to add 's3' to uses_netloc list and it should be fine too. I shall add it and include your tests. Thanks.

----------
components: +Library (Lib) -Extension Modules

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

From report at bugs.python.org  Fri Feb 12 09:41:33 2010
From: report at bugs.python.org (Oren Held)
Date: Fri, 12 Feb 2010 08:41:33 +0000
Subject: [issue7902] relative import broken
In-Reply-To: <1265828963.53.0.5315107426.issue7902@psf.upfronthosting.co.za>
Message-ID: <1265964093.53.0.1358786499.issue7902@psf.upfronthosting.co.za>


Changes by Oren Held <oren at held.org.il>:


----------
nosy: +Oren_Held

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

From report at bugs.python.org  Fri Feb 12 09:50:55 2010
From: report at bugs.python.org (Katrine Whiteson)
Date: Fri, 12 Feb 2010 08:50:55 +0000
Subject: [issue5651] OS X Installer: add checks to ensure proper Tcl
	configuration during build
In-Reply-To: <1238602612.52.0.800890790819.issue5651@psf.upfronthosting.co.za>
Message-ID: <1265964655.67.0.699342953228.issue5651@psf.upfronthosting.co.za>


Katrine Whiteson <katrinewhiteson at gmail.com> added the comment:

Hi,

I am having a related issue installing Tkinter (which I need to install matplotlib).

I am running Mac OS X 10.4.11, and just installed Python 2.6.4 .

After several other fights, one remaining battle for me to get matlotlib installed is to have a working version of Tkinter, although there are several in my Mac from Xcode and also Python, I guess they just aren't installed in useful places? After I installed Python 2.6.4, import _tkinter failed. So I installed Tcl 8.5 from active state.

Now, I make it to the Tkinter test:

            Tkinter._test() Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk/Tkinter.py", line 3746, in _test root = Tk() File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk/Tkinter.py", line 1645, in init self._loadtk() File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk/Tkinter.py", line 1659, in _loadtk % (_tkinter.TK_VERSION, tk_version) RuntimeError: tk.h version (8.4) doesn't match libtk.a version (8.5)

I realize you have discussed the exact error I am describing here: http://bugs.python.org/issue4017

but those errors arose from a problem with an earlier version of python, where setup.py reversed the order of where to look. The advice in your previous post is to fix this order in setup.py and rebuild python, but my setup.py is already looking good - it includes these lines:

def detect_tkinter_darwin(self, inc_dirs, lib_dirs): # The _tkinter module, using frameworks. Since frameworks are quite # different the UNIX search logic is not sharable. from os.path import join, exists framework_dirs = [ '/Library/Frameworks', '/System/Library/Frameworks/', join(os.getenv('HOME'), '/Library/Frameworks')

I would really appreciate any insight on how to handle this!( I am a biologist...)

While I'm at it, I'll include what is going on when I try to install m matplotlib in case it is useful...matplotlib thinks I have Tkinter 8.4 (ironically, only after I installed 8.5, before that it always said it could not find Tkinter):

Tkinter: Tkinter: 65971, Tk: 8.4, Tcl: 8.4

also, here is the error I run into when trying to build matplotlib:

powerpc-apple-darwin8-g++-4.0.1: unrecognized option '-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk' i686-apple-darwin8-g++-4.0.1: unrecognized option '-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk' /usr/bin/ld: -syslibroot: multiply specified collect2: ld returned 1 exit status /usr/bin/ld: -syslibroot: multiply specified collect2: ld returned 1 exit status lipo: can't open input file: /var/tmp//ccrblCgU.out (No such file or directory) error: command 'g++' failed with exit status 1 make: * [mpl_build] Error 1

thank you!!

Katrine

----------
nosy: +Katrine.Whiteson

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

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


Zsolt Cserna <zsolt.cserna at morganstanley.com> added the comment:

This issue doesn't seem to cause any problems in our production code, however I haven't tested it.

Btw what is the status of the solaris support? According to wiki page it should be supported by python, in real it seems it's not really supported (I mean not just this bug, but others related to solaris).

----------

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

From report at bugs.python.org  Fri Feb 12 11:32:32 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 12 Feb 2010 10:32:32 +0000
Subject: [issue5651] OS X Installer: add checks to ensure proper Tcl
	configuration during build
In-Reply-To: <1238602612.52.0.800890790819.issue5651@psf.upfronthosting.co.za>
Message-ID: <1265970752.27.0.894518571389.issue5651@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

If you have installed Python 2.6.4 using the python.org OS X installer, it was linked with Tk 8.4, and will not use Tk 8.5.  OS X 10.4 has an old version of Tk 8.4; your best bet is to install the most recent Tcl/Tk 8.4 from ActiveState Tcl/Tk.

----------

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

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: [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 11:53:14 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 12 Feb 2010 10:53:14 +0000
Subject: [issue7906] float("INFI") returns inf on certain platforms
In-Reply-To: <1265895632.82.0.0740289647812.issue7906@psf.upfronthosting.co.za>
Message-ID: <1265971994.88.0.663082082319.issue7906@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree that backporting the various parts needed to get this working would be risky and shouldn't be done.

As for Solaris sure, I'm not sure. You might ask on python-dev. I get the impression that few (if any) core developers have access to a Solaris machine.

----------

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

From report at bugs.python.org  Fri Feb 12 12:40:49 2010
From: report at bugs.python.org (Katrine Whiteson)
Date: Fri, 12 Feb 2010 11:40:49 +0000
Subject: [issue5651] OS X Installer: add checks to ensure proper Tcl
	configuration during build
In-Reply-To: <1265970752.27.0.894518571389.issue5651@psf.upfronthosting.co.za>
Message-ID: <1688FE1F-1544-4C92-B17F-C9DBBD37D742@gmail.com>


Katrine Whiteson <katrinewhiteson at gmail.com> added the comment:

Thanks very much for your helpful and quick reply!

I installed Tcl8.4 from activestate, and had the same version  
conflict error when I did the Tkinter test in Python. So I  
uninstalled both Tcl8.4 and Tcl8.5 (I did sudo ./uninstall while in  
this directory, the 8.4 and 8.5 versions:  /Library/Receipts/ 
ActiveTcl-8.4.pkg/Contents/Resources)

Then I reinstalled Tcl8.4 from active state, and now it still seems  
to look for Tcl8.5 when I say "import _tkinter" in Python:

katrine-whitesons-computer:/Applications/Q/matplotlib-0.99.1.1  
katrinewhiteson$ python
Python 2.6 (trunk:66714:66715M, Oct  1 2008, 18:36:04)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import _tkinter
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.6/ 
lib/python2.6/lib-dynload/_tkinter.so, 2): Library not loaded: / 
Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
   Referenced from: /Library/Frameworks/Python.framework/Versions/2.6/ 
lib/python2.6/lib-dynload/_tkinter.so
   Reason: image not found

____________________

I looked in /Library/Frameworks/Tcl.framework

and found 2 folders, "8.4" and "Current", the latter does not contain  
anything that says 8.5.

How can I get python to stop looking for 8.5?

thank you!
Katrine

On Feb 12, 2010, at 11:32 AM, Ned Deily wrote:

>
> Ned Deily <nad at acm.org> added the comment:
>
> If you have installed Python 2.6.4 using the python.org OS X  
> installer, it was linked with Tk 8.4, and will not use Tk 8.5.  OS  
> X 10.4 has an old version of Tk 8.4; your best bet is to install  
> the most recent Tcl/Tk 8.4 from ActiveState Tcl/Tk.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5651>
> _______________________________________

----------

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

From report at bugs.python.org  Fri Feb 12 12:58:43 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 12 Feb 2010 11:58:43 +0000
Subject: [issue7916] zipfile.ZipExtFile passes long to fileobj.read()
In-Reply-To: <1265971080.38.0.966459739534.issue7916@psf.upfronthosting.co.za>
Message-ID: <1265975923.31.0.515098059557.issue7916@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This was fixed with issue7249 and will be available with 2.6.5

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Feb 12 14:10:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 12 Feb 2010 13:10:51 +0000
Subject: [issue7906] float("INFI") returns inf on certain platforms
In-Reply-To: <1265895632.82.0.0740289647812.issue7906@psf.upfronthosting.co.za>
Message-ID: <1265980251.85.0.0994700481102.issue7906@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My feeling from watching bug reports is that Solaris is no less well supported than other non-linux, non-windows platforms.  When you look at the number of open Solaris bug reports, also consider the number of open bug reports over all.  We just don't have enough developer resources to close them all :(  And yes, developer access to appropriate test systems is one of the big issues.

If you have time to actively participate in resolving Solaris bugs by testing and proposing patches, my guess is you will get cooperation (and gratitude) from the dev team.

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> committed/rejected

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

From report at bugs.python.org  Fri Feb 12 14:41:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 12 Feb 2010 13:41:51 +0000
Subject: [issue7904] urlparse.urlsplit mishandles novel schemes
In-Reply-To: <1265844290.89.0.139975092944.issue7904@psf.upfronthosting.co.za>
Message-ID: <1265982111.42.0.887755928078.issue7904@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think Mark is correct.  RFC 3986 says:

When authority is present, the path must either be empty or begin with a slash ("/") character.  When authority is not present, the path cannot begin with two slash characters ("//").

I think it would make sense to have urlparse fall back to doing a generic RFC 3986 parse when it does not recognize the scheme.

----------
nosy: +r.david.murray
versions: +Python 3.1, Python 3.2

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

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: [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 15:52:33 2010
From: report at bugs.python.org (Andrew Chong)
Date: Fri, 12 Feb 2010 14:52:33 +0000
Subject: [issue7917] list of list created by *
In-Reply-To: <1265986353.37.0.770575922393.issue7917@psf.upfronthosting.co.za>
Message-ID: <1265986353.37.0.770575922393.issue7917@psf.upfronthosting.co.za>


New submission from Andrew Chong <sledge76 at hotmail.com>:

This shows unexpected behavior.

>>> data2 = [[]] * 4
>>> print data2
[[], [], [], []]
>>> data2[0] += [(0,1)]
>>> print data2
[[(0, 1)], [(0, 1)], [(0, 1)], [(0, 1)]]

I added a tuple to only 0th list, but it got added to all the lists in the global list.

----------
components: +None
type:  -> behavior

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

From report at bugs.python.org  Fri Feb 12 15:55:43 2010
From: report at bugs.python.org (Andrew Chong)
Date: Fri, 12 Feb 2010 14:55:43 +0000
Subject: [issue7917] list of list created by *
In-Reply-To: <1265986353.37.0.770575922393.issue7917@psf.upfronthosting.co.za>
Message-ID: <1265986543.75.0.446092652294.issue7917@psf.upfronthosting.co.za>


Andrew Chong <sledge76 at hotmail.com> added the comment:

But this works fine.

>>> data = []
>>> data += [[]]
>>> data += [[]]
>>> data += [[]]
>>> data += [[]]
>>> print data  
[[], [], [], []]
>>> data[0] += [(0,1)]
>>> print data        
[[(0, 1)], [], [], []]

----------

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

From report at bugs.python.org  Fri Feb 12 15:56:13 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 12 Feb 2010 14:56:13 +0000
Subject: [issue7917] list of list created by *
In-Reply-To: <1265986353.37.0.770575922393.issue7917@psf.upfronthosting.co.za>
Message-ID: <1265986573.34.0.543472938603.issue7917@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

It is by design.

Please read the documentation:
http://docs.python.org/library/stdtypes.html#sequence-types-str-unicode-list-tuple-buffer-xrange

----------
nosy: +flox
resolution:  -> invalid

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

From report at bugs.python.org  Fri Feb 12 15:56:24 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 12 Feb 2010 14:56:24 +0000
Subject: [issue7917] list of list created by *
In-Reply-To: <1265986353.37.0.770575922393.issue7917@psf.upfronthosting.co.za>
Message-ID: <1265986584.13.0.26925673233.issue7917@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
status: open -> closed

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

From report at bugs.python.org  Fri Feb 12 16:39:35 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 12 Feb 2010 15:39:35 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265989175.6.0.87989838811.issue7712@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Fixed on trunk with r78136.

Before closing this issue, we may apply additional cleanup on regrtest:
 - the "sys.path" hack is not needed anymore (no risk of relative imports)
 - the hack for sys.argv[0] could be removed too, and use __file__ instead

----------
Added file: http://bugs.python.org/file16218/issue7712_regrtest_remove_hacks.diff

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

From report at bugs.python.org  Fri Feb 12 16:44:11 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 12 Feb 2010 15:44:11 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265989451.83.0.174223313322.issue7712@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Removed file: http://bugs.python.org/file16218/issue7712_regrtest_remove_hacks.diff

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

From report at bugs.python.org  Fri Feb 12 16:45:10 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 12 Feb 2010 15:45:10 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1265989510.44.0.239236398785.issue7712@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


Added file: http://bugs.python.org/file16219/issue7712_regrtest_rm_hacks.diff

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

From report at bugs.python.org  Fri Feb 12 17:04:55 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 12 Feb 2010 16:04:55 +0000
Subject: [issue7805] test_multiprocessing failure
In-Reply-To: <1264773760.19.0.248393154087.issue7805@psf.upfronthosting.co.za>
Message-ID: <1265990695.99.0.3085749875.issue7805@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I can reproduce it almost always under these conditions:

System: Ubuntu Intrepid 64-bit, running on the actual hardware.
CPU: Core 2 Duo.
Load: At least one core maxed out by another process.

On an empty machine I haven't reproduced it yet.

----------
nosy: +skrah

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

From report at bugs.python.org  Fri Feb 12 17:08:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Feb 2010 16:08:41 +0000
Subject: [issue7805] test_multiprocessing failure
In-Reply-To: <1264773760.19.0.248393154087.issue7805@psf.upfronthosting.co.za>
Message-ID: <1265990921.51.0.507555472972.issue7805@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Indeed, I forgot to mention that the Debian Lenny install I reproduce the bug on is a single core (virtual) machine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7805>
_______________________________________

From report at bugs.python.org  Fri Feb 12 17:14:08 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 12 Feb 2010 16:14:08 +0000
Subject: [issue5651] OS X Installer: add checks to ensure proper Tcl
	configuration during build
In-Reply-To: <1238602612.52.0.800890790819.issue5651@psf.upfronthosting.co.za>
Message-ID: <1265991248.95.0.531807365349.issue5651@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Katherine: how did you install Python, did you use the installer on the python.org website or some other installer (or even by building from source)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5651>
_______________________________________

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: [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 18:30:41 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Fri, 12 Feb 2010 17:30:41 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1265995841.29.0.975753915672.issue7900@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

I don't see any issue here, runs perfectly fine on Mac OS X (Snow Leopard)

Shashwat-Anands-MacBook-Pro:test l0nwlf$ pwd
/Users/l0nwlf/python-svn/Lib/test
Shashwat-Anands-MacBook-Pro:test l0nwlf$ python2.7 test_posix.py
testNoArgFunctions (__main__.PosixTester) ... ok
test_access (__main__.PosixTester) ... ok
test_chdir (__main__.PosixTester) ... ok
test_chflags (__main__.PosixTester) ... ok
test_chown (__main__.PosixTester) ... ok
test_confstr (__main__.PosixTester) ... ok
test_dup (__main__.PosixTester) ... ok
test_dup2 (__main__.PosixTester) ... ok
test_fchown (__main__.PosixTester) ... ok
test_fdopen (__main__.PosixTester) ... ok
test_fstat (__main__.PosixTester) ... ok
test_fstatvfs (__main__.PosixTester) ... ok
test_ftruncate (__main__.PosixTester) ... ok
test_getcwd_long_pathnames (__main__.PosixTester) ... ok
test_initgroups (__main__.PosixTester) ... ok
test_lchflags (__main__.PosixTester) ... ok
test_lchown (__main__.PosixTester) ... ok
test_lsdir (__main__.PosixTester) ... ok
test_osexlock (__main__.PosixTester) ... ok
test_osshlock (__main__.PosixTester) ... ok
test_pipe (__main__.PosixTester) ... ok
test_stat (__main__.PosixTester) ... ok
test_statvfs (__main__.PosixTester) ... ok
test_strerror (__main__.PosixTester) ... ok
test_tempnam (__main__.PosixTester) ... ok
test_tmpfile (__main__.PosixTester) ... ok
test_umask (__main__.PosixTester) ... ok
test_utime (__main__.PosixTester) ... ok

----------------------------------------------------------------------
Ran 28 tests in 0.025s

OK

Shashwat-Anands-MacBook-Pro:test l0nwlf$ python2.7 --versionPython 2.7a3+
Shashwat-Anands-MacBook-Pro:test l0nwlf$ python2.7 
Python 2.7a3+ (trunk:78165, Feb 12 2010, 22:36:03) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import posix
>>> posix.getgroups()
[20, 204, 100, 98, 81, 80, 79, 61, 12, 402, 401]
>>>

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Fri Feb 12 18:44:06 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Fri, 12 Feb 2010 17:44:06 +0000
Subject: [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: <1265996646.56.0.457197490325.issue7909@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Seems fine to me, does not raise any errors. My OS is OS X Snow Leopard. I checked it in python 2.5, 2.6, 2.7 too, no issues raised.

Shashwat-Anands-MacBook-Pro:test l0nwlf$ python2.6
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 os,logging
>>> 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')
>>>

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7909>
_______________________________________

From report at bugs.python.org  Fri Feb 12 18:47:26 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 12 Feb 2010 17:47:26 +0000
Subject: [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: <1265996846.53.0.0618839074192.issue7909@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

>From the bug report, it look likes its specific to windows, not OS X.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7909>
_______________________________________

From report at bugs.python.org  Fri Feb 12 19:03:12 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 12 Feb 2010 18:03:12 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1265997792.78.0.296616192864.issue7900@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

What is the (Apple Inc. build 5646) (dot 1) vs normal (Apple Inc. build 5646). ?

While, ronald.oussoren did make a lot some changes recently (r78149 to r78152).This fix could have been a side-effect of one of it, thought I could not find the direct correlation.

----------
nosy: +orsenthil, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Fri Feb 12 19:11:37 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 12 Feb 2010 18:11:37 +0000
Subject: [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: <1265998297.84.0.436230815532.issue7909@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

nul is a special "dos device"
_getfullpathname() correctly returns \\.\nul, but normpath() then simplifies it to \\nul

I suggest that normpath() be changed to consider \\.\ as a special prefix, and keep it intact when it appears at the start of the path. See also
http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx

----------
keywords: +easy
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7909>
_______________________________________

From report at bugs.python.org  Fri Feb 12 19:29:54 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 12 Feb 2010 18:29:54 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1265999394.14.0.773389101259.issue7900@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I still see it on trunk (revision 78165). No idea what the (dot 1) means.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Fri Feb 12 19:44:55 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 12 Feb 2010 18:44:55 +0000
Subject: [issue5651] OS X Installer: add checks to ensure proper Tcl
	configuration during build
In-Reply-To: <1238602612.52.0.800890790819.issue5651@psf.upfronthosting.co.za>
Message-ID: <1266000295.27.0.47523713106.issue5651@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Ah, earlier you said you installed Python 2.6.4 but, in your most recent message, it shows:

katrinewhiteson$ python
Python 2.6 (trunk:66714:66715M, Oct  1 2008, 18:36:04)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin

I'm not sure what that is but it's not python 2.6.4 nor a python.org python nor an Apple-supplied python.  So chances are it was linked with Tk 10.5 present on the system.  Type:
which python
to find out where this one is installed and, if necessary, remove it and re-install a python, like from the python.org installer, that was linked with Tk 8.4.  You then should see something like this:

Python 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5651>
_______________________________________

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: [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 20:39:13 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 12 Feb 2010 19:39:13 +0000
Subject: [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: <1266003553.7.0.610263916001.issue7919@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

str->float conversions have been reworked in 2.7 and 3.1. The 'D' exponent will not on any platform starting with those versions.

So, this would be a non-platform specific feature request.

----------
assignee: ronaldoussoren -> 
components: +Interpreter Core -Macintosh
nosy: +eric.smith, mark.dickinson
versions: +Python 2.7, Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7919>
_______________________________________

From report at bugs.python.org  Fri Feb 12 20:49:50 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 12 Feb 2010 19:49:50 +0000
Subject: [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: <1266004190.99.0.126697638394.issue7919@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

That was supposed to say:

The 'D' exponent will not work on any platform starting with those versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7919>
_______________________________________

From report at bugs.python.org  Fri Feb 12 20:55:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 12 Feb 2010 19:55:09 +0000
Subject: [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: <1266004509.85.0.0868747742361.issue7919@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Out of curiosity, where are your data coming from?

For Python, this seems like a needless complication.  It should be simple enough to replace the 'D's with 'E's prior to passing the strings to float.

I notice that some varieties of Lisp and Scheme use 's', 'f', 'd', 'l' as the exponent marker for floats of different precisions (short, single, double, long double).  But Python only has one precision of float.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7919>
_______________________________________

From report at bugs.python.org  Fri Feb 12 21:05:26 2010
From: report at bugs.python.org (ricitron)
Date: Fri, 12 Feb 2010 20:05:26 +0000
Subject: [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: <1266005126.7.0.0546480853485.issue7919@psf.upfronthosting.co.za>


ricitron <ricitron at mac.com> added the comment:

I am running python 2.5.4. While it works on linux and windows, it does not work on mac. 

Fortran doubles are output using the D notation. If I am importing a large amount of data, I would rather not do a search and replace every time before reading in the data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7919>
_______________________________________

From report at bugs.python.org  Fri Feb 12 21:25:11 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 12 Feb 2010 20:25:11 +0000
Subject: [issue7505] ctypes not converting None to Null in 64-bit system
In-Reply-To: <1260810641.87.0.854694050504.issue7505@psf.upfronthosting.co.za>
Message-ID: <1266006311.51.0.236928010694.issue7505@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Confirm that 2.5 is the only troublesome version, but also when compiled from source (Ubuntu 64-bit, 2.5.5).

----------
nosy: +skrah
versions: +Python 2.5 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7505>
_______________________________________

From report at bugs.python.org  Fri Feb 12 21:46:19 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 12 Feb 2010 20:46:19 +0000
Subject: [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: <1266007579.59.0.390918469329.issue7919@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sorry, I'm -1 on this:  outside Fortran, using 'E' for the exponent marker seems to be near universal.  It just doesn't seem worth adding the extra complication to the Python code, or going through all the various places that expect an 'e' (float literals in Python source, inputs to the float function, Decimal and Fraction inputs, complex numbers, etc.) and trying to decide whether 'd' should be supported there too.

Even in Fortran, isn't it normal to output floats and doubles using the 'E' format specifier?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7919>
_______________________________________

From report at bugs.python.org  Fri Feb 12 21:49:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 12 Feb 2010 20:49:35 +0000
Subject: [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: <1266007775.86.0.6132159234.issue7919@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I would rather not do a search and replace every time before reading in > the data.

There's no need to do a search and replace *before* reading the data:  read the data first, then have Python do the replace for you before passing each string to float:

>>> t = string.maketrans('d', 'e')
>>> '-14.235d+03'.translate(t)
'-14.235e+03'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7919>
_______________________________________

From report at bugs.python.org  Fri Feb 12 22:11:52 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 12 Feb 2010 21:11:52 +0000
Subject: [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: <bf61017f-e68d-47e0-8626-12b54d4fb429@email.android.com>


Eric Smith <eric at trueblade.com> added the comment:

Unless and until we implement 'd' exponents, we should add a test to make sure they don't work. That they ever worked on any platform was a surprise. 
--
Eric.

----------
title: reading scientific notation using d instead of e on max osx -> reading scientific notation using d instead of e on max	osx

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7919>
_______________________________________

From report at bugs.python.org  Fri Feb 12 22:12:07 2010
From: report at bugs.python.org (mARK)
Date: Fri, 12 Feb 2010 21:12:07 +0000
Subject: [issue7904] urlparse.urlsplit mishandles novel schemes
In-Reply-To: <1265844290.89.0.139975092944.issue7904@psf.upfronthosting.co.za>
Message-ID: <1266009127.54.0.369427303757.issue7904@psf.upfronthosting.co.za>


mARK <python.mbloore at xoxy.net> added the comment:

The case which prompted this issue was a purely private set of URLs, sent to me by a client but never sent to Amazon or anywhere else outside our systems (though I'm sure many others have invented this particular scheme for their own use).  It would have been convenient if urlparse had handled it properly.  That is true for any scheme one may invent at need.

On second thought it does make sense to enforce the use of :// for the schemes in uses_netloc, but still not to ignore its meaning for other schemes.  It also makes sense to add s3 to uses_netloc despite the fact that it is not (afaik) registered, since it is an obvious invention.

I'll make another patch, but I don't have time to do it just now.

----------
components: +Extension Modules -Library (Lib)
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7904>
_______________________________________

From report at bugs.python.org  Fri Feb 12 22:13:58 2010
From: report at bugs.python.org (mARK)
Date: Fri, 12 Feb 2010 21:13:58 +0000
Subject: [issue7904] urlparse.urlsplit mishandles novel schemes
In-Reply-To: <1265844290.89.0.139975092944.issue7904@psf.upfronthosting.co.za>
Message-ID: <1266009238.98.0.802466822128.issue7904@psf.upfronthosting.co.za>


Changes by mARK <python.mbloore at xoxy.net>:


----------
components: +Library (Lib) -Extension Modules
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7904>
_______________________________________

From report at bugs.python.org  Fri Feb 12 22:19:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 12 Feb 2010 21:19:09 +0000
Subject: [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: <1266009549.08.0.158847495271.issue7919@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Done in r78166 (trunk), r78167 (py3k).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7919>
_______________________________________

From report at bugs.python.org  Fri Feb 12 22:44:45 2010
From: report at bugs.python.org (Andres Riancho)
Date: Fri, 12 Feb 2010 21:44:45 +0000
Subject: [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: [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 00:02:43 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Fri, 12 Feb 2010 23:02:43 +0000
Subject: [issue7920] urllib2.HTTPRedirectHandler incorrect redirect
In-Reply-To: <1266011084.83.0.0326673543999.issue7920@psf.upfronthosting.co.za>
Message-ID: <1266015763.37.0.956890968201.issue7920@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

In Python 2.7a3+, trunk:78165 the code is as follows: (note that there is a segment of code to fix malformed URLs)

"""
        if 'location' in headers:
            newurl = headers.getheaders('location')[0]
        elif 'uri' in headers:
            newurl = headers.getheaders('uri')[0]
        else:
            return

        # fix a possible malformed URL
        urlparts = urlparse.urlparse(newurl)
        if not urlparts.path:
            urlparts = list(urlparts)
            urlparts[2] = "/"
        newurl = urlparse.urlunparse(urlparts)

        newurl = urlparse.urljoin(req.get_full_url(), newurl)

"""

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7920>
_______________________________________

From report at bugs.python.org  Sat Feb 13 00:37:18 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Feb 2010 23:37:18 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1266017838.45.0.667110341124.issue7712@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'm not sure it's safe to remove those hacks, they might be necessary in some corner case.
I'll also port this to py3k before closing the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7712>
_______________________________________

From report at bugs.python.org  Sat Feb 13 02:29:02 2010
From: report at bugs.python.org (Meador Inge)
Date: Sat, 13 Feb 2010 01:29:02 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1266024542.01.0.267310083137.issue3132@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Is anyone working on implementing these new struct modifiers?  If not, then I would love to take a shot at it.

----------
nosy: +minge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Sat Feb 13 02:35:15 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Feb 2010 01:35:15 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1266024542.01.0.267310083137.issue3132@psf.upfronthosting.co.za>
Message-ID: <1afaf6161002121735v60a2111bv9b5a866062ea5e8f@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/2/12 Meador Inge <report at bugs.python.org>:
>
> Meador Inge <meadori at gmail.com> added the comment:
>
> Is anyone working on implementing these new struct modifiers? ?If not, then I would love to take a shot at it.

Not to my knowledge.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Sat Feb 13 02:56:57 2010
From: report at bugs.python.org (mike bayer)
Date: Sat, 13 Feb 2010 01:56:57 +0000
Subject: [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 03:01:30 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Feb 2010 02:01:30 +0000
Subject: [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: <1266026490.52.0.569143151217.issue7922@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Please try 2to3 from 2.7a3 or the 2to3 trunk.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7922>
_______________________________________

From report at bugs.python.org  Sat Feb 13 03:02:03 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Feb 2010 02:02:03 +0000
Subject: [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: <1266026523.02.0.921012142621.issue7922@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Sorry, I meant from the py3k branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7922>
_______________________________________

From report at bugs.python.org  Sat Feb 13 03:14:15 2010
From: report at bugs.python.org (mike bayer)
Date: Sat, 13 Feb 2010 02:14:15 +0000
Subject: [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: <1266027255.39.0.740066265377.issue7922@psf.upfronthosting.co.za>


mike bayer <mike_mp at zzzcomputing.com> added the comment:

yes, its handled:

WARNING: couldn't encode test.py's diff for your terminal

is that fix specific to 2to3 or is that just how "print" works in 3.2 ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7922>
_______________________________________

From report at bugs.python.org  Sat Feb 13 03:19:15 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Feb 2010 02:19:15 +0000
Subject: [issue7922] Python 3's 2to3 does not handle non-ascii source files
In-Reply-To: <1266027255.39.0.740066265377.issue7922@psf.upfronthosting.co.za>
Message-ID: <1afaf6161002121819h53e10a03u71688eea3a20f17a@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/2/12 mike bayer <report at bugs.python.org>:
>
> mike bayer <mike_mp at zzzcomputing.com> added the comment:
>
> yes, its handled:
>
> WARNING: couldn't encode test.py's diff for your terminal
>
> is that fix specific to 2to3 or is that just how "print" works in 3.2 ?

It's just that whatever python guesses your terminal encoding is (try
print(sys.stdin.encoding)) might not be able to handle whatever
characters are in the source file, so we just don't print it. You can
change the default encoding with the PYTHONIOENCODING env var.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7922>
_______________________________________

From report at bugs.python.org  Sat Feb 13 03:19:53 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Feb 2010 02:19:53 +0000
Subject: [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: <1266027593.46.0.839153693921.issue7922@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7922>
_______________________________________

From report at bugs.python.org  Sat Feb 13 03:20:38 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Feb 2010 02:20:38 +0000
Subject: [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: <1266027638.91.0.783373224544.issue7922@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

You can just use the --no-diffs option, btw, to avoid this problem on earlier versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7922>
_______________________________________

From report at bugs.python.org  Sat Feb 13 04:26:22 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 13 Feb 2010 03:26:22 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266031582.44.0.00342019101912.issue7900@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

It seems they are basically the same thing, the version of GCC and the build of OS X(latest in the case here). Was not able to figure out the (dot 1) stuff though.

----------
nosy:  -loewis, michael.foord, orsenthil, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Sat Feb 13 04:54:15 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 13 Feb 2010 03:54:15 +0000
Subject: [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: <1266033255.59.0.99641652427.issue7919@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'm -1 on this, too. Closing.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7919>
_______________________________________

From report at bugs.python.org  Sat Feb 13 04:54:20 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 13 Feb 2010 03:54:20 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266033260.54.0.377888068352.issue7900@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

please not remove the nosy list. ( I guess, you did it by accident).
let's wait for ronald's response.

----------
nosy: +loewis, michael.foord, orsenthil, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Sat Feb 13 05:30:24 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 13 Feb 2010 04:30:24 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266035424.93.0.912248084495.issue7900@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

Thanks for correcting it back. I did not even realized it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Sat Feb 13 05:31:58 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 13 Feb 2010 04:31:58 +0000
Subject: [issue7921] Some sqlite3 Connection methods point to themselves
In-Reply-To: <1266013165.58.0.187332799456.issue7921@psf.upfronthosting.co.za>
Message-ID: <1266035518.32.0.970548780217.issue7921@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Here's a patch which corrects executemany, along with execute and executescript. An explicit title is used, with a reference to the underlying Cursor methods.

----------
keywords: +needs review, patch
nosy: +brian.curtin
priority:  -> low
stage:  -> patch review
title: executemany() link in Connection.executemany should point to Cursor.executemany -> Some sqlite3 Connection methods point to themselves
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file16220/issue7921.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7921>
_______________________________________

From report at bugs.python.org  Sat Feb 13 05:33:37 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 13 Feb 2010 04:33:37 +0000
Subject: [issue7920] urllib2.HTTPRedirectHandler incorrect redirect
In-Reply-To: <1266011084.83.0.0326673543999.issue7920@psf.upfronthosting.co.za>
Message-ID: <1266035617.97.0.478310440858.issue7920@psf.upfronthosting.co.za>


Changes by Shashwat Anand <anand.shashwat at gmail.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7920>
_______________________________________

From report at bugs.python.org  Sat Feb 13 07:06:34 2010
From: report at bugs.python.org (Travis Oliphant)
Date: Sat, 13 Feb 2010 06:06:34 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1266024542.01.0.267310083137.issue3132@psf.upfronthosting.co.za>
Message-ID: <00E3606B-6974-40D0-AA1A-CC1D83C9013E@enthought.com>


Travis Oliphant <oliphant at enthought.com> added the comment:

On Feb 12, 2010, at 7:29 PM, Meador Inge wrote:

>
> Meador Inge <meadori at gmail.com> added the comment:
>
> Is anyone working on implementing these new struct modifiers?  If  
> not, then I would love to take a shot at it.

That would be great.

-Travis

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Sat Feb 13 08:22:04 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Sat, 13 Feb 2010 07:22:04 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266045724.59.0.466609700008.issue7900@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

5646 and 5646.1 are the builds of GCC by Apple. The various builds of gcc are present on http://www.opensource.apple.com/source/gcc/ 

[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin -> http://www.opensource.apple.com/source/gcc/gcc-5646.1/

[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
 -> http://www.opensource.apple.com/source/gcc/gcc-5646/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Sat Feb 13 11:59:26 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Feb 2010 10:59:26 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1266058766.33.0.234188110934.issue7712@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

"Complex is better than complicated... Special cases aren't special enough to break the rules."

The module "regrtest" is complex enough. We don't need to keep useless hacks inside.
It would be more interesting to replace the hack with some words, or an assertion, and understand the real (or hypothetic) issue behind this hack.

Eventually, if we keep these hacks around, it may hide real bugs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7712>
_______________________________________

From report at bugs.python.org  Sat Feb 13 12:07:54 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Feb 2010 11:07:54 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1266059274.29.0.344917421658.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Some of the proposed struct module additions look far from straightforward;  I find that section of the PEP significantly lacking in details and motivation.

"Unpacking a long-double will return a decimal object or a ctypes long-double."

Returning a Decimal object here doesn't make a lot of sense, since Decimal objects aren't generally compatible with floats.  And ctypes long double objects don't seem to exist, as far as I can tell.  It might be better not to add this code.

Another bit that's not clear to me:  how is unpacking an object pointer expected to work, and how would it typically be used?  What if the unpacked pointer no longer points to a valid Python object?  How would this work in other Python implementations?

For the 'X{}' format (pointer to a function), is this supposed to mean a Python function or a C function?

What's a 'specific pointer'?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Sat Feb 13 13:02:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Feb 2010 12:02:36 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1266062556.57.0.871107502925.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Whoops.  ctypes does have long double, of course.  Apologies.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Sat Feb 13 13:18:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Feb 2010 12:18:39 +0000
Subject: [issue1023290] Conversion of longs to bytes and vice-versa.
Message-ID: <1266063519.83.0.802366371517.issue1023290@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

A couple of questions for the backport:

(1) should the 'signed' parameter remain keyword-only in 2.7?  I'd say yes, to avoid issues when forward-porting code from 2.7 to 3.2.  On the other hand, 2.7 doesn't support keyword-only arguments at the Python level, so a keyword-only argument might be a bit of a surprise to users.

(2) When specifying the byteorder, is there a need to allow u'big' and u'little' as well as 'big' and 'little'?

----------
priority: low -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1023290>
_______________________________________

From report at bugs.python.org  Sat Feb 13 14:23:31 2010
From: report at bugs.python.org (Santhosh Thottingal)
Date: Sat, 13 Feb 2010 13:23:31 +0000
Subject: [issue6895] locale._parse_localename fails when localename does not
	contain encoding information
In-Reply-To: <1252765618.77.0.920082811868.issue6895@psf.upfronthosting.co.za>
Message-ID: <1266067411.49.0.422529857957.issue6895@psf.upfronthosting.co.za>


Santhosh Thottingal <santhosh.thottingal at gmail.com> added the comment:

I see that the ml_IN added to locale.alias of X.org. 
lemburg, Do you think that my patch is still required as a fallback solution in case xx_YY mapping not found in locale.alias? 
If you can confirm that it is not required, we can close this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6895>
_______________________________________

From report at bugs.python.org  Sat Feb 13 14:36:16 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 13 Feb 2010 13:36:16 +0000
Subject: [issue5125] Strange locale problem with Python 3
In-Reply-To: <1233517710.32.0.869509955584.issue5125@psf.upfronthosting.co.za>
Message-ID: <1266068176.39.0.00457464183307.issue5125@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

As an aside, I would not use atof(). Better use something like:

char *end;

f = strtod(input, &end);
if (*end != '\0') {
    PyErr_Format(PyExc_ValueError, "Could not convert: %s", end);
    return NULL;
}


I've two questions:

1) Does the problem still appear in Python3.1 or Python3.2?

2) What is the output of:
>>> import locale
>>> locale.setlocale(locale.LC_ALL)

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5125>
_______________________________________

From report at bugs.python.org  Sat Feb 13 15:06:58 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 13 Feb 2010 14:06:58 +0000
Subject: [issue7442] _localemodule.c: str2uni() with different LC_NUMERIC and
	LC_CTYPE
In-Reply-To: <1260009859.57.0.721297634888.issue7442@psf.upfronthosting.co.za>
Message-ID: <1266070018.52.0.804549911142.issue7442@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I have a patch that fixes this specific issue. Probably there are similar
issues in other places, e.g. when LC_TIME and LC_CTYPE differ.

I suspect that this is related:

http://bugs.python.org/issue5905

----------
keywords: +patch
Added file: http://bugs.python.org/file16221/set_ctype_before_mbstowcs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7442>
_______________________________________

From report at bugs.python.org  Sat Feb 13 15:44:13 2010
From: report at bugs.python.org (Andres Riancho)
Date: Sat, 13 Feb 2010 14:44:13 +0000
Subject: [issue7920] urllib2.HTTPRedirectHandler incorrect redirect
In-Reply-To: <1266011084.83.0.0326673543999.issue7920@psf.upfronthosting.co.za>
Message-ID: <1266072253.23.0.428361925734.issue7920@psf.upfronthosting.co.za>


Andres Riancho <andresriancho at users.sourceforge.net> added the comment:

The problem is still there in 2.7:

>>> urlparts = urlparse.urlparse('C:\\boot.ini')
>>> urlparts
('c', '', '\\boot.ini', '', '', '')
>>> if not urlparts.path:
...     urlparts = list(urlparts)
...     urlparts[2] = "/"
... 
>>> urlparts
('c', '', '\\boot.ini', '', '', '')
>>> newurl = urlparse.urlunparse(urlparts)
>>> newurl
'c:\\boot.ini'
>>> newurl = urlparse.urljoin( 'http://host.tld/spam/eggs.py', newurl)
>>> newurl
'c:\\boot.ini'
>>>

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7920>
_______________________________________

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: [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 16:57:38 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Feb 2010 15:57:38 +0000
Subject: [issue3475] _elementtree.c import can fail silently
In-Reply-To: <1217488390.82.0.966024621847.issue3475@psf.upfronthosting.co.za>
Message-ID: <1266076658.15.0.936193974178.issue3475@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
dependencies: +Update ElementTree with upstream changes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3475>
_______________________________________

From report at bugs.python.org  Sat Feb 13 16:58:39 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 13 Feb 2010 15:58:39 +0000
Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
In-Reply-To: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za>
Message-ID: <1266076719.62.0.611729991834.issue1745@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Mark Dickinson added the comment:
> (1) should the 'signed' parameter remain keyword-only in 2.7?

We should keep it as a keyword-only argument.  Also, issue #1745 might bring keyword-only arguments to 2.7.

> (2) When specifying the byteorder, is there a need to allow u'big' and
> u'little' as well as 'big' and 'little'?

Allow both. Since, 'big' == u'big' is True, it would be weird to treat them differently in this case.

Plus, it will make life easier for people who uses:

  from __future__ import unicode_literals

in their code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745>
_______________________________________

From report at bugs.python.org  Sat Feb 13 17:01:18 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Feb 2010 16:01:18 +0000
Subject: [issue1538691] Patch cElementTree to export CurrentLineNumber
Message-ID: <1266076878.59.0.764343219716.issue1538691@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
dependencies: +Update ElementTree with upstream changes
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1538691>
_______________________________________

From report at bugs.python.org  Sat Feb 13 17:04:40 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Feb 2010 16:04:40 +0000
Subject: [issue3475] _elementtree.c import can fail silently
In-Reply-To: <1217488390.82.0.966024621847.issue3475@psf.upfronthosting.co.za>
Message-ID: <1266077080.74.0.87575808184.issue3475@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
nosy: +flox
priority:  -> normal
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3475>
_______________________________________

From report at bugs.python.org  Sat Feb 13 17:05:16 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Feb 2010 16:05:16 +0000
Subject: [issue1538691] Patch cElementTree to export CurrentLineNumber
Message-ID: <1266077116.89.0.166474400371.issue1538691@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1538691>
_______________________________________

From report at bugs.python.org  Sat Feb 13 18:25:36 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 13 Feb 2010 17:25:36 +0000
Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
In-Reply-To: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za>
Message-ID: <1266081936.89.0.0653466205747.issue1745@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745>
_______________________________________

From report at bugs.python.org  Sat Feb 13 18:28:29 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 13 Feb 2010 17:28:29 +0000
Subject: [issue1023290] Conversion of longs to bytes and vice-versa.
Message-ID: <1266082109.53.0.962989982682.issue1023290@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Mark Dickinson added the comment:
> (1) should the 'signed' parameter remain keyword-only in 2.7?

We should keep it as a keyword-only argument.  Also, issue #1745 might bring keyword-only arguments to 2.7.

> (2) When specifying the byteorder, is there a need to allow u'big' and
> u'little' as well as 'big' and 'little'?

Allow both. Since, 'big' == u'big' is True, it would be weird to treat them differently in this case.

Plus, it will make life easier for people who uses:

  from __future__ import unicode_literals

in their code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1023290>
_______________________________________

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: [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:30:09 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Feb 2010 17:30:09 +0000
Subject: [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: <1266082209.8.0.460571285306.issue7924@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
components: +Tests

_______________________________________
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: [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  Sat Feb 13 18:54:48 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Feb 2010 17:54:48 +0000
Subject: [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: <1266083688.54.0.727936726713.issue7924@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The behaviour is weird.
Use attached patch to reproduce this behaviour.

 ~ $ ./python -m test.regrtest -uall test_curses test_datetime
test_curses
test_curses skipped -- No module named _NO_curses
test_datetime
1 test OK.
1 test skipped:
    test_curses
Those skips are all expected on linux2.

 ~ $ ./python -m test.regrtest -uall test_capi
test_capi
test test_capi crashed -- <class 'ImportError'>: No module named _NO_curses
1 test failed:
    test_capi

 ~ $ ./python -m test.regrtest -uall test_datetime test_capi
test_datetime
test_capi
All 2 tests OK.

 ~ $ ./python -m test.regrtest -uall test_curses test_capi
test_curses
test_curses skipped -- No module named _NO_curses
test_capi
XXX undetected error
test test_capi crashed -- <class 'ImportError'>: No module named datetime
1 test failed:
    test_capi
1 test skipped:
    test_curses
Those skips are all expected on linux2.

Now, we need to identify the culprit: Modules/_testcapimodule.c or Objects/capsule.c ...

----------
keywords: +patch
nosy: +larry
Added file: http://bugs.python.org/file16222/issue7924_test_case.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7924>
_______________________________________

From report at bugs.python.org  Sat Feb 13 19:01:05 2010
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 13 Feb 2010 18:01:05 +0000
Subject: [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: <1266084065.47.0.601826252546.issue7924@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

"To reproduce: add a typo on "_curses" on line 1666."

Of what file?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7924>
_______________________________________

From report at bugs.python.org  Sat Feb 13 19:18:54 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Feb 2010 18:18:54 +0000
Subject: [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: <1266085134.01.0.414227784743.issue7924@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The simple fix:

--- Modules/_testcapimodule.c   (revision 78171)
+++ Modules/_testcapimodule.c   (working copy)
@@ -1763,6 +1763,8 @@
                        Py_DECREF(object);
                        Py_DECREF(module);
                }
+               else
+                       PyErr_Clear();
        }
 
   exit:

(we don't want to fail if optional "_curses" is not built)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7924>
_______________________________________

From report at bugs.python.org  Sat Feb 13 19:19:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Feb 2010 18:19:20 +0000
Subject: [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: <1266085160.38.0.125199806922.issue7924@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7924>
_______________________________________

From report at bugs.python.org  Sat Feb 13 19:30:17 2010
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 13 Feb 2010 18:30:17 +0000
Subject: [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: <1266085817.34.0.577272570133.issue7924@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Patch to make testcapsule clear import errors when testing.  Sorry about the whitespace changes, but I outdented a bunch of code--I think it's clearer this way.

----------
Added file: http://bugs.python.org/file16223/lch.patch.trunk.py3k.r78149

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7924>
_______________________________________

From report at bugs.python.org  Sat Feb 13 19:45:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Feb 2010 18:45:34 +0000
Subject: [issue1023290] Conversion of longs to bytes and vice-versa.
Message-ID: <1266086734.25.0.566767532739.issue1023290@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks, Alexandre!  Agreed on both points.  I don't really want to allow u'big' and u'little', but I think that's just my laziness talking.  (Apart from that, I have a working patch.)

There's some precedent for not allowing the unicode versions:

>>> float.__getformat__("double")
'IEEE, little-endian'
>>> float.__getformat__(u"double")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __getformat__() argument must be string, not unicode

But I admit it isn't particularly compelling.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1023290>
_______________________________________

From report at bugs.python.org  Sat Feb 13 19:47:16 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Feb 2010 18:47:16 +0000
Subject: [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: <1266086836.74.0.499838015058.issue7925@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
priority:  -> normal
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7925>
_______________________________________

From report at bugs.python.org  Sat Feb 13 19:47:38 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Feb 2010 18:47:38 +0000
Subject: [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: <1266086858.43.0.965115847312.issue7925@psf.upfronthosting.co.za>


Changes by Florent Xicluna <laxyf at yahoo.fr>:


----------
stage: needs patch -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7925>
_______________________________________

From report at bugs.python.org  Sat Feb 13 19:50:14 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Feb 2010 18:50:14 +0000
Subject: [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: <1266087014.22.0.669206261444.issue7924@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks both of you for (finally) tracking this down!

I've applied flox's quick fix in r78172, and reverted the old attempted fix in r78173.  Both merged to py3k in r78174.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7924>
_______________________________________

From report at bugs.python.org  Sat Feb 13 21:45:17 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Feb 2010 20:45:17 +0000
Subject: [issue5125] Strange locale problem with Python 3
In-Reply-To: <1233517710.32.0.869509955584.issue5125@psf.upfronthosting.co.za>
Message-ID: <1266093917.16.0.740603648164.issue5125@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Actually, for Python 3.x, rather than using strtod directly it would be better to use the PyOS_string_to_double C-API function.  That function is entirely locale-agnostic:  it should behave identically to the float constructor.

Python 3.0 is no longer supported:  it would be good to know whether this problem persists with Python 3.1 or the py3k svn branch.

----------
nosy: +mark.dickinson
versions: +Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5125>
_______________________________________

From report at bugs.python.org  Sat Feb 13 21:46:55 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 13 Feb 2010 20:46:55 +0000
Subject: [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: <1266094015.33.0.284580336152.issue7925@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Please provide some test data, and describe which behavior you expect.

----------
components: +XML -Library (Lib)
nosy: +flox
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7925>
_______________________________________

From report at bugs.python.org  Sat Feb 13 23:53:48 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Feb 2010 22:53:48 +0000
Subject: [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: <1266101628.13.0.508476080971.issue7923@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee: georg.brandl -> vinay.sajip
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7923>
_______________________________________

From report at bugs.python.org  Sun Feb 14 00:08:24 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 13 Feb 2010 23:08:24 +0000
Subject: [issue7826] support caching for 2to3
In-Reply-To: <1265936760.18.0.108729470992.issue7826@psf.upfronthosting.co.za>
Message-ID: <1afaf6161002131505j5f63debeyd0cfe34c16e40979@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/2/11 Brian Harring <report at bugs.python.org>:
>
> Brian Harring <ferringb at gmail.com> added the comment:
>
> @benjamin:
>
> Tests can be written; the reason this patch doesn't bundle tests up front is that I wasn't going to burn the time till I knew they were needed since I expected the concept to require some debate.
>
> As for the hacks angle, there isn't anything hackish there- hackish is what you have to do w/out either of these patches (http://www.pkgcore.org/trac/pkgcore/browser/snakeoil/snakeoil/caching_2to3.py). ?I understand not everyone likes classes mixed on the fly, but it's a perfectly valid technique w/ many, many valid uses.

While it may be a valid pattern, I still think there are more elegant solutions.

>
> Converting the innards of 2to3 over to a generalized plugin interface frankly is overkill from where I'm standing- being able to plugin new fixers is one thing (very useful in my opinion but orthogonal to what this ticke tis about), being able to plugin on the fly different refactoring outputers is another thing.

I plan to work on this this spring or summer if I have time.

>
> Personally what's in place w/in allow_alternate_output_tools.patch is more than enough for the crazy ideas I've got kicking around.
>
> If you've got a specific complaint in the patch, an area that is dodgy/hacky, state it please- I'm more than open to actionable criticisms.

I think delegation would be more appropriate than adding mixin classes
at runtime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7826>
_______________________________________

From report at bugs.python.org  Sun Feb 14 03:57:54 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Feb 2010 02:57:54 +0000
Subject: [issue7921] Some sqlite3 Connection methods point to themselves
In-Reply-To: <1266013165.58.0.187332799456.issue7921@psf.upfronthosting.co.za>
Message-ID: <1266116274.19.0.764976893493.issue7921@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r78176 (trunk), r78177 (release26-maint), r78178 (py3k) and r78179 (release31-maint), thanks for the report and the patch!

----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7921>
_______________________________________

From report at bugs.python.org  Sun Feb 14 04:14:08 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Feb 2010 03:14:08 +0000
Subject: [issue7888] turtle "settiltangle" should be marked deprecated,
	not "tiltangle"
In-Reply-To: <1265674514.67.0.740398455539.issue7888@psf.upfronthosting.co.za>
Message-ID: <1266117248.6.0.628906619304.issue7888@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r78180 (py3k) and r78181 (release31-maint), thanks for the report!

----------
assignee: georg.brandl -> ezio.melotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7888>
_______________________________________

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: [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 08:44:58 2010
From: report at bugs.python.org (Braden McDaniel)
Date: Sun, 14 Feb 2010 07:44:58 +0000
Subject: [issue6820] Redefinition of HAVE_STRFTIME can cause compiler errors.
In-Reply-To: <1251884386.05.0.339554390546.issue6820@psf.upfronthosting.co.za>
Message-ID: <1266133498.83.0.159404818097.issue6820@psf.upfronthosting.co.za>


Braden McDaniel <braden at endoframe.com> added the comment:

In general, this does *not* play well with libraries that define the same symbols.

It is not correct to install the AC_CONFIG_HEADERS. Any macros in an installed configuration header need to be namespaced per-project; e.g., PYTHON_HAVE_STRFTIME.

----------
nosy: +braden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6820>
_______________________________________

From report at bugs.python.org  Sun Feb 14 09:19:49 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 14 Feb 2010 08:19:49 +0000
Subject: [issue7926] Stray parentheses() in context manager "what's new" doc
In-Reply-To: <1266130394.53.0.910004543029.issue7926@psf.upfronthosting.co.za>
Message-ID: <1266135589.01.0.636225040858.issue7926@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r78182.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
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: [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: [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  Sun Feb 14 12:49:17 2010
From: report at bugs.python.org (Edward Welbourne)
Date: Sun, 14 Feb 2010 11:49:17 +0000
Subject: [issue7926] Stray parentheses() in context manager "what's new" doc
In-Reply-To: <1266130394.53.0.910004543029.issue7926@psf.upfronthosting.co.za>
Message-ID: <1266148157.26.0.130989971598.issue7926@psf.upfronthosting.co.za>


Edward Welbourne <eddy at chaos.org.uk> added the comment:

The third change removes the early uses of "object" from:
<quote> Finally, the closing(object)() function returns object so that it can be bound to a variable, and calls object.close at the end of the block. </quote>
leaving the last use (object.close) as a dangling reference.
So either revert this part of the fix and change :func:`closing(object)` to just ``closing(object)`` or follow up the present change by changing <quote> and calls :meth `object.close` at the end </quote> to <q> and calls the argument's :meth:`close` method at the end </q>

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7926>
_______________________________________

From report at bugs.python.org  Sun Feb 14 14:08:30 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 14 Feb 2010 13:08:30 +0000
Subject: [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: <1266152910.03.0.799346163776.issue7923@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

These changes have already been made in trunk (see r68624, r76869), just not backported to release26-maint.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7923>
_______________________________________

From report at bugs.python.org  Sun Feb 14 14:16:41 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 14 Feb 2010 13:16:41 +0000
Subject: [issue7928] String formatting: grammar wrongly limits [index] to
	integer
In-Reply-To: <1266146946.63.0.7361643831.issue7928@psf.upfronthosting.co.za>
Message-ID: <1266153401.08.0.402935615459.issue7928@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> eric.smith
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7928>
_______________________________________

From report at bugs.python.org  Sun Feb 14 14:39:28 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 14 Feb 2010 13:39:28 +0000
Subject: [issue7926] Stray parentheses() in context manager "what's new" doc
In-Reply-To: <1266130394.53.0.910004543029.issue7926@psf.upfronthosting.co.za>
Message-ID: <1266154768.14.0.52235578401.issue7926@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, should be fine now in r78188.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7926>
_______________________________________

From report at bugs.python.org  Sun Feb 14 15:15:13 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 14 Feb 2010 14:15:13 +0000
Subject: [issue7788] segfault when deleting from a list using slice with very
	big `step' value
In-Reply-To: <1264531632.85.0.040390960633.issue7788@psf.upfronthosting.co.za>
Message-ID: <1266156913.6.0.635355381307.issue7788@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Yes, adding carefully placed (size_t) casts seems like the right way to solve the problem.

I've fixed all (I think) the warnings in r78183, r78184, r78189.  I also fixed one case (unrelated to this issue) of potential undefined behaviour from signed overflow.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7788>
_______________________________________

From report at bugs.python.org  Sun Feb 14 16:25:52 2010
From: report at bugs.python.org (Edward Welbourne)
Date: Sun, 14 Feb 2010 15:25:52 +0000
Subject: [issue7926] Stray parentheses() in context manager "what's new" doc
In-Reply-To: <1266130394.53.0.910004543029.issue7926@psf.upfronthosting.co.za>
Message-ID: <1266161152.6.0.669842404443.issue7926@psf.upfronthosting.co.za>


Edward Welbourne <eddy at chaos.org.uk> added the comment:

Nice :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7926>
_______________________________________

From report at bugs.python.org  Sun Feb 14 23:32:59 2010
From: report at bugs.python.org (Katrine Whiteson)
Date: Sun, 14 Feb 2010 22:32:59 +0000
Subject: [issue5651] OS X Installer: add checks to ensure proper Tcl
	configuration during build
In-Reply-To: <1266000295.27.0.47523713106.issue5651@psf.upfronthosting.co.za>
Message-ID: <BB7E4006-7108-4DF4-8B5E-D8966CB6C325@gmail.com>


Katrine Whiteson <katrinewhiteson at gmail.com> added the comment:

Hi,

Wow, thank you for noticing this. I tried to install python 2.6.4  
with the mac dmg, but couldn't figure out where it was installed.  I  
hunted around and made a link to a python 2.6 that I found - it must  
have been a previous version.

Now I have a fresh and successful python 2.6.4 install, Tkinter test  
works, and so I should be set.

I am still having trouble building matplotlib. Apparently my  
syslibroot is multiply specified. (I installed Xcode 2.2.1 from the  
mac developer site recently, by the way...). If you understand this,  
I would really appreciate any insight you have (I am attaching the  
output from when I try to build matplotlib).

thank you!!
Katrine

python2.6 setup.py build
======================================================================== 
====
BUILDING MATPLOTLIB
             matplotlib: 0.99.1.1
                 python: 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32)   
[GCC
                         4.0.1 (Apple Inc. build 5493)]
               platform: darwin

REQUIRED DEPENDENCIES
                  numpy: 1.3.0
              freetype2: found, but unknown version (no pkg-config)
                         * WARNING: Could not find 'freetype2'  
headers in any
                         * of '.', './freetype2'.

OPTIONAL BACKEND DEPENDENCIES
                 libpng: found, but unknown version (no pkg-config)
                         * Could not find 'libpng' headers in any of '.'
                Tkinter: Tkinter: 73770, Tk: 8.4, Tcl: 8.4
               wxPython: no
                         * wxPython not found
                   Gtk+: no
                         * Building for Gtk+ requires pygtk; you must  
be able
                         * to "import gtk" in your build/install  
environment
        Mac OS X native: yes
                     Qt: no
                    Qt4: no
                  Cairo: no

OPTIONAL DATE/TIMEZONE DEPENDENCIES
               datetime: present, version unknown
               dateutil: matplotlib will provide
                   pytz: matplotlib will provide
adding pytz

OPTIONAL USETEX DEPENDENCIES
                 dvipng: no
            ghostscript: /bin/sh: line 1: gs: command not found
                  latex: no

[Edit setup.cfg to suppress the above messages]
======================================================================== 
====
pymods ['pylab']
packages ['matplotlib', 'matplotlib.backends',  
'matplotlib.projections', 'mpl_toolkits', 'mpl_toolkits.mplot3d',  
'mpl_toolkits.axes_grid', 'matplotlib.sphinxext',  
'matplotlib.numerix', 'matplotlib.numerix.mlab',  
'matplotlib.numerix.ma', 'matplotlib.numerix.linear_algebra',  
'matplotlib.numerix.random_array', 'matplotlib.numerix.fft',  
'matplotlib.delaunay', 'pytz', 'dateutil', 'dateutil/zoneinfo']
running build
running build_py
copying lib/matplotlib/mpl-data/matplotlibrc -> build/lib.macosx-10.4- 
fat-2.6/matplotlib/mpl-data
copying lib/matplotlib/mpl-data/matplotlib.conf -> build/ 
lib.macosx-10.4-fat-2.6/matplotlib/mpl-data
running build_ext
building 'matplotlib.ft2font' extension
c++ -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g  
-bundle -undefined dynamic_lookup -arch i386 -arch ppc -L/usr/local/ 
lib -syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc - 
I/usr/local/include -I/usr/local/include/freetype2 -isysroot / 
Developer/SDKs/MacOSX10.4u.sdk build/temp.macosx-10.4-fat-2.6/src/ 
ft2font.o build/temp.macosx-10.4-fat-2.6/src/mplutils.o build/ 
temp.macosx-10.4-fat-2.6/CXX/cxx_extensions.o build/temp.macosx-10.4- 
fat-2.6/CXX/cxxsupport.o build/temp.macosx-10.4-fat-2.6/CXX/ 
IndirectPythonInterface.o build/temp.macosx-10.4-fat-2.6/CXX/ 
cxxextensions.o -lfreetype -lz -lstdc++ -lm -o build/lib.macosx-10.4- 
fat-2.6/matplotlib/ft2font.so
powerpc-apple-darwin8-g++-4.0.1: unrecognized option '-syslibroot,/ 
Developer/SDKs/MacOSX10.4u.sdk'
i686-apple-darwin8-g++-4.0.1: unrecognized option '-syslibroot,/ 
Developer/SDKs/MacOSX10.4u.sdk'
//usr/bin/ld: -usr/syslibroot: multiply specified
bincollect2: /ld: -syslibroot: multiply specified
ld returned 1 exit statuscollect2:
ld returned 1 exit status
lipo: can't open input file: /var/tmp//ccym1XU1.out (No such file or  
directory)
error: command 'c++' failed with exit status 1
make: *** [mpl_build] Error 1
katrine-whitesons-computer:/Applications/Q/matplotlib-0.99.1.1  
katrinewhiteson$ gcc -V
gcc: argument to `-V' is missing
katrine-whitesons-computer:/Applications/Q/matplotlib-0.99.1.1  
katrinewhiteson$ which gcc
/usr/bin/gcc
katrine-whitesons-computer:/Applications/Q/matplotlib-0.99.1.1  
katrinewhiteson$   c f yj ny
-bash: c: command not found
katrine-whitesons-computer:/Applications/Q/matplotlib-0.99.1.1  
katrinewhiteson$ k/l
-bash: k/l: No such file or directory

On Feb 12, 2010, at 7:44 PM, Ned Deily wrote:

>
> Ned Deily <nad at acm.org> added the comment:
>
> Ah, earlier you said you installed Python 2.6.4 but, in your most  
> recent message, it shows:
>
> katrinewhiteson$ python
> Python 2.6 (trunk:66714:66715M, Oct  1 2008, 18:36:04)
> [GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
>
> I'm not sure what that is but it's not python 2.6.4 nor a  
> python.org python nor an Apple-supplied python.  So chances are it  
> was linked with Tk 10.5 present on the system.  Type:
> which python
> to find out where this one is installed and, if necessary, remove  
> it and re-install a python, like from the python.org installer,  
> that was linked with Tk 8.4.  You then should see something like this:
>
> Python 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32)
> [GCC 4.0.1 (Apple Inc. build 5493)] on darwin
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5651>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5651>
_______________________________________

From report at bugs.python.org  Mon Feb 15 00:02:50 2010
From: report at bugs.python.org (Michael Newman)
Date: Sun, 14 Feb 2010 23:02:50 +0000
Subject: [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:08 2010
From: report at bugs.python.org (tholzer)
Date: Mon, 15 Feb 2010 01:05:08 +0000
Subject: [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 07:46:03 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Feb 2010 06:46:03 +0000
Subject: [issue7932] print statement delayed IOError when stdout has been
	closed
In-Reply-To: <1266195907.59.0.6287236457.issue7932@psf.upfronthosting.co.za>
Message-ID: <1266216363.98.0.420734154285.issue7932@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is not a bug. The output stream gets buffered, and that it is closed is only detected when a flush is attempted. Use the -u option if you want unbuffered stdout.

It is, however, a bug that Python 2.6 apparently fails to flush the output at all; Python 2.5 did that correctly.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7932>
_______________________________________

From report at bugs.python.org  Mon Feb 15 09:39:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Feb 2010 08:39:04 +0000
Subject: [issue3920] OpenBSD 4.4 still doesn't support _XOPEN_SOURCE
In-Reply-To: <1221983557.66.0.866339205664.issue3920@psf.upfronthosting.co.za>
Message-ID: <1266223144.35.0.993821455185.issue3920@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I have now committed bsd3.diff as r78194, r78195, r78196, and r78197

----------
resolution:  -> accepted
status: open -> closed
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.5, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3920>
_______________________________________

From report at bugs.python.org  Mon Feb 15 09:44:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Feb 2010 08:44:06 +0000
Subject: [issue7903] Configure script incorrect for reasonably recent OpenBSD
In-Reply-To: <1265835897.46.0.381453341475.issue7903@psf.upfronthosting.co.za>
Message-ID: <1266223446.41.0.181973432851.issue7903@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This issue is now superseded by issue 3920. It would be good if somebody could confirm that the approach taken for 4.4 continues to work in more recent releases.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7903>
_______________________________________

From report at bugs.python.org  Mon Feb 15 10:43:22 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Feb 2010 09:43:22 +0000
Subject: [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: <1266227002.52.0.897226273765.issue7930@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is the stripid implementation:

_re_stripid = re.compile(r' at 0x[0-9a-f]{6,16}(>+)$', re.IGNORECASE)
def stripid(text):
    """Remove the hexadecimal id from a Python object representation."""
    # The behaviour of %p is implementation-dependent in terms of case.
    if _re_stripid.search(repr(Exception)):
        return _re_stripid.sub(r'\1', text)
    return text

The problem is that repr(Exception) used to return <class exceptions.Exception at 0x00A64510> on Py<=2.4 but now returns <type 'exceptions.Exception'>, so the code inside the if is never executed (this is what happens where there are no unittests).
That 'if' has been introduced in r19750 and I think that the reason is to check if the id in 'text' is really an id and hence has the same format of the ids of other objects. I don't think this is really necessary though.

----------
assignee:  -> ezio.melotti
nosy: +ezio.melotti
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7930>
_______________________________________

From report at bugs.python.org  Mon Feb 15 11:47:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Feb 2010 10:47:38 +0000
Subject: [issue1652] subprocess should have an option to restore SIGPIPE to
	default action
In-Reply-To: <1197992466.47.0.0612439954222.issue1652@psf.upfronthosting.co.za>
Message-ID: <1266230858.38.0.950267753192.issue1652@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think restore_sigpipe=True would be a reasonable default.
As RDM says, adding an unit test would be better, but it may be difficult to do so (we probably can't spawn Python itself since it will change the default SIGPIPE handler at startup).
Looking at the patch, you don't need to import `signal` again: it's already imported at the top level.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1652>
_______________________________________

From report at bugs.python.org  Mon Feb 15 12:47:11 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 15 Feb 2010 11:47:11 +0000
Subject: [issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2
In-Reply-To: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
Message-ID: <1266234431.02.0.908409501983.issue7173@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I tried several times to debug it myself, but I don't understand the exception cleanup macros in ceval.c (UNWIND_EXCEPTION_HANDLER and friends, new in Py3). If someone can get me set up to debug them, I can give it another shot. I assume there are a couple of invariants involved in them? Is there any interaction with generators that I should know about?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________

From report at bugs.python.org  Mon Feb 15 13:37:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Feb 2010 12:37:45 +0000
Subject: [issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2
In-Reply-To: <1266234431.02.0.908409501983.issue7173@psf.upfronthosting.co.za>
Message-ID: <1266237551.3343.6.camel@localhost>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I tried several times to debug it myself, but I don't understand the
> exception cleanup macros in ceval.c (UNWIND_EXCEPTION_HANDLER and
> friends, new in Py3). If someone can get me set up to debug them, I
> can give it another shot. I assume there are a couple of invariants
> involved in them? Is there any interaction with generators that I
> should know about?

The exception state (what sys.exc_info() gives you) in 3.x is lexically
scoped (which it wasn't in 2.x).
Which means that given:
    try:
        1/0
    except ZeroDivisionError:
        # A
        try:
            [][0]
        except IndexError:
            # B
            pass
        # C

The exception state in C will hold the ZeroDivisionError, not the
IndexError (it is the reverse in 2.x). For that, each try/except block
needs to save the previous exception state; it is saved on the frame's
stack. When the try/except block is left, UNWIND_EXC_HANDLER is used to
restore the previous exception state.

And, yes, there's an interaction with generators, because "yield" can be
invoked from an except block. In that case, we have to temporarily
restore the caller's exception state. See the SWAP_EXC_STATE() call in
YIELD_VALUE. Also, the generator's exception state is restored when
resuming it, which is done in line 1162 and following in ceval.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________

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: [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 16:15:05 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 15 Feb 2010 15:15:05 +0000
Subject: [issue7903] Configure script incorrect for reasonably recent OpenBSD
In-Reply-To: <1265835897.46.0.381453341475.issue7903@psf.upfronthosting.co.za>
Message-ID: <1266246905.52.0.829296275078.issue7903@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

In my testing of issue 3920 I missed that the original approach also
fixed the ncurses.h problem, so it should be preferred over bsd3.diff.

I attach a patch that reverts the recent commit and extends the
xopen_source=no up to version 4.9. I've tested it on 4.4 and 4.6,
johns did essentially the same on 4.7.

I agree with Skip and johns that at least all 4.* versions should be covered, otherwise we have this situation every 6 months.

----------
keywords: +patch
Added file: http://bugs.python.org/file16224/use-xopen-source-no.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7903>
_______________________________________

From report at bugs.python.org  Mon Feb 15 17:10:27 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Feb 2010 16:10:27 +0000
Subject: [issue7903] Configure script incorrect for reasonably recent OpenBSD
In-Reply-To: <1265835897.46.0.381453341475.issue7903@psf.upfronthosting.co.za>
Message-ID: <1266250227.8.0.807310500001.issue7903@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Stefan, what ncurses problem are you referring to?

I quite object to working around OpenBSD limitations, and would rather hope that OpenBSD fixes their POSIX support at some point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7903>
_______________________________________

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: [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  Mon Feb 15 20:28:10 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 15 Feb 2010 19:28:10 +0000
Subject: [issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2
In-Reply-To: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
Message-ID: <1266262090.11.0.270405558298.issue7173@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Is it normal that even after the call to next(), the generator frame contains a reference to the RuntimeError?

Long explanation:
- When the function exits, there is a cycle [parent frame]-> ['it' variable]-> [generator frame]-> [RuntimeError]-> [parent frame].
- gc.collect() collects them all, destroys the generator, this causes GeneratorExit exception to be sent into the generator frame.
- This executes SWAP_EXC_STATE() in ceval.c ("/* We were in an except handler when we left, restore the exception state which was put aside */"), this *moves* the reference to the exception from the frame to the thread state.
- The exception is resurrected, but this does not prevent the gc from calling its tp_clear method! and setting exc_info() as a side-effect of gc.collect() is really weird...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________

From report at bugs.python.org  Mon Feb 15 20:54:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Feb 2010 19:54:40 +0000
Subject: [issue7173] Cython compiler run crashes CPython 3.1.1 and 3.2
In-Reply-To: <1256030477.33.0.0599886113888.issue7173@psf.upfronthosting.co.za>
Message-ID: <1266263680.31.0.359434818698.issue7173@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Is it normal that even after the call to next(), the generator frame 
> contains a reference to the RuntimeError?

As long as it's executing the generator it's quite normal. The generator must be able to restore the caller's RuntimeError when interrupted by a yield. But after the yield, the generator normally doesn't retain a reference (thanks to SWAP_EXC_STATE() in YIELD_VALUE).

> - This executes SWAP_EXC_STATE() in ceval.c ("/* We were in an except handler when we left, restore the exception state which was put aside */"), this *moves* the reference to the exception from the frame to the thread state.

Actually, it (does/should) execute SAVE_EXC_STATE() instead, because the thread's exception state was empty when yielding.

The following patch seems to do the trick:

diff -r 4465a45b8876 Python/ceval.c
--- a/Python/ceval.c	Mon Feb 15 09:35:16 2010 +0100
+++ b/Python/ceval.c	Mon Feb 15 20:51:58 2010 +0100
@@ -1159,7 +1159,7 @@ PyEval_EvalFrameEx(PyFrameObject *f, int
 	assert(stack_pointer != NULL);
 	f->f_stacktop = NULL;	/* remains NULL unless yield suspends frame */
 
-	if (f->f_code->co_flags & CO_GENERATOR) {
+	if (!throwflag && (f->f_code->co_flags & CO_GENERATOR)) {
 		if (f->f_exc_type != NULL && f->f_exc_type != Py_None) {
 			/* We were in an except handler when we left,
 			   restore the exception state which was put aside

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7173>
_______________________________________

From report at bugs.python.org  Mon Feb 15 22:03:45 2010
From: report at bugs.python.org (tholzer)
Date: Mon, 15 Feb 2010 21:03:45 +0000
Subject: [issue7932] print statement delayed IOError when stdout has been
	closed
In-Reply-To: <1266195907.59.0.6287236457.issue7932@psf.upfronthosting.co.za>
Message-ID: <1266267825.51.0.71658913414.issue7932@psf.upfronthosting.co.za>


tholzer <tholzer at wetafx.co.nz> added the comment:

This is not quite correct:

The following 2 lines fail as expected (unbuffered):

<pre>
python -u -c 'import sys; print >> sys.stdout, "x"' 1>&- ; echo $?
python -u -c 'import sys; print >> sys.stderr, "x"' 2>&- ; echo $?
</pre>

whereas in the following example, the first command succeeds and the second one fails:

<pre>
python -c 'import sys; print >> sys.stdout, "x"' 1>&- ; echo $?
python -c 'import sys; print >> sys.stderr, "x"' 2>&- ; echo $?
</pre>

This is counter-intuitive and somewhat contradicts the documentation, as stderr always seems to be unbuffered (irrespective of the -u option). IMHO, they should either both fail or both succeed.

They seem to behave the same in 2.5 & 2.6, however in 3.1, they all die with a SIGABRT, which I guess could be questioned as well. IMHO, they should just throw an exception like in 2.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7932>
_______________________________________

From report at bugs.python.org  Mon Feb 15 22:11:36 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 15 Feb 2010 21:11:36 +0000
Subject: [issue7903] Configure script incorrect for reasonably recent OpenBSD
In-Reply-To: <1265835897.46.0.381453341475.issue7903@psf.upfronthosting.co.za>
Message-ID: <1266268296.96.0.525263881247.issue7903@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

On OpenBSD the ncurses.h header has been broken for quite some time,
see e.g. http://bugs.python.org/issue1244610. The problem is that
when _XOPEN_SOURCE_EXTENDED is defined, wchar_t is defined twice.
I can confirm that it is still broken on 4.6, but it appears that
it has been fixed in current.

So I propose to use the old method up to 4.6, and use the new method
from 4.7 on. I attach a patch that has been tested on an OpenBSD
snapshot (which will become version 4.7).

----------
Added file: http://bugs.python.org/file16226/openbsd_configure.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7903>
_______________________________________

From report at bugs.python.org  Mon Feb 15 22:47:18 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Feb 2010 21:47:18 +0000
Subject: [issue7903] Configure script incorrect for reasonably recent OpenBSD
In-Reply-To: <1265835897.46.0.381453341475.issue7903@psf.upfronthosting.co.za>
Message-ID: <1266270438.29.0.519341153077.issue7903@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the tests, and the patch. Committed as r78202, r78203, r78204, and r78205.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7903>
_______________________________________

From report at bugs.python.org  Mon Feb 15 22:48:22 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Feb 2010 21:48:22 +0000
Subject: [issue6375] compile failure in Modules/python.c
In-Reply-To: <1246293041.45.0.166944459621.issue6375@psf.upfronthosting.co.za>
Message-ID: <1266270502.08.0.893343644945.issue6375@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Closing this as unreproducible.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6375>
_______________________________________

From report at bugs.python.org  Mon Feb 15 22:49:27 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 15 Feb 2010 21:49:27 +0000
Subject: [issue4639] Build failure on OpenBSD 4.4-current regarding lstat()
In-Reply-To: <1229091079.2.0.148699699558.issue4639@psf.upfronthosting.co.za>
Message-ID: <1266270567.82.0.624778202779.issue4639@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please try the Python trunk (or release26-maint branch) and report whether the problem still occurs?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4639>
_______________________________________

From report at bugs.python.org  Tue Feb 16 00:27:11 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 15 Feb 2010 23:27:11 +0000
Subject: [issue4639] Build failure on OpenBSD 4.4-current regarding lstat()
In-Reply-To: <1229091079.2.0.148699699558.issue4639@psf.upfronthosting.co.za>
Message-ID: <1266276431.23.0.722462046866.issue4639@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This is fixed in trunk by the configure.in patch. I've tested trunk on 4.4
and 4.7.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4639>
_______________________________________

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: [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 03:45:57 2010
From: report at bugs.python.org (JT Johnson)
Date: Tue, 16 Feb 2010 02:45:57 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1266288357.6.0.903480955095.issue7936@psf.upfronthosting.co.za>


JT Johnson <svedgeburn at gmail.com> added the comment:

Actually, I was playing around with it and I found that using the "python" command before it does work.
Now, when I type what you said to do, it shows that there is no association, even though i can run a program without the python command.
This is quite strange...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Tue Feb 16 03:50:52 2010
From: report at bugs.python.org (JT Johnson)
Date: Tue, 16 Feb 2010 02:50:52 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1266288652.04.0.824962740686.issue7936@psf.upfronthosting.co.za>


JT Johnson <svedgeburn at gmail.com> added the comment:

Sorry for a double-comment, but I thought of posting this after I already submitted the last one and I found no edit button.

Here's some output:

"Microsoft Windows [Version 6.0.6001]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.
C:\Users\JT>assoc .py
File association not found for extension .py
C:\Users\JT>assoc py
File association not found for extension py
C:\Users\JT\Desktop\Programming Projects>pythonversion.py
2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]
C:\Users\JT\Desktop\Programming Projects>ftype Python.File
File type 'Python.File' not found or no open command associated with it.
C:\Users\JT\Desktop\Programming Projects>assoc py
File association not found for extension py
C:\Users\JT\Desktop\Programming Projects>assoc .py
File association not found for extension .py
C:\Users\JT\Desktop\Programming Projects>assoc .pyw
File association not found for extension .pyw
C:\Users\JT\Desktop\Programming Projects>assoc pyw
File association not found for extension pyw
C:\Users\JT\Desktop\Programming Projects>assoc pyc
File association not found for extension pyc
C:\Users\JT\Desktop\Programming Projects>assoc .pyc
File association not found for extension .pyc
C:\Users\JT\Desktop\Programming Projects>assoc .pyo
File association not found for extension .pyo
C:\Users\JT\Desktop\Programming Projects>assoc pyo
File association not found for extension pyo"

(Sorry it's so long, I cut out the blank lines as it is)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Tue Feb 16 04:09:26 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Tue, 16 Feb 2010 03:09:26 +0000
Subject: [issue7931] Python hangs after last thread has exited
In-Reply-To: <1266190573.54.0.57456470329.issue7931@psf.upfronthosting.co.za>
Message-ID: <1266289766.24.0.0906440991023.issue7931@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

Here is a short testcase that reproduces the problem. If you run the script it daemonizes correctly, but then the daemon does not terminate  but hangs forever.

The crucial part seems to be to daemonize the program while there is more than one thread running.

----------
Added file: http://bugs.python.org/file16228/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7931>
_______________________________________

From report at bugs.python.org  Tue Feb 16 04:13:04 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Tue, 16 Feb 2010 03:13:04 +0000
Subject: [issue7931] Interpreter does not terminate if daemonized while
	running multithreaded
In-Reply-To: <1266190573.54.0.57456470329.issue7931@psf.upfronthosting.co.za>
Message-ID: <1266289984.72.0.0611806080485.issue7931@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


----------
title: Python hangs after last thread has exited -> Interpreter does not terminate if daemonized while running multithreaded

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7931>
_______________________________________

From report at bugs.python.org  Tue Feb 16 06:02:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Feb 2010 05:02:12 +0000
Subject: [issue7846] Fnmatch cache is never cleared during usage
In-Reply-To: <1265209336.56.0.865162695939.issue7846@psf.upfronthosting.co.za>
Message-ID: <1266296532.89.0.195780253421.issue7846@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

The feature seems useful to me and the patch straightforward.

I wonder why you used a global name for the max length (?_MAXCACHE?) instead of inlining the value where it is used. Does it feel more constanty? ;) I fear that the leading underscore won?t discourage users from touching it, so I?d suggest making it public or completely hidden. On second thought, you could argue that Python is a matter of consenting adults, and that leading underscore is okay.

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7846>
_______________________________________

From report at bugs.python.org  Tue Feb 16 06:13:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Feb 2010 05:13:15 +0000
Subject: [issue7751] urllib.urlopen("///C|/foo/bar/spam.foo") IOError: [Errno
	22]
In-Reply-To: <1264114525.88.0.153808488744.issue7751@psf.upfronthosting.co.za>
Message-ID: <1266297195.33.0.620987373617.issue7751@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

I?m no expert on Python bugs, but I believe a test for the fixed behavior would improve your patch. Maybe a link to some documentation in a comment (or in an entry in Misc/NEWS) too.

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7751>
_______________________________________

From report at bugs.python.org  Tue Feb 16 07:42:18 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Feb 2010 06:42:18 +0000
Subject: [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: <1266302538.67.0.999068579063.issue7930@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here's a patch with a minimal unittest.

----------
keywords: +easy, needs review, patch
stage: test needed -> patch review
versions:  -Python 2.5
Added file: http://bugs.python.org/file16229/issue7930.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7930>
_______________________________________

From report at bugs.python.org  Tue Feb 16 08:53:51 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 16 Feb 2010 07:53:51 +0000
Subject: [issue7751] urllib.urlopen("///C|/foo/bar/spam.foo") IOError: [Errno
	22]
In-Reply-To: <1264114525.88.0.153808488744.issue7751@psf.upfronthosting.co.za>
Message-ID: <1266306831.22.0.838980974908.issue7751@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

A testcase is attached.

Information about the file URI scheme can be found at:

http://en.wikipedia.org/wiki/File_URI_scheme
http://tools.ietf.org/html/draft-hoffman-file-uri-03
http://blogs.msdn.com/ie/archive/2006/12/06/file-uris-in-windows.aspx
http://www.cs.tut.fi/~jkorpela/fileurl.html

----------
Added file: http://bugs.python.org/file16230/test_nturl2path.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7751>
_______________________________________

From report at bugs.python.org  Tue Feb 16 10:08:04 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 16 Feb 2010 09:08:04 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266311284.62.0.139991833188.issue7900@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Michael: 
* which configure options do you use?
* which xcode version do you use? 
  (this shouldn't be relevant, I'm interested in what causes the dot 1
  suffix)
* If you use --enable-universalsdk: do you have the 10.4 SDK installed
  (should be installed in "$(xcode-select -print-path)/SDKs/")

I cannot reproduce this with r78205, OSX 10.6.2/10C540, gcc version 4.2.1 (Apple Inc. build 5659), Xcode 3.2.2/10M2135.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Feb 16 10:12:29 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 16 Feb 2010 09:12:29 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266311549.51.0.490141234167.issue7900@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

A related question: is this issue present in the 3.x trunk?

(BTW: feel free to assign all OSX related issues to me)

----------
assignee:  -> ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Feb 16 10:38:46 2010
From: report at bugs.python.org (Andrew Clegg)
Date: Tue, 16 Feb 2010 09:38:46 +0000
Subject: [issue7846] Fnmatch cache is never cleared during usage
In-Reply-To: <1265209336.56.0.865162695939.issue7846@psf.upfronthosting.co.za>
Message-ID: <1266313126.32.0.208469812466.issue7846@psf.upfronthosting.co.za>


Andrew Clegg <ancl at pml.ac.uk> added the comment:

Hi,

I used a global name for a couple of reasons: it is consistent with the cache itself and the size of the cache being defined in the same place; and because I wanted to allow the value to be modified by users.

I used the leading underscore to give a weak indication of internal use - for most users, it can be completely ignored. If someone wanted to modify the maximum size of the cache however, this would be a reasonable and safe thing for them to do.

Cheers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7846>
_______________________________________

From report at bugs.python.org  Tue Feb 16 11:46:56 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 16 Feb 2010 10:46:56 +0000
Subject: [issue7582] [patch] diff.py to use iso timestamp
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1266317216.32.0.0931158822369.issue7582@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Ok. Let's commit it at least to 2.7 - I'll create a separate issue for discussion of unified diff format later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7582>
_______________________________________

From report at bugs.python.org  Tue Feb 16 13:22:33 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 16 Feb 2010 12:22:33 +0000
Subject: [issue1212900] Python segfaults on OpenBSD (tested 3.4 and 3.5)
Message-ID: <1266322953.47.0.412471793503.issue1212900@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

It is a stack overflow, which can be prevented by setting

#define Py_DEFAULT_RECURSION_LIMIT 150

in Python/ceval.c.

Then the program behaves in the same way as on Linux (i.e. it swallows
the RuntimeError somewhere). Recommend closing.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1212900>
_______________________________________

From report at bugs.python.org  Tue Feb 16 13:52:41 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Feb 2010 12:52:41 +0000
Subject: [issue4151] Separate build dir broken
In-Reply-To: <1224522256.17.0.820973690454.issue4151@psf.upfronthosting.co.za>
Message-ID: <1266324761.0.0.167735095835.issue4151@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

current status with 2.7 alpha3:

FAIL: test_get_python_inc (distutils.tests.test_sysconfig.SysconfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/packages/python/2.7/python2.7-2.7~a3/Lib/distutils/tests/test_sysconfig.py", line 47, in test_get_python_inc
    self.assertTrue(os.path.isfile(python_h), python_h)
AssertionError: /home/packages/python/2.7/python2.7-2.7~a3/build-static/Include/Python.h

unsure about this one:
FAIL: test_finalize_options (distutils.tests.test_build.BuildTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/packages/python/2.7/python2.7-2.7~a3/Lib/distutils/tests/test_build.py", line 24, in test_finalize_options
    self.assertEquals(cmd.build_purelib, wanted)
AssertionError: 'build/lib.linux-i686-2.7' != 'build/lib'

----------
nosy: +tarek
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4151>
_______________________________________

From report at bugs.python.org  Tue Feb 16 13:54:18 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Feb 2010 12:54:18 +0000
Subject: [issue5217] testExtractDir (test.test_zipfile.TestWithDirectory)
	fails when python built with srcdir != builddir
In-Reply-To: <1234363884.6.0.67560680288.issue5217@psf.upfronthosting.co.za>
Message-ID: <1266324858.02.0.306470921715.issue5217@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

this works with 2.7 alpha3, won't fix for 3.0

----------
versions:  -Python 2.7, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5217>
_______________________________________

From report at bugs.python.org  Tue Feb 16 14:59:11 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 16 Feb 2010 13:59:11 +0000
Subject: [issue7334] ElementTree: file locking in Jython 2.5 (OSError on
	Windows)
In-Reply-To: <1258386968.95.0.507644857951.issue7334@psf.upfronthosting.co.za>
Message-ID: <1266328751.78.0.575291188102.issue7334@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The patch proposed on msg95349:
 * need tests
 * not reviewed (yet)

----------
keywords: +patch
nosy: +flox
priority:  -> normal
stage:  -> needs patch
title: XML file locking in Jython 2.5 (OSError on Windows) -> ElementTree: file locking in Jython 2.5 (OSError on Windows)
Added file: http://bugs.python.org/file16231/issue7334_etree_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7334>
_______________________________________

From report at bugs.python.org  Tue Feb 16 15:01:54 2010
From: report at bugs.python.org (Jason Tishler)
Date: Tue, 16 Feb 2010 14:01:54 +0000
Subject: [issue1005895] curses for win32
Message-ID: <1266328914.49.0.408240989341.issue1005895@psf.upfronthosting.co.za>


Jason Tishler <jason at tishler.net> added the comment:

Sorry, but I don't know. I haven't looked at this issue for almost five years! And when I did, I only looked as far to determine it wasn't Cygwin related.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1005895>
_______________________________________

From report at bugs.python.org  Tue Feb 16 15:25:13 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Tue, 16 Feb 2010 14:25:13 +0000
Subject: [issue7736] os.listdir hangs since opendir() and closedir() do
	not	release GIL
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1266330313.63.0.286839853747.issue7736@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

Does this patch still need review? Both Martin and Antoine already commented that the patch is ok, so it'd be great if someone could actually apply it...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Tue Feb 16 15:45:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Feb 2010 14:45:01 +0000
Subject: [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: <1266331501.23.0.915297063126.issue7939@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If by "fail" you mean "doesn't execute the command in the way I expected", then I believe you will be enlightened by reading the recent updates to the Popen documentation (see issue 6760).

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> patch to subprocess docs to better explain Popen's 'args' argument
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7939>
_______________________________________

From report at bugs.python.org  Tue Feb 16 16:22:24 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 16 Feb 2010 15:22:24 +0000
Subject: [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: <1266333744.15.0.773432603838.issue7939@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I can't see changes to subprocess.call() docs in issue #6760. I reopen this bug, because call() definitely need a visible note about this significant behavior. I can not reopen #6760

http://docs.python.org/library/subprocess.html#convenience-functions

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7939>
_______________________________________

From report at bugs.python.org  Tue Feb 16 18:20:17 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 16 Feb 2010 17:20:17 +0000
Subject: [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: <1266340817.36.0.387775520694.issue7939@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I still do not agree. There should be a note in call() documentation, because users will waste their time experiencing the bug before reading documentation again.

If you can't make something just work without rereading the whole doc - that's not pythonic.

----------

_______________________________________
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: [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:36:59 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 16 Feb 2010 17:36:59 +0000
Subject: [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: <1266341819.33.0.648378754297.issue7939@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

"This module also defines two shortcut functions"

I think given that we say the calls are shortcuts, and that their arguments are the same as Popen, I take that to mean that subprocess.call experiences the same situations as subprocess.Popen.

If any change has to be made, I could get on board with changing "two shortcut functions" to "two Popen shortcut functions".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7939>
_______________________________________

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: [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: [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 18:53:35 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 16 Feb 2010 17:53:35 +0000
Subject: [issue7931] Interpreter does not terminate if daemonized while
	running multithreaded
In-Reply-To: <1266190573.54.0.57456470329.issue7931@psf.upfronthosting.co.za>
Message-ID: <1266342815.39.0.0395340294816.issue7931@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

libc.daemon() calls forks(), which duplicates only the main thread.
The other thread does not exists in the forked process, and the interpreter blocks while trying to wait for it...

Please use os.fork() instead, it has code to forget the threads created by the threading module (and clears some other locks as well, preventing deadlocks).
Or google for "daemonize python".

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7931>
_______________________________________

From report at bugs.python.org  Tue Feb 16 19:00:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Feb 2010 18:00:10 +0000
Subject: [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: <1266343210.98.0.798463440217.issue7939@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

You can't even use call or check_call without referencing the Popen constructor documentation, so I'm not sure what you are advocating, Anatoly.  We certainly don't want to repeat the Popen documentation in full for each convenience function, and if we aren't doing that it seems to me that the current one line redirect to the full Popen docs is the right thing to do.  I have, however, turned those references into active links. so that all you have to do is click on Popen to get bounced up to the full docs.  (Change made in trunk in r78206, it will get copied to the other branches eventually.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7939>
_______________________________________

From report at bugs.python.org  Tue Feb 16 19:03:12 2010
From: report at bugs.python.org (Thomas Smith)
Date: Tue, 16 Feb 2010 18:03:12 +0000
Subject: [issue7332] python script segment fault at
	PyMarshal_ReadLastObjectFromFile in import_submodule
In-Reply-To: <1258357834.64.0.393669010596.issue7332@psf.upfronthosting.co.za>
Message-ID: <1266343392.07.0.59164377904.issue7332@psf.upfronthosting.co.za>


Thomas Smith <thomathom at gmail.com> added the comment:

I'm also getting segfaults in PyMarshal_ReadLastObjectFromFile in Python 2.6.2 (on Ubuntu Jaunty).  It's very sporadic, I've been reproducing it by running a minimal script 100,000 times, and getting a few core dumps.  There are several Ubuntu bugreports in various packages that use Python:

https://bugs.launchpad.net/ubuntu/+source/apport/+bug/393022
https://bugs.launchpad.net/ubuntu/+source/gnome-python/+bug/432546
https://bugs.launchpad.net/ubuntu/+source/streamtuner/+bug/336331

I've attached a zip file with my test scripts and some gdb backtraces.  I am happy to spend time on this bug, although I only have a rudimentary knowledge of C, so I'd mainly be useful for testing.

The computer I'm having trouble on is a Dell PowerEdge T410, with a Xeon E5502, and it had another sporadic segfault problem in a should-be-reliable program, ImageMagick.  Switching to GraphicsMagick fixed that one, somehow.  If it's a hardware-specific bug, Python is the only program that's tickling it right now...

----------
nosy: +Thomas.Smith
versions: +Python 2.6
Added file: http://bugs.python.org/file16236/traces.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7332>
_______________________________________

From report at bugs.python.org  Tue Feb 16 19:04:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Feb 2010 18:04:08 +0000
Subject: [issue7846] Fnmatch cache is never cleared during usage
In-Reply-To: <1266313126.32.0.208469812466.issue7846@psf.upfronthosting.co.za>
Message-ID: <4B7ADE10.6090202@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Hi

Your rationale makes perfect sense. Perhaps add a comment suggesting 
it?s ok to change the value.

Cheers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7846>
_______________________________________

From report at bugs.python.org  Tue Feb 16 19:11:16 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 16 Feb 2010 18:11:16 +0000
Subject: [issue1212900] Python segfaults on OpenBSD (tested 3.4 and 3.5)
Message-ID: <1266343876.18.0.586510117856.issue1212900@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1212900>
_______________________________________

From report at bugs.python.org  Tue Feb 16 19:16:11 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 16 Feb 2010 18:16:11 +0000
Subject: [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: <1266344171.53.0.771907964009.issue7942@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I fail to see the bug in this report. What did you expect to happen instead?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7942>
_______________________________________

From report at bugs.python.org  Tue Feb 16 19:20:21 2010
From: report at bugs.python.org (kenneth dombrowski)
Date: Tue, 16 Feb 2010 18:20:21 +0000
Subject: [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 19:23:48 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 16 Feb 2010 18:23:48 +0000
Subject: [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: <1266344628.84.0.268004181733.issue7944@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Please use patches to show where the code changed.
(I generated one; it looks good to me)

I would like this kind of patches applied to CPython.
Looking at the Pypy test suite, the following test files seem easy to update:
test_bz2
test_dumbdbm
test_mailbox
test_marshal
test_mmap
test_pkgimport
test_tarfile
test_tempfile
test_traceback

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file16237/test_old_mailbox.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7944>
_______________________________________

From report at bugs.python.org  Tue Feb 16 21:19:13 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 16 Feb 2010 20:19:13 +0000
Subject: [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: <1266351553.79.0.242959661923.issue7939@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Thanks. That should be enough, although I wouldn't mind against more prominent notice to urge users to go and see Popen parameters. I would also add a second example to allow users see the difference. For instance, how to execute another Python script:

retcode = call("diff.py oldfile newfile", shell=True)
retcode = call([sys.executable], ["diff.py oldfile newfile"])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7939>
_______________________________________

From report at bugs.python.org  Tue Feb 16 21:24:38 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 16 Feb 2010 20:24:38 +0000
Subject: [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: <1266351878.44.0.904511914053.issue7939@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

The last one should be:
retcode = call([sys.executable, "diff.py oldfile newfile"])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7939>
_______________________________________

From report at bugs.python.org  Tue Feb 16 21:41:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Feb 2010 20:41:01 +0000
Subject: [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: <1266352861.51.0.06017054702.issue7939@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think you should reread the Popen docs carefully :)

That example should be:

call([sys.executable, 'diff.py', 'oldfile', 'newfile'])

And there are examples of that call format in the Popen docs, as well as the explanation of exactly how to format the list correctly.  So again, I don't think it is a good idea to try to duplicate that in the call/check_call docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7939>
_______________________________________

From report at bugs.python.org  Tue Feb 16 21:48:46 2010
From: report at bugs.python.org (David Beazley)
Date: Tue, 16 Feb 2010 20:48:46 +0000
Subject: [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  Tue Feb 16 21:58:32 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 16 Feb 2010 20:58:32 +0000
Subject: [issue7945] typo in operator.isCallable deprecation warning
In-Reply-To: <1266344420.98.0.249728155986.issue7945@psf.upfronthosting.co.za>
Message-ID: <1266353912.6.0.72448472773.issue7945@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No, this is correct.  isCallable() was deprecated since 2.0, but the replacement was the builtin callable() until 2.6.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7945>
_______________________________________

From report at bugs.python.org  Tue Feb 16 23:24:54 2010
From: report at bugs.python.org (Andrew McNabb)
Date: Tue, 16 Feb 2010 22:24:54 +0000
Subject: [issue5088] optparse: inconsistent default value for append actions
In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>
Message-ID: <1266359094.39.0.851552986764.issue5088@psf.upfronthosting.co.za>


Andrew McNabb <amcnabb at mcnabbs.org> added the comment:

I think that optparse is doing the right thing here.  I think that your code example should be changed to:

import optparse
  parser = optparse.OptionParser()
  parser.add_option("-o", "--option", action = "append")
  options, args = parser.parse_args()
  if not options.option:
    options.option = ['a']
  print options

Think of the default as the initial list, and each time the -o option is specified, an item is appended to that initial list.

----------
nosy: +amcnabb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5088>
_______________________________________

From report at bugs.python.org  Tue Feb 16 23:46:07 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 16 Feb 2010 22:46:07 +0000
Subject: [issue7947] Documentation of math.pow, math.hypot, and complex.__abs__
In-Reply-To: <1266360101.13.0.863363643677.issue7947@psf.upfronthosting.co.za>
Message-ID: <1266360367.73.0.852409512748.issue7947@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for reporting this.

Rather than documenting corner cases explicitly, maybe it would be enough to point to the C99 standard:  the corner cases for the math functions should (modulo bugs) all follow Annex F of the C standard, while the corner cases for the cmath functions follow Annex G.  This doesn't quite tell the complete story, because some functions (for example the cmath.rect function) don't appear in the C standards, but it would avoid cluttering the function descriptions with special cases.

Certainly the "All functions ..." sentence is inaccurate, and should be removed or revised.  I believe it's true for all single-argument functions, though.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7947>
_______________________________________

From report at bugs.python.org  Tue Feb 16 23:54:41 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 16 Feb 2010 22:54:41 +0000
Subject: [issue7947] Documentation of math.pow, math.hypot, and complex.__abs__
In-Reply-To: <1266360101.13.0.863363643677.issue7947@psf.upfronthosting.co.za>
Message-ID: <1266360881.48.0.514515978617.issue7947@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  Looking at the docs, there are a number of revisions that would be useful.  For example, the docs mention signaling NaNs, but that doesn't make a lot of sense:  Python essentially treats all NaNs as quiet.  I'll add this to my to-do list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7947>
_______________________________________

From report at bugs.python.org  Wed Feb 17 00:17:50 2010
From: report at bugs.python.org (Paul Boddie)
Date: Tue, 16 Feb 2010 23:17:50 +0000
Subject: [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: <1266362270.98.0.211314760332.issue7942@psf.upfronthosting.co.za>


Paul Boddie <paul at boddie.org.uk> added the comment:

I would have expected a more accurate error message for the new-style class. In the original message which brought this to my attention, the cause was not particularly obvious:

http://www.selenic.com/pipermail/mercurial/2010-February/030066.html

I concede that the different mechanisms in place for new-style classes might make it hard to have a specific error message in such a situation, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7942>
_______________________________________

From report at bugs.python.org  Wed Feb 17 00:21:47 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 16 Feb 2010 23:21:47 +0000
Subject: [issue6472] Update ElementTree with upstream changes
In-Reply-To: <1247446553.79.0.919218325186.issue6472@psf.upfronthosting.co.za>
Message-ID: <1266362507.79.0.993271030102.issue6472@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Update the 2.x patch with the last version uploaded to rietveld (patch set 5).

Improved test coverage with upstream tests and tests cases provided by Neil on issue #6232.

Note: the patch for 3.x is obsolete.

----------
Added file: http://bugs.python.org/file16239/issue6472_etree_upstream_v5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6472>
_______________________________________

From report at bugs.python.org  Wed Feb 17 00:35:16 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Feb 2010 23:35:16 +0000
Subject: [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: <1266363316.79.0.539420805806.issue7930@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r78207 (trunk), r78208 (release26-maint), r78209 (py3k) and r78210 (release31-maint).
After a short discussion on #python-dev I decided to remove the 'if', because it's not necessary and might creates problems with other implementations.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7930>
_______________________________________

From report at bugs.python.org  Wed Feb 17 01:35:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Feb 2010 00:35:21 +0000
Subject: [issue5088] optparse: inconsistent default value for append actions
In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>
Message-ID: <1266366921.73.0.689746427839.issue5088@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I agree with Andrew, but I think the optparse documentation should make it clear that this is what happens with a default value for an 'append' action.  It is *implied* by the fact that append says it appends to a list, and default says the value is set before any options are parsed, but it should be made explicit in the docs for the 'append' action.  Doc patch welcomed.

----------
assignee:  -> georg.brandl
components: +Documentation -Library (Lib)
nosy: +georg.brandl, r.david.murray
priority:  -> normal
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5088>
_______________________________________

From report at bugs.python.org  Wed Feb 17 01:50:39 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Feb 2010 00:50:39 +0000
Subject: [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: <1266367839.43.0.024965979491.issue7942@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In the example you give it seems to me that the message for the new style class is more accurate and useful than the message for the old style class.  Looking at your mercurial example, it looks like the problem is the same (len returning a long), and again it seems to me that the new message is more accurate than the old, and that neither one is more confusing than the other in the given context(s).  Or, if anything, that the OverflowError is less confusing as it has more connection with the problem (committing *large* amounts of data).

I don't see this as a bug in any sense, myself.  What would consider to be a "specific" error message?  Perhaps this is a request for an enhancement, instead.

----------
nosy: +r.david.murray
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7942>
_______________________________________

From report at bugs.python.org  Wed Feb 17 02:22:40 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 17 Feb 2010 01:22:40 +0000
Subject: [issue7005] ConfigParser does not handle options without values
In-Reply-To: <1254032044.95.0.187935622211.issue7005@psf.upfronthosting.co.za>
Message-ID: <1266369760.21.0.252528846032.issue7005@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Assigning to myself for handling.

Bumping to Python 2.7 / 3.2 since support for this syntax variation is a new feature.

----------
assignee:  -> fdrake
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7005>
_______________________________________

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: [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 02:44:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 17 Feb 2010 01:44:43 +0000
Subject: [issue7948] Complete your registration to Python tracker --
	key	yAMyUeuHR9LS2Q86aUUs2GO4rujOhgWH
In-Reply-To: <4B7B4978.6050804@gmx.net>
Message-ID: <1266371083.02.0.515280565909.issue7948@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7948>
_______________________________________

From report at bugs.python.org  Wed Feb 17 03:30:48 2010
From: report at bugs.python.org (=?utf-8?q?Mathias_Panzenb=C3=B6ck?=)
Date: Wed, 17 Feb 2010 02:30:48 +0000
Subject: [issue7949] idle does not handle dark gtk color schemes
In-Reply-To: <1266372113.11.0.0197701157976.issue7949@psf.upfronthosting.co.za>
Message-ID: <1266373848.2.0.533247356736.issue7949@psf.upfronthosting.co.za>


Mathias Panzenb?ck <grosser.meister.morti at gmx.net> added the comment:

I just noticed that the debugger also suffers from this problem. Doing a quick grep over the source reveals even more places that might cause problems (where only the bg or only the fg color is set).

I think in ScrolledList.py the background="white" should just be removed. This and setting the fg color to black when the bg color is set to yellow (Debugger.py) makes the debugger usable.

Checkboxes and radiobuttons seem to be messed up in general (forced white bg but using system fg color (white on white on my system); not idles but Tkinters or TKs fault).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7949>
_______________________________________

From report at bugs.python.org  Wed Feb 17 04:00:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Feb 2010 03:00:39 +0000
Subject: [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: <1266375639.71.0.245501264547.issue7946@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Just a quick test under Linux (on a dual quad core machine):
- with iotest.py and echo_client.py both running Python 2.7: 25.562 seconds (410212.450 bytes/sec)
- with iotest.py and echo_client.py both running Python 3.2: 28.160 seconds (372362.459 bytes/sec)

As already said, the "spinning endlessly" loop is a best case for thread switching latency in 2.x, because the opcodes are very short. If each opcode in the loop has an average duration of 20 ns, and with the default check interval of 100, the GIL gets speculatively released every 2 us (yes, microseconds). That's why I suggested trying more "realistic" workloads, as in ccbench.

Also, as I told you, there might also be interactions with the various timing heuristics the TCP stack of the kernel applies. It would be nice to test with UDP.

That said, the observations are interesting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Wed Feb 17 04:30:17 2010
From: report at bugs.python.org (Meador Inge)
Date: Wed, 17 Feb 2010 03:30:17 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1266059274.29.0.344917421658.issue3132@psf.upfronthosting.co.za>
Message-ID: <4095897c1002161930l74fa0f13xf9656c71b6cfde41@mail.gmail.com>


Meador Inge <meadori at gmail.com> added the comment:

Hi All,

On Sat, Feb 13, 2010 at 5:07 AM, Mark Dickinson <report at bugs.python.org>wrote:

>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Some of the proposed struct module additions look far from straightforward;
>  I find that section of the PEP significantly lacking in details and
> motivation.
>

I agree.

> "Unpacking a long-double will return a decimal object or a ctypes
> long-double."
>
> Returning a Decimal object here doesn't make a lot of sense, since Decimal
> objects aren't generally compatible with floats.  And ctypes long double
> objects don't seem to exist, as far as I can tell.  It might be better not
> to add this code.

And under what conditions would a ctype long double be used vs. a Decimal
object.

>

Another bit that's not clear to me:  how is unpacking an object pointer
> expected to work, and how would it typically be used?  What if the unpacked
> pointer no longer points to a valid Python object?  How would this work in
> other Python implementations?
>

I guess if an object associated with the packed address does not exist, then
you would unpack None (?).  This is especially a problem if the struct-sting
is being sent over the wire to another machine.

> For the 'X{}' format (pointer to a function), is this supposed to mean a
> Python function or a C function?
>

I read that as a Python function.  However, I am not completely sure how the
prototype would be enforced when unpacking.  I am also wondering, though,
how the signatures on pointers-to-functions are specified?  Are
the arguments and return type full struct strings as well?

> What's a 'specific pointer'?

I think this means a pointer to a specific type, e.g. '&d' is a pointer to a
double. If this is the case, though, the use cases are not completely clear
to me.

I also have the following questions:

* Can pointers be nested, '&&d' ?
* What nesting level can structures have? Arbitrary?
* The new array syntax claims "multi-dimensional array of whatever follows".

  Truly whatever? Arrays of structures? Arrays of pointers?
* "complex (whatever the next specifier is)".  Not really 'whatever'.  You
  can not have a 'complex bool' or 'complex int'.  What other types of
  complex are there besides complex double?
* How do array specifiers and pointer specifiers mix?  For example, would
  '(2, 2)&d' be a two-by-two array of pointers to doubles?  What about
  '&(2, 2)d'?  Is this a pointer to an two-by-two array of doubles?

The new features of the struct-string syntax are so different that I think
we
need to specify a grammar.  I think it will clarify some of the open
questions.

In addition, I was thinking that a reasonable implemenation strategy would
be to keep the current struct-string syntax mostly in place within the C
module
implementation.  The C implementation would just provide an interface to
pack\unpack sequences of primitive data elements.  Then we could write a
layer in the Python 'struct' module that took care of the higher-order
concepts like nested structures, arrays, named values, and pointers to
functions.  The higher-order concepts would be mapped to the appropriate
primitive sequence strings.

I think this will simplify the implementation and will provide a way to
phase
it.  We can implement the primitive type extensions in C first followed by
the higher-level Python stuff.  The result of each phase is immediately
usuable.

I have attached a patch against the PEP containing my current thoughts on
fleshing out the grammar and some of the current open questions.  This still
needs work, but I wanted to share to see if I am on the right track.
 Please advise on how to proceed.

----------
keywords: +patch
Added file: http://bugs.python.org/file16241/unnamed
Added file: http://bugs.python.org/file16242/pep-3118.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________
-------------- next part --------------
<div>Hi All,</div><div><br></div>On Sat, Feb 13, 2010 at 5:07 AM, Mark Dickinson <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Mark Dickinson &lt;<a href="mailto:dickinsm at gmail.com">dickinsm at gmail.com</a>&gt; added the comment:<br>
<br>
Some of the proposed struct module additions look far from straightforward; ??I find that section of the PEP significantly lacking in details and motivation.<br></blockquote><div>??</div><div>I agree.</div><div>??</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

&quot;Unpacking a long-double will return a decimal object or a ctypes long-double.&quot;<br>
<br>
Returning a Decimal object here doesn&#39;t make a lot of sense, since Decimal objects aren&#39;t generally compatible with floats. ??And ctypes long double objects don&#39;t seem to exist, as far as I can tell. ??It might be better not to add this code.</blockquote>
<div><br></div><div>And under what conditions would a ctype long double be used vs. a Decimal object.</div><div>??</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
??</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Another bit that&#39;s not clear to me: ??how is unpacking an object pointer expected to work, and how would it typically be used? ??What if the unpacked pointer no longer points to a valid Python object? ??How would this work in other Python implementations?<br>
</blockquote><div><br></div><div>I guess if an object associated with the packed address does not exist, then you would unpack None (?). ??This is especially a problem if the struct-sting is being sent over the wire to another machine.</div>
<div>??</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
For the &#39;X{}&#39; format (pointer to a function), is this supposed to mean a Python function or a C function?<br></blockquote><div><br></div><div>I read that as a Python function. ??However, I am not completely sure how the prototype would be enforced when unpacking. ??I am also wondering, though, how the signatures on pointers-to-functions are specified? ??Are the??arguments and return type full struct strings as well?</div>
<div>??</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
What&#39;s a &#39;specific pointer&#39;?</blockquote><div><br></div><div>I think this means a pointer to a specific type, e.g. &#39;&amp;d&#39; is a pointer to a double. If this is the case, though, the use cases are not completely clear to me.</div>
</div><br>I also have the following questions:
<div><br></div><div><div>* Can pointers be nested, &#39;&amp;&amp;d&#39; ?</div><div>* What nesting level can structures have? Arbitrary?</div><div>* The new array syntax claims &quot;multi-dimensional array of whatever follows&quot;. ??</div>
<div>????Truly whatever? Arrays of structures? Arrays of pointers?</div><div>* &quot;complex (whatever the next specifier is)&quot;. ??Not really &#39;whatever&#39;. ??You</div><div>????can not have a &#39;complex bool&#39; or &#39;complex int&#39;. ??What other types of</div>
<div>????complex are there besides complex double?</div><div>* How do array specifiers and pointer specifiers mix? ??For example, would</div><div>????&#39;(2, 2)&amp;d&#39; be a two-by-two array of pointers to doubles? ??What about</div>
<div>????&#39;&amp;(2, 2)d&#39;? ??Is this a pointer to an two-by-two array of doubles?</div><div><br></div><div>The new features of the struct-string syntax are so different that I think we??</div><div>need to specify a grammar. ??I think it will clarify some of the open</div>
<div>questions. ??</div><div><br></div><div>In addition, I was thinking that a reasonable implemenation strategy would</div><div>be to keep the current struct-string syntax mostly in place within the C module??</div><div>implementation. ??The C implementation would just provide an interface to??</div>
<div>pack\unpack sequences of primitive data elements. ??Then we could write a??</div><div>layer in the Python &#39;struct&#39; module that took care of the higher-order??</div><div>concepts like nested structures, arrays, named values, and pointers to</div>
<div>functions. ??The higher-order concepts would be mapped to the appropriate</div><div>primitive sequence strings.</div><div><br></div><div>I think this will simplify the implementation and will provide a way to phase</div>
<div>it. ??We can implement the primitive type extensions in C first followed by</div><div>the higher-level Python stuff. ??The result of each phase is immediately usuable.</div><div><br></div><div>I have attached a patch against the PEP containing my current thoughts on</div>
<div>fleshing out the grammar and some of the current open questions. ??This still needs work, but I wanted to share to see if I am on the right track. ??Please??advise on how to proceed.</div></div>
-------------- next part --------------
Index: pep-3118.txt
===================================================================
--- pep-3118.txt	(revision 78193)
+++ pep-3118.txt	(working copy)
@@ -637,9 +637,54 @@
 ctypes and NumPy for example).  The Python 2.5 specification is 
 at http://docs.python.org/library/struct.html.
 
-Here are the proposed additions:
+The grammar of the original struct string-syntax is very simple.  It consist of
+a byte-order specifier followed by a character code which may optionally be 
+preceded by a numeric count::
 
+   struct-string ::= <byte-order-specifier> (<count> <code>)*
+   byte-order-specifier ::= '!' | '@' | '=' | '>' | '<' | '^'
+   count ::= <integer>
+   code ::= 'x' | 'c' | 'b' | 'B' | '?' | 'h' | 'H' | 'i' | 'I' | 'l' | 'L'
+          | 'q' | 'Q' | 'f' | 'd' | 's' | 'p' | 'P'
 
+The proposed additions will extend this syntax by adding support for new
+primitive types, name specifiers, detailed structure layout, and 
+function-pointers.  The  high-level structure of the new syntax is::
+
+   struct-string ::= (<type-string> <name-specifier>?)*
+   type-string ::= <primitive>
+                 | <structure>
+                 | <pointer-to-function>
+
+The struct module will be changed to understand this new syntax  and
+return appropriate Python objects on unpacking.  White-space in the 
+struct-string syntax will be ignored, if it isn't already.  The details
+of the grammar elements *primitive*, *name-specifier*, *structure*, 
+and *pointer-to-function* are described in the following sub-sections.
+
+In addition to implementing this new syntax, functions should be added to 
+ctypes to create a ctypes object from a struct description, and add 
+long-double, and ucs-2 to ctypes.
+
+Primitive Extensions
+---------------------
+
+The extenstions to the primitive data types will provide new type codes,
+the ability to change byte-order mid-stream, and a way to specify pointers 
+to data::
+
+   primitive ::= <byte-order-specifier> <count>? <array-specifier>? <pointer-specifier>+ <code>
+   byte-order-specifier ::= '!' | '@' | '=' | '>' | '<' | '^'
+   count ::= <integer>
+   pointer-specifier ::= '&'
+   array-specifier ::= '(' <integer> (',' <integer>)* ')'
+   code ::= 'x' | 'c' | 'b' | 'B' | '?' | 'h' | 'H' | 'i' | 'I' | 'l' | 'L'
+          | 'q' | 'Q' | 'f' | 'd' | 's' | 'p' | 'P' | 't' | 'g' | 'u' | 'w' 
+          | 'O' | 'Z'
+
+The new *code* types and modifications to old *code* types are described as 
+follows:
+
 ================  ===========
 Character         Description
 ================  ===========
@@ -650,45 +695,75 @@
 'u'               ucs-2 
 'w'               ucs-4 
 'O'               pointer to Python Object 
-'Z'               complex (whatever the next specifier is)
-'&'               specific pointer (prefix before another character) 
-'T{}'             structure (detailed layout inside {}) 
-'(k1,k2,...,kn)'  multi-dimensional array of whatever follows 
-':name:'          optional name of the preceeding element 
-'X{}'             pointer to a function (optional function 
-                    signature inside {} with any return value
-                    preceeded by -> and placed at the end)
+'Z'               complex
 ================  ===========
 
-The struct module will be changed to understand these as well and
-return appropriate Python objects on unpacking.  Unpacking a
-long-double will return a decimal object or a ctypes long-double.
-Unpacking 'u' or 'w' will return Python unicode.  Unpacking a
-multi-dimensional array will return a list (of lists if >1d).
-Unpacking a pointer will return a ctypes pointer object. Unpacking a
-function pointer will return a ctypes call-object (perhaps). Unpacking
-a bit will return a Python Bool.  White-space in the struct-string
-syntax will be ignored if it isn't already.  Unpacking a named-object
-will return some kind of named-tuple-like object that acts like a
-tuple but whose entries can also be accessed by name. Unpacking a
-nested structure will return a nested tuple.
+The *pointer-specifier* is used to denote a pointer to a specified type.  
+For example, '&g' represents a pointer to a long-double and '&&I' respresents
+a pointer to a pointer to an unsigned integer.
 
-Endian-specification ('!', '@','=','>','<', '^') is also allowed
-inside the string so that it can change if needed.  The
-previously-specified endian string is in force until changed.  The
-default endian is '@' which means native data-types and alignment.  If
-un-aligned, native data-types are requested, then the endian
+The *array-specifier* is used to denote homogenous multi-dimensional areas
+of memory.  The type-code immediately following the array-specifier denotes
+the type of the elements in that memory area.  This extension also allows 
+specifying if the data is supposed to be viewed as a (C-style contiguous, 
+last-dimension varies the fastest) multi-dimensional array of a particular 
+format.
+
+The *byte-order-specifier* is now allowed inside the string so that it can 
+change if needed.  The previously specified byte-order specifier is in force 
+until changed.  The default byte-order is '@' which means native data-types and 
+alignment.  If un-aligned, native data-types are requested, then the byte-order
 specification is '^'.
 
-According to the struct-module, a number can preceed a character
-code to specify how many of that type there are.  The
-``(k1,k2,...,kn)`` extension also allows specifying if the data is
-supposed to be viewed as a (C-style contiguous, last-dimension
-varies the fastest) multi-dimensional array of a particular format.
+The following unpacking requirements must be met:
 
-Functions should be added to ctypes to create a ctypes object from
-a struct description, and add long-double, and ucs-2 to ctypes.
+* a long-double will return a decimal object or a ctypes long-double.
+* 'u' or 'w' will return Python unicode.  
+* a multi-dimensional array will return a list (of lists if >1d).
+* a pointer will return a ctypes pointer object. 
+* a bit will return a Python Bool. 
+* a pointer to a Python Object will return the Python Object associated with
+  the address encoded in the struct-string if a Python Object of that address
+  exist.  Otherwise, None is returned.
 
+Named Specifier
+---------------
+The name specifier is used to associate names with values in the struct-string::
+
+   name-specifier := ':' <string> ':'
+
+The following unpacking requirements must be met:
+
+* a named-object will return some kind of named-tuple-like object 
+  that acts like a tuple but whose entries can also be accessed by name.
+
+
+Structure Layout
+----------------
+The new structure layout syntax provides a way to specify a detailed
+structure layout::
+
+   structure := 'T' '{' <struct-string> '}'
+
+Structures may be arbitrarily nested.
+
+The following unpacking requirements must be met:
+
+* Unpacking a nested structure will return a nested tuple.
+
+
+Pointer to Functions
+--------------------
+The pointer to a function syntax provides a way to specify ...::
+
+   pointer-to-function := 'X' '{' <signature>? '}
+   signature := <struct-string> '->' <string-string>
+
+The following unpacking requirements must be met:
+
+* a function pointer will return a ctypes call-object (perhaps). 
+
+
 Examples of Data-Format Descriptions
 ====================================
 

From report at bugs.python.org  Wed Feb 17 05:01:18 2010
From: report at bugs.python.org (David Beazley)
Date: Wed, 17 Feb 2010 04:01:18 +0000
Subject: [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: <1266379278.52.0.0540866647566.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

The comment on the CPU-bound workload is valid--it is definitely true that Python 2.6 results will degrade as the workload of each tick is increased.   Maybe a better way to interpreter those results is as a baseline of what kind of I/O performance is possible if there is a quick I/O response time.

However, ignoring that and the comparison between Python 2.6 and 3.2, there is still a serious performance issue with I/O in 3.2.  For example, the dramatic decrease in I/O performance as there are more CPU bound threads competing and the fact that there is a huge performance gain when all but one CPU core is disabled. 

I tried the test using UDP packets and get virtually the exact same behavior described.  For instance, echoing 10MB (sent in 8k UDP packets) takes about 0.6s in Python 2.6 and 12.0s in Python-3.2.   The time shoots up to more than 40s if there are two CPU-bound threads. 

The problem being described really doesn't have anything to do with TCP vs. UDP or any part of the network stack.  It has everything to do with how the operating system buffers I/O requests and how I/O operations such as sends and receives complete immediately without blocking depending on system buffer characteristics (e.g., if there is space in the send buffer, a send will return immediately without blocking).   The fact that the GIL is released when it's not necessary in these cases is really the source of the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Wed Feb 17 07:58:26 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 17 Feb 2010 06:58:26 +0000
Subject: [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: <1266389906.31.0.0262871764409.issue7939@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

You are right - I should read the docs, but one of the outstanding features of Python is that in many cases you can test the code faster than read documentation. =) It would help if ["ls", "-la"] example included third argument thus fully covering the concept.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7939>
_______________________________________

From report at bugs.python.org  Wed Feb 17 11:08:43 2010
From: report at bugs.python.org (Andrew Clegg)
Date: Wed, 17 Feb 2010 10:08:43 +0000
Subject: [issue7846] Fnmatch cache is never cleared during usage
In-Reply-To: <1265209336.56.0.865162695939.issue7846@psf.upfronthosting.co.za>
Message-ID: <1266401323.84.0.579156758147.issue7846@psf.upfronthosting.co.za>


Andrew Clegg <ancl at pml.ac.uk> added the comment:

"If you give something an _, then it is not considered part of the public API and it (the internal API, not the value) is subject to change, which means you should *not* suggest that users change it.  If they find it and want to change it anyway, that's their lookout.  That's the consenting adults part :)"

This sums it up well - it should be considered a detail of implementation, thus the _. When I said I wanted to allow the value to be modified, I was thinking of the 'consenting adult' type of usage, not everyday usage. Of course there is no reasonable way to prevent the value being modified anyway.

So - _MAXCACHE can stay where it is, but should not be documented or be included in __all__. Does that seem reasonable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7846>
_______________________________________

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: [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  Wed Feb 17 12:55:25 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 17 Feb 2010 11:55:25 +0000
Subject: [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: <1266407725.31.0.993539758934.issue7950@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This was just discussed in issue 6760.

----------
nosy: +eric.smith
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> patch to subprocess docs to better explain Popen's 'args' argument

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7950>
_______________________________________

From report at bugs.python.org  Wed Feb 17 13:16:39 2010
From: report at bugs.python.org (Paul Boddie)
Date: Wed, 17 Feb 2010 12:16:39 +0000
Subject: [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: <1266408999.62.0.657656971346.issue7942@psf.upfronthosting.co.za>


Paul Boddie <paul at boddie.org.uk> added the comment:

I don't disagree that OverflowError describes what's happening, but the need to convert to an int in the first place is a detail of the machine - you'd have to know that this is a limitation of whatever internal "protocol" CPython implements - not a description of the cause of the error, which is what the old-style message describes quite clearly.

On the subject of whether __len__ should be able to return long integers, GvR seems to like the idea (from the related bug mentioned earlier):

http://bugs.python.org/issue2690#msg70525

I'll take a closer look at the mechanisms for error reporting around this situation later, but my assertion is that the new-style message isn't as helpful as the old-style one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7942>
_______________________________________

From report at bugs.python.org  Wed Feb 17 13:58:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Feb 2010 12:58:57 +0000
Subject: [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: <1266411537.31.0.225581836105.issue7942@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Interestingly, this (len returning something larger than ssize_t) has not been fixed in python3.

On the other hand, I still think the new-style message is better.  Yes, it is an implementation detail of CPython, but that is exactly the error being reported.  Another implementation might successfully return the value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7942>
_______________________________________

From report at bugs.python.org  Wed Feb 17 14:01:57 2010
From: report at bugs.python.org (Alex Willmer)
Date: Wed, 17 Feb 2010 13:01:57 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1266411717.35.0.382904111913.issue2636@psf.upfronthosting.co.za>


Alex Willmer <alex at moreati.org.uk> added the comment:

I've packaged this latest revision and uploaded to PyPI http://pypi.python.org/pypi/regex

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Feb 17 15:36:53 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 17 Feb 2010 14:36:53 +0000
Subject: [issue7593] Computed-goto patch for RE engine
In-Reply-To: <1262052691.46.0.772398622751.issue7593@psf.upfronthosting.co.za>
Message-ID: <1266417413.71.0.972191323045.issue7593@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

I finally got around to benchmarking this change, and unfortunately the results are not good.

I used the regex tests in the Unladen Swallow test suite, regex_effbot and regex_v8.  The tests are written for Python 2.x, but the fixes for 3.x are straightforward (use print() in one function; replace xrange with range in the bm_regex_effbot.py and bm_regex_v8.py files; remove a few uses of u''; I'll provide a patch later.)

Hardware: MacBook, Intel Core 2 Duo, 1.83GHz, 2MB L2 cache, 667 MHz bus.

Tests invoked with ./perf.py -b regex_effbot -r -v ../py3k/python.exe ../threaded-3000/python.exe

regex_effbot is 1.1002 times slower with the computed-goto patch, and 
regex_v8 is 1.0081x slower.  perf.py indicates that both results are significant.

I'd like to see a few people replicate these results -- maybe the effect is very platform dependent or I ran the tests incorrectly -- but on current evidence, this patch is not worth pursuing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7593>
_______________________________________

From report at bugs.python.org  Wed Feb 17 16:12:27 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 17 Feb 2010 15:12:27 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1266419547.63.0.190956857972.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> And under what conditions would a ctype long double be used vs. a
> Decimal object.

Well, I'm guessing that this was really just an open question for the PEP, and that the PEP authors hadn't decided which of these two options was more appropriate.  If all long doubles were converted to Decimal, then we need to determine what precision is appropriate to use for the conversion: any long double *can* be represented exactly as a Decimal, but to get an exact representation can need thousands of digits in some cases, so it's probably better to always round to some fixed number of signficant digits.  36 significant digits is a reasonable choice here: it's the minimum number of digits that's guaranteed to distinguish two distinct long doubles, for the case where a long double has 113 bits of precision (i.e., IEEE 754 binary128 format);  other common long double formats have smaller precision than this (usually 53 (normal double), 64 (x87 extended doubles), or 106 (double double)).  There would probably also need to be some way to 'repack' the Decimal instance.

The 'platform long double -> Decimal' conversion itself would also be nontrivial to implement;  I can lend a hand here if you want it.

Using ctypes makes more sense to me, since it doesn't involve trying to mix decimal and binary, except that I don't know whether it's acceptable for other standard library modules to have dependencies on ctypes.  I'm not sure whether ctypes is available on all platforms that Python runs on. It's also a bit ugly that, depending on the platform, sometimes a long double will unpack to an instance of ctypes.long_double, and sometimes (when long double == double) to a regular Python float.

Anyway, this particular case (long double) isn't a big deal:  it can be overcome, one way or another.  I'm more worried about some of the other aspects of the changes.

[About unpacking with the 'O' format.]
> I guess if an object associated with the packed address does not
> exist, then you would unpack None (?).  This is especially a problem 
> if the struct-sting is being sent over the wire to another machine.

And how do you determine whether an address gives a valid object or not?  I can only assume that packing and unpacking with the 'O' format is only supposed to be used in certain restricted circumstances, but it's not clear to me what those circumstances are.

> I also have the following questions: [...]

I think a lot of this discussion needs to go back to python-dev;  with luck, we can get some advice and clarifications from the PEP authors there.  I'm not sure whether it's appropriate to modify the original PEP (especially since it's already accepted), or whether it would be better to produce a separate document describing the proposed changes in detail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Wed Feb 17 16:13:59 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 17 Feb 2010 15:13:59 +0000
Subject: [issue7593] Computed-goto patch for RE engine
In-Reply-To: <1262052691.46.0.772398622751.issue7593@psf.upfronthosting.co.za>
Message-ID: <1266419639.1.0.451739250165.issue7593@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Actually, I really want someone to verify that measurement.  As a control, I tried running the call_method benchmark (after a few more xrange fixes).  The Python 3.x trunk version with my patch is measured as 1.0227x slower, even though the patch only touches the re module and call_method doesn't use the module at all.  I recompiled both binaries; both builds are using the same compiler arguments; both have the same version from trunk.  I'm mystified about why the patched version is slower.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7593>
_______________________________________

From report at bugs.python.org  Wed Feb 17 16:18:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 17 Feb 2010 15:18:09 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1266419889.34.0.751975275297.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm looking for previous discussions of this PEP.  There's a python-dev thread in April 2007:

http://mail.python.org/pipermail/python-dev/2007-April/072537.html

Are there other discussions that I'm missing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Wed Feb 17 17:30:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 17 Feb 2010 16:30:45 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1266424245.73.0.803241563647.issue7633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The latest patch looks fine.  I've attached a slightly tweaked version:

 - Add conversions for number_class;  without this, number_class is inconsistent with the various is_*** methods.  "c.is_normal(3)" should be equivalent to "c.number_class(3) in ('+Normal', '-Normal)", for example.

 - Remove conversions for 'canonical' and 'is_canonical';  I agree with Stefan that these don't make a lot of sense.  It's mostly academic, since I can't imagine either of these methods gets much use.

 - I've reworded the documentation slightly.

 - Remove lots of trailing whitespace (mostly on otherwise empty lines).

If this looks okay to everyone, I'll check it in.

----------
Added file: http://bugs.python.org/file16245/issue7633_jjconti4_metd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Wed Feb 17 17:38:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 17 Feb 2010 16:38:23 +0000
Subject: [issue7299] setup.py install doesn't honor PYTHONUSERBASE
In-Reply-To: <1257857799.68.0.397965237537.issue7299@psf.upfronthosting.co.za>
Message-ID: <1266424703.38.0.91151257734.issue7299@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

It seems to me that your patch doesn?t fix a bug but adds a feature. PEP?370 says that ?distutils.command.install (setup.py install) gets a new argument --user to install packages in the user site directory?, not that the presence of the envvar should trigger the user install scheme.

Can you give a link to the original bug report?

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7299>
_______________________________________

From report at bugs.python.org  Wed Feb 17 19:41:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Feb 2010 18:41:16 +0000
Subject: [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: <1266432076.52.0.109375726675.issue7946@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

We could try not to release the GIL when socket methods are called on a non-blocking socket.

Regardless, I've re-run the tests under the Linux machine, with two spinning threads:

* python 2.7: 
25.580 seconds (409914.612 bytes/sec)
* python 3.2:
32.216 seconds (325485.029 bytes/sec)

(and as someone mentioned, the "priority requests" mechanism which was in the original new GIL patch might improve things. It's not an ideal time for me to test, right now :-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Wed Feb 17 19:50:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Feb 2010 18:50:15 +0000
Subject: [issue7593] Computed-goto patch for RE engine
In-Reply-To: <1262052691.46.0.772398622751.issue7593@psf.upfronthosting.co.za>
Message-ID: <1266432615.26.0.80005625683.issue7593@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You should disassemble the output (or produce assembler from gcc) and check that the various indirect jumps at the end of each case block don't get merged into a single shared indirect jump.

Or perhaps it's simply that regular expression matching isn't really sensitive to bytecode dispatch overhead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7593>
_______________________________________

From report at bugs.python.org  Wed Feb 17 20:35:46 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 17 Feb 2010 19:35:46 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1266435346.5.0.870584792242.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

The main text at http://pypi.python.org/pypi/regex appears to have lost its backslashes, for example:

    The Unicode escapes uxxxx and Uxxxxxxxx are supported.

instead of:

    The Unicode escapes \uxxxx and \Uxxxxxxxx are supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Feb 17 22:09:38 2010
From: report at bugs.python.org (mARK)
Date: Wed, 17 Feb 2010 21:09:38 +0000
Subject: [issue7904] urlparse.urlsplit mishandles novel schemes
In-Reply-To: <1265844290.89.0.139975092944.issue7904@psf.upfronthosting.co.za>
Message-ID: <1266440978.63.0.0951820809709.issue7904@psf.upfronthosting.co.za>


mARK <python.mbloore at xoxy.net> added the comment:

Doing a fallback test for // would look like
if scheme in uses_netloc and url[:2] == '//' or url[:2] == '//':

but this is equivalent to 
if url[:2] == '//':

i.e., an authority appears if and only if there is a // after the scheme.

This still allows a uses_netloc scheme to appear without //.

I have attached a patch against Python 2.7, svn revision 78212.  It adds s3 to netloc.

----------
Added file: http://bugs.python.org/file16246/fix7904-2.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7904>
_______________________________________

From report at bugs.python.org  Thu Feb 18 00:43:27 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Wed, 17 Feb 2010 23:43:27 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1266450207.35.0.249463945425.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

I just tested the fix for unicode tracebacks and found some possibly weird results (not sure how/whether it should be fixed, as these inputs are indeed rather artificial...).
(win XPp SP3 Czech, Python 2.6.4)

Using the cmd console, the output is fine (for the characters it can accept and display)

>>> regex.findall(ur"\p{InBasicLatin?}", u"a?")
Traceback (most recent call last):
...
  File "C:\Python26\lib\regex.py", line 1244, in _parse_property
    raise error("undefined property name '%s'" % name)
regex.error: undefined property name 'InBasicLatin?'
>>>

(same result for other distorted "proprety names" containing e.g. ??????????????i???? ...

However, in Idle the output differs depending on the characters present

>>> regex.findall(ur"\p{InBasicLatin?}", u"ab c")
yields the expected
...
  File "C:\Python26\lib\regex.py", line 1244, in _parse_property
    raise error("undefined property name '%s'" % name)
error: undefined property name 'InBasicLatin?'

but

>>> regex.findall(ur"\p{InBasicLatin?}", u"ab c")

Traceback (most recent call last):
...
  File "C:\Python26\lib\regex.py", line 1244, in _parse_property
    raise error("undefined property name '%s'" % name)
  File "C:\Python26\lib\regex.py", line 167, in __init__
    message = message.encode(sys.stdout.encoding)
  File "C:\Python26\lib\encodings\cp1250.py", line 12, in encode
    return codecs.charmap_encode(input,errors,encoding_table)
UnicodeEncodeError: 'charmap' codec can't encode character u'\xcc' in position 37: character maps to <undefined>
>>> 

which might be surprising, as cp1250 should be able to encode "?", maybe there is some intermediate ascii step?

using the wxpython pyShell I get its specific encoding error:

regex.findall(ur"\p{InBasicLatin?}", u"ab c")
Traceback (most recent call last):
...
  File "C:\Python26\lib\regex.py", line 1102, in _parse_escape
    return _parse_property(source, info, in_set, ch)
  File "C:\Python26\lib\regex.py", line 1244, in _parse_property
    raise error("undefined property name '%s'" % name)
  File "C:\Python26\lib\regex.py", line 167, in __init__
    message = message.encode(sys.stdout.encoding)
AttributeError: PseudoFileOut instance has no attribute 'encoding'

(the same for \p{InBasicLatin?} etc.)


In python 3.1 in Idle, all of these exceptions are displayed correctly, also in other scripts or with special characters.

Maybe in python 2.x e.g. repr(...) of the unicode error messages could be used in order to avoid these problems, but I don't know, what the conventions are in these cases.


Another issue I found here (unrelated to tracebacks) are backslashes or punctuation (except the handled -_) in the property names, which just lead to failed mathces and no exceptions about unknown property names

regex.findall(u"\p{InBasic.Latin}", u"ab c")
[]


I was also surprised by the added pos/endpos parameters, as I used flags as a non-keyword third parameter for the re functions in my code (probably my fault ...)

re.findall(pattern, string, flags=0)

regex.findall(pattern, string, pos=None, endpos=None, flags=0, overlapped=False)

(is there a specific reason for this order, or could it be changed to maintain compatibility with the current re module?)

I hope, at least some of these remarks make some sense;
  thanks for the continued work on this module!

   vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

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: [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: [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: [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:48:06 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Feb 2010 00:48:06 +0000
Subject: [issue7953] RawIOBase.read fails with an AttributeError
In-Reply-To: <1266453866.93.0.344169930807.issue7953@psf.upfronthosting.co.za>
Message-ID: <1266454086.34.0.962224978576.issue7953@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

If you want the actual raw sys.stdin stream, use sys.stdin.buffer.raw.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7953>
_______________________________________

From report at bugs.python.org  Thu Feb 18 01:54:13 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Feb 2010 00:54:13 +0000
Subject: [issue7953] RawIOBase.read fails with an AttributeError
In-Reply-To: <1266453866.93.0.344169930807.issue7953@psf.upfronthosting.co.za>
Message-ID: <1266454453.27.0.883307061126.issue7953@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Also note that RawIOBase is not intended to be a concrete class, it is intended to be subclassed (thus the 'Base' in the name).

----------
nosy: +r.david.murray
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7953>
_______________________________________

From report at bugs.python.org  Thu Feb 18 02:22:47 2010
From: report at bugs.python.org (Andrew McNabb)
Date: Thu, 18 Feb 2010 01:22:47 +0000
Subject: [issue7954] detach method has no docstring
In-Reply-To: <1266454423.14.0.91704717974.issue7954@psf.upfronthosting.co.za>
Message-ID: <1266456167.71.0.672349998034.issue7954@psf.upfronthosting.co.za>


Andrew McNabb <amcnabb at mcnabbs.org> added the comment:

Oops.  I had run "pydoc" instead of "pydoc3", so I was getting the 2.6 version of the io docstrings instead of the 3.1 version.

By the way, it took about an hour to find out how to get Python 3 to treat stdin as bytes instead of unicode.  Now that I know what I was looking for, the documentation for the io library seems fine.  However, since Python 3 uptake is still a little slow, it's really hard to search for good information out there.

Would it be possible to some tutorial-style information to the io library documentation?  Stuff like switching stdin and stdout to bytes mode seem like they will be common problems, and it's a bit overwhelming to sort through 14 pages of documentation.  I think for most readers, it would be helpful to start with a brief tutorial before lunging into the hierarchy of abstract classes.

Overall, the documentation is great; it's detailed and complete.  If there's one weakness, it's the overview.

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7954>
_______________________________________

From report at bugs.python.org  Thu Feb 18 02:27:13 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 18 Feb 2010 01:27:13 +0000
Subject: [issue7954] detach method has no docstring
In-Reply-To: <1266456167.71.0.672349998034.issue7954@psf.upfronthosting.co.za>
Message-ID: <1afaf6161002171727o4a423208l1876b9d18a693e4f@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/2/17 Andrew McNabb <report at bugs.python.org>:
>
> Andrew McNabb <amcnabb at mcnabbs.org> added the comment:
>
> Oops. ?I had run "pydoc" instead of "pydoc3", so I was getting the 2.6 version of the io docstrings instead of the 3.1 version.
>
> By the way, it took about an hour to find out how to get Python 3 to treat stdin as bytes instead of unicode. ?Now that I know what I was looking for, the documentation for the io library seems fine. ?However, since Python 3 uptake is still a little slow, it's really hard to search for good information out there.

There's a note here: http://docs.python.org/py3k/library/sys#sys.stdin

>
> Would it be possible to some tutorial-style information to the io library documentation? ?Stuff like switching stdin and stdout to bytes mode seem like they will be common problems, and it's a bit overwhelming to sort through 14 pages of documentation. ?I think for most readers, it would be helpful to start with a brief tutorial before lunging into the hierarchy of abstract classes.
>
> Overall, the documentation is great; it's detailed and complete. ?If there's one weakness, it's the overview.

Yes, but that's another issue. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7954>
_______________________________________

From report at bugs.python.org  Thu Feb 18 02:36:40 2010
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Thu, 18 Feb 2010 01:36:40 +0000
Subject: [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: <1266457000.48.0.280791340247.issue7952@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

Correction: when input is followed by output, the call needed to avoid undefined behaviour has to be to a "file positioning function" (fseek, fsetpos, or rewind, but not fflush). Since fileobject.c does not use wide I/O operations, it should be sufficient to use _portable_fseek(fp, 0, SEEK_SET).

(_portable_fseek may call some function that is not strictly defined to be a "file positioning function", e.g. fseeko() or fseek64(). However, it would be insane for a stdio implementation not to treat those as being file positioning functions as far as the intent of the C or POSIX standards is concerned.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7952>
_______________________________________

From report at bugs.python.org  Thu Feb 18 04:03:21 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 18 Feb 2010 03:03:21 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1266462201.47.0.34431371295.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20100218.zip is a new version of the regex module.

I've added '.' to the permitted characters when parsing the name of a property. The name itself is no longer reported in the error message.

I've also corrected the positions of the 'pos' and 'endpos' arguments:

    regex.findall(pattern, string, flags=0, pos=None, endpos=None, overlapped=False)

----------
Added file: http://bugs.python.org/file16247/issue2636-20100218.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

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: [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 11:05:40 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 18 Feb 2010 10:05:40 +0000
Subject: [issue7712] Add a context manager to change cwd in test.test_support
	and run the test suite in a temp dir.
In-Reply-To: <1263620547.47.0.155851687393.issue7712@psf.upfronthosting.co.za>
Message-ID: <1266487540.5.0.837933284239.issue7712@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Ported to py3k in r78214. I will think about the cleanups later, they are not so important right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7712>
_______________________________________

From report at bugs.python.org  Thu Feb 18 13:09:48 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 18 Feb 2010 12:09:48 +0000
Subject: [issue5604] imp.find_module() mixes UTF8 and MBCS
In-Reply-To: <1238423201.33.0.732435229283.issue5604@psf.upfronthosting.co.za>
Message-ID: <1266494988.63.0.919775915644.issue5604@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Still an issue for some buildbot:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/1487
http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/1491


It is loosely related with #7712, because now the tests are run in TEMP (on C:) instead of the build dir (on D:).

----------
keywords: +buildbot
nosy: +ezio.melotti, flox
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5604>
_______________________________________

From report at bugs.python.org  Thu Feb 18 13:26:55 2010
From: report at bugs.python.org (Michael Newman)
Date: Thu, 18 Feb 2010 12:26:55 +0000
Subject: [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 13:55:53 2010
From: report at bugs.python.org (Paul Boddie)
Date: Thu, 18 Feb 2010 12:55:53 +0000
Subject: [issue7942] Inconsistent error types/messages for __len__ (and
	__nonzero__) between old and new-style classes
In-Reply-To: <1266341801.65.0.120911514825.issue7942@psf.upfronthosting.co.za>
Message-ID: <1266497753.63.0.823614170959.issue7942@psf.upfronthosting.co.za>


Paul Boddie <paul at boddie.org.uk> added the comment:

Actually, in the issue reported, the initial problem occurs in the evaluation of an object in a boolean context (and the subsequent problem occurs with an explicit len invocation):

http://www.selenic.com/pipermail/mercurial/2010-February/030066.html

Presumably (from memory and a brief look at the reference), when "if data:" is evaluated, Python attempts to invoke an instance's __nonzero__ method or its __len__ method. Since the mercurial.httprepo.httpsendfile class only provides a __len__ method, the __len__ method's return value is used to determine truth.

The following demonstrates this particular issue:

>>> class C:
...     def __len__(self):
...             return 2**35
...
>>> c = C()
>>> if c: pass
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __nonzero__ should return an int
>>> class C(object):
...     def __len__(self):
...             return 2**35
...
>>> c = C()
>>> if c: pass
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to int

Here, I could actually argue that the message mentioning __nonzero__ is obscure: there isn't such a method defined, and __len__ is the misbehaving method. Still, in the context of boolean evaluation, the OverflowError is less helpful than it could be.

----------
title: Inconsistent error types/messages for __len__ between old and new-style classes -> Inconsistent error types/messages for __len__ (and __nonzero__) between old and new-style classes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7942>
_______________________________________

From report at bugs.python.org  Thu Feb 18 14:00:11 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 18 Feb 2010 13:00:11 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1266498011.58.0.82580390932.issue7633@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

It looks good (I agree on number_class), but I'd change these:

  - Add raiseit=True to context.copy_decimal()

  - Remove wrong comment from context.is_infinite()

  - Add _convert_other(a, raiseit=True) to context.logical_invert()

  - More whitespace in test_decimal()



The new tests could be condensed quite a bit by using getattr(), but
that isn't so important.

----------
Added file: http://bugs.python.org/file16251/issue7633_jjconti5_metd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

From report at bugs.python.org  Thu Feb 18 14:23:18 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 18 Feb 2010 13:23:18 +0000
Subject: [issue5604] imp.find_module() mixes UTF8 and MBCS
In-Reply-To: <1238423201.33.0.732435229283.issue5604@psf.upfronthosting.co.za>
Message-ID: <1266499398.31.0.626817846624.issue5604@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Also the test has a few problems:
1) the keys of known_locales are lowercase, but locale_encoding = locale.getpreferredencoding() can return uppercase encodings (e.g. UTF-8);
2) this masks another error: the b'\xe4' is not a valid utf-8 byte and it can be decoded;
3) the test should be skipped properly if the preferred encoding is not among the ones of the known_locales dict;
4) the 'encoded_char' should be 'decoded_char'.

It seems that in the failure linked by Florent, find_module tries to encode the filename with the wrong encoding and with error='replace' and the char at the end of 'test_imp_helper_' is converted to U+FFFD.
If the file is created with the correct name (e.g. 'test_imp_helper_\xc0') and find_module tries to search the wrong name (i.e. 'test_imp_helper_\ufffd'), then the error is raised (but then cp1252 used by the terminal can't encode that char and the second exception is raised).
Now the tests are run on C: and the filesystem encoding might be different, so it might not match anymore the encoding returned by locale.getpreferredencoding().

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5604>
_______________________________________

From report at bugs.python.org  Thu Feb 18 15:05:46 2010
From: report at bugs.python.org (Christoph Neuroth)
Date: Thu, 18 Feb 2010 14:05:46 +0000
Subject: [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: <1266501946.05.0.103947722629.issue7950@psf.upfronthosting.co.za>


Christoph Neuroth <christoph.neuroth at googlemail.com> added the comment:

You're right, that has been improved in regard to how you can do it instead. However, I still think it lacks to mention the security risk involved - compare this to e.g. os.tempnam(), which has a warning in a red box.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7950>
_______________________________________

From report at bugs.python.org  Thu Feb 18 15:17:45 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 18 Feb 2010 14:17:45 +0000
Subject: [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: <1266502665.79.0.548638290506.issue7950@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

If you want to generate some more discussion, I suggest you close this issue and reopen the other one, since that has more people on the nosy list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7950>
_______________________________________

From report at bugs.python.org  Thu Feb 18 15:24:11 2010
From: report at bugs.python.org (Christoph Neuroth)
Date: Thu, 18 Feb 2010 14:24:11 +0000
Subject: [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: <1266503051.2.0.694095035317.issue7950@psf.upfronthosting.co.za>


Christoph Neuroth <christoph.neuroth at googlemail.com> added the comment:

Good idea :)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7950>
_______________________________________

From report at bugs.python.org  Thu Feb 18 15:28:49 2010
From: report at bugs.python.org (Christoph Neuroth)
Date: Thu, 18 Feb 2010 14:28:49 +0000
Subject: [issue6760] patch to subprocess docs to better explain Popen's 'args'
	argument
In-Reply-To: <1250937633.23.0.298701528399.issue6760@psf.upfronthosting.co.za>
Message-ID: <1266503329.94.0.308030221297.issue6760@psf.upfronthosting.co.za>


Christoph Neuroth <christoph.neuroth at googlemail.com> added the comment:

As recommended by eric.smith on #7950, I'd like to suggest further extending the documentation to include a security warning about (quite easily) possible code injection bugs when using the shell=True parameter (similar to other places in the documentation).

----------
nosy: +christoph.neuroth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6760>
_______________________________________

From report at bugs.python.org  Thu Feb 18 15:53:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 18 Feb 2010 14:53:08 +0000
Subject: [issue7633] decimal.py: type conversion in context methods
In-Reply-To: <1262610073.25.0.98727322064.issue7633@psf.upfronthosting.co.za>
Message-ID: <1266504788.32.0.14359236074.issue7633@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Tweaked some doctests in r78218:

- add integer argument doctest for logical_invert
- fix integer literals with a leading zero for the other logical_***
  methods, since they're illegal in Python 3.

Merged to py3k in r78219.

Thanks, everyone!

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7633>
_______________________________________

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: [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:28:43 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 18 Feb 2010 15:28:43 +0000
Subject: [issue7957] Tutorial issue regarding the sys module
In-Reply-To: <1266505107.41.0.314960086696.issue7957@psf.upfronthosting.co.za>
Message-ID: <1266506923.07.0.885997939933.issue7957@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

That's odd, they should exist and do for me:

Python 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.ps1
'>>> '
>>> sys.ps2
'... '
>>>

----------
nosy: +ronaldoussoren

_______________________________________
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: [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 16:32:21 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 18 Feb 2010 15:32:21 +0000
Subject: [issue7957] Tutorial issue regarding the sys module
In-Reply-To: <1266505107.41.0.314960086696.issue7957@psf.upfronthosting.co.za>
Message-ID: <1266507141.52.0.35764996537.issue7957@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

They exist only in interactive mode.  They won't be present if you do e.g.

python -c "import sys; print dir(sys)"

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7957>
_______________________________________

From report at bugs.python.org  Thu Feb 18 16:47:05 2010
From: report at bugs.python.org (Lucian Ursu)
Date: Thu, 18 Feb 2010 15:47:05 +0000
Subject: [issue7957] Tutorial issue regarding the sys module
In-Reply-To: <1266505107.41.0.314960086696.issue7957@psf.upfronthosting.co.za>
Message-ID: <1266508025.02.0.783152218256.issue7957@psf.upfronthosting.co.za>


Lucian Ursu <lucian_ursu at yahoo.com> added the comment:

Then it must be an issue with my Python. This is what I get. 
>>> import sys
>>> dir(sys)
['__displayhook__', '__doc__', '__excepthook__', '__name__', '__package__', '__stderr__', '__stdin__', '__stdout__', '_clear_type_cache', '_current_frames', '_getframe', 'api_version', 'argv', 'builtin_module_names', 'byteorder', 'call_tracing', 'callstats', 'copyright', 'displayhook', 'dllhandle', 'dont_write_bytecode', 'exc_clear', 'exc_info', 'exc_traceback', 'exc_type', 'exc_value', 'excepthook', 'exec_prefix', 'executable', 'exit', 'flags', 'float_info', 'getcheckinterval', 'getdefaultencoding', 'getfilesystemencoding', 'getprofile', 'getrecursionlimit', 'getrefcount', 'getsizeof', 'gettrace', 'getwindowsversion', 'hexversion', 'last_traceback', 'last_type', 'last_value', 'maxint', 'maxsize', 'maxunicode', 'meta_path', 'modules', 'path', 'path_hooks', 'path_importer_cache', 'platform', 'prefix', 'py3kwarning', 'setcheckinterval', 'setprofile', 'setrecursionlimit', 'settrace', 'stderr', 'stdin', 'stdout', 'subversion', 'version', 'version_info', 'warnoptions', 'winver']
>>> sys.ps1

Traceback (most recent call last):
  File "<pyshell#23>", line 1, in <module>
    sys.ps1
AttributeError: 'module' object has no attribute 'ps1'
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7957>
_______________________________________

From report at bugs.python.org  Thu Feb 18 17:06:29 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 18 Feb 2010 16:06:29 +0000
Subject: [issue7958] test_platform failure on OS X 10.6
In-Reply-To: <1266506997.43.0.181933833727.issue7958@psf.upfronthosting.co.za>
Message-ID: <1266509189.09.0.764919643006.issue7958@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This test seems to trigger an issue in site.py, adding '-v' to the code that starts the interpreter in test_platform.py gives the following output (amongst a lot more text that doesn't seem to be relevant):

'import site' failed; traceback:
Traceback (most recent call last):
  File "/Users/ronald/Projects/python/python-trunk/build/../Lib/site.py", line 530, in <module>
    main()
  File "/Users/ronald/Projects/python/python-trunk/build/../Lib/site.py", line 509, in main
    addbuilddir()
  File "/Users/ronald/Projects/python/python-trunk/build/../Lib/site.py", line 118, in addbuilddir
    s = "build/lib.%s-%.3s" % (get_platform(), sys.version)
  File "/Users/ronald/Projects/python/python-trunk/Lib/sysconfig.py", line 577, in get_platform
    cfgvars = get_config_vars()
  File "/Users/ronald/Projects/python/python-trunk/Lib/sysconfig.py", line 402, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/Users/ronald/Projects/python/python-trunk/Lib/sysconfig.py", line 255, in _init_posix
    raise IOError(msg)
IOError: invalid Python installation: unable to open /usr/local/lib/python2.7/config/Makefile (No such file or directory)


The root cause is that test_architecture_via_symlink starts python through a symlink, and that confuses the sysconfig module because that tries to detect if it is running in the build tree by looking for a file relative to sys.executable, without resolving symlinks.

A simple patch to sysconfig seems to fix the issue:

-_PROJECT_BASE = abspath(os.path.dirname(sys.executable))
+_PROJECT_BASE = abspath(os.path.dirname(os.path.realpath(sys.executable)))

(also attached as a proper patch).

I'm adding tarek because he added Lib/sysconfig.py.

Tarek: could you please review the patch?

----------
keywords: +patch
nosy: +tarek
Added file: http://bugs.python.org/file16252/sysconfig.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7958>
_______________________________________

From report at bugs.python.org  Thu Feb 18 19:04:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 18 Feb 2010 18:04:06 +0000
Subject: [issue6040] bdist_msi does not deal with pre-release version
In-Reply-To: <1242472106.67.0.523299229524.issue6040@psf.upfronthosting.co.za>
Message-ID: <1266516246.03.0.33224227638.issue6040@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The problem is that the version number goes into the MSI ProductVersion property, which MUST be numeric, or else Windows will refuse to install the package. So this is not just an arbitrary choice (at least not by bdist_msi).

I'm not sure how a strictly numeric version could be determined from the metadata for a prerelease.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6040>
_______________________________________

From report at bugs.python.org  Thu Feb 18 19:05:18 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 18 Feb 2010 18:05:18 +0000
Subject: [issue5839] RegOpenKeyEx key failed on Vista 64Bit with return 2
In-Reply-To: <1240663838.43.0.625551571341.issue5839@psf.upfronthosting.co.za>
Message-ID: <1266516318.78.0.170003990765.issue5839@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Closing because of lack of feedback.

----------
nosy: +loewis
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5839>
_______________________________________

From report at bugs.python.org  Thu Feb 18 20:17:03 2010
From: report at bugs.python.org (Andrew McNabb)
Date: Thu, 18 Feb 2010 19:17:03 +0000
Subject: [issue7955] TextIOWrapper Buffering Inconsistent Between _io and _pyio
In-Reply-To: <1266475277.48.0.657351294204.issue7955@psf.upfronthosting.co.za>
Message-ID: <1266520623.19.0.177534864336.issue7955@psf.upfronthosting.co.za>


Andrew McNabb <amcnabb at mcnabbs.org> added the comment:

This seems like a common need (particularly for stdout and stderr), and setting `stdout._CHUNK_SIZE = 1` is relying on an implementation detail.

1) Can the documentation for TextIOWrapper be updated to clearly describe this extra buffering (how often buffer.write is called, etc.)?

2) Can there be a flush-like method, say write_to_buffer() to force a buffer.write() without the overhead of a flush?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7955>
_______________________________________

From report at bugs.python.org  Thu Feb 18 20:23:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Feb 2010 19:23:21 +0000
Subject: [issue7955] TextIOWrapper Buffering Inconsistent Between _io and _pyio
In-Reply-To: <1266475277.48.0.657351294204.issue7955@psf.upfronthosting.co.za>
Message-ID: <1266521001.92.0.0790903589709.issue7955@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I agree this deserves documentation. I'm not convinced it's a common need, though. Usually you either use stdin/stdout in binary mode or in text mode, but you don't interleave both quite frequently.

----------
assignee:  -> georg.brandl
components: +Documentation
nosy: +georg.brandl
resolution: invalid -> 
stage: committed/rejected -> 
versions: +Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7955>
_______________________________________

From report at bugs.python.org  Thu Feb 18 20:42:40 2010
From: report at bugs.python.org (Andrew McNabb)
Date: Thu, 18 Feb 2010 19:42:40 +0000
Subject: [issue7955] TextIOWrapper Buffering Inconsistent Between _io and _pyio
In-Reply-To: <1266475277.48.0.657351294204.issue7955@psf.upfronthosting.co.za>
Message-ID: <1266522160.52.0.241838947934.issue7955@psf.upfronthosting.co.za>


Andrew McNabb <amcnabb at mcnabbs.org> added the comment:

I would imagine that this would come up in most programs that read data from a pipe or from a socket (which are binary data) and then output to stdout or stderr.  I ran across the problem in my first non-trivial port to Python 3, and it seems like a common case to me.

But having the weird behavior documented is the most important thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7955>
_______________________________________

From report at bugs.python.org  Thu Feb 18 20:46:10 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Thu, 18 Feb 2010 19:46:10 +0000
Subject: [issue1540] Refleak tests: test_doctest and test_gc are failing
In-Reply-To: <1196606516.14.0.848950318684.issue1540@psf.upfronthosting.co.za>
Message-ID: <1266522370.74.0.910012853624.issue1540@psf.upfronthosting.co.za>


Jeremy Hylton <jhylton at gmail.com> added the comment:

I'm trying to figure out the attached script.  If I run Python 3.0, the script doesn't run because of the undefined gc.DEBUG_OBJECTS.  If I just remove that, the script runs without error.  Does that mean the problem is fixed?  Or is running without an error an example of the problem?

If I add gc.DEBUG_SAVEALL, it fails--but that seems obvious because DEBUG_SAVEALL adds all objects with finalizers to gc.garbage.

----------
nosy: +Jeremy.Hylton

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1540>
_______________________________________

From report at bugs.python.org  Thu Feb 18 21:03:38 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 18 Feb 2010 20:03:38 +0000
Subject: [issue1578269] Add os.symlink() and os.path.islink() support for
	Windows
Message-ID: <1266523418.57.0.269025604899.issue1578269@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

At the language summit we okay'd using ctypes in the tests for standard lib modules, specifically for this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1578269>
_______________________________________

From report at bugs.python.org  Thu Feb 18 21:20:36 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 18 Feb 2010 20:20:36 +0000
Subject: [issue7956] unittest.Testcase assertDictContainsSubset with integer
	keys
In-Reply-To: <1266496014.66.0.425338547188.issue7956@psf.upfronthosting.co.za>
Message-ID: <1266524436.71.0.35575870116.issue7956@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Thanks for reporting this.

I can fix this particular error easily by repr'ing the keys. In the process I've found another fun way of killing this assert method:


        one = ''.join(chr(i) for i in range(255))
        two = u'\uFFFD'
        first = {'foo': one}
        second = {'foo': two}
        self.assertDictContainsSubset(first, second)

  File "/Users/michael/Dev/Packages/python-trunk/Lib/unittest/case.py", line 728, in assertDictContainsSubset
    (key, value, actual[key]))
UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 143: ordinal not in range(128)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7956>
_______________________________________

From report at bugs.python.org  Thu Feb 18 22:13:40 2010
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 18 Feb 2010 21:13:40 +0000
Subject: [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: [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  Thu Feb 18 22:49:54 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 18 Feb 2010 21:49:54 +0000
Subject: [issue7961] Py3k: decoding empty bytestring with invalid encoding
	throws no error
In-Reply-To: <1266529462.35.0.7496345471.issue7961@psf.upfronthosting.co.za>
Message-ID: <1266529794.47.0.569528823606.issue7961@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Specifically, the behaviour comes from an early check for empty strings in the PyUnicode_FromEncodedObject function:

    /* Convert to Unicode */
    if (len == 0) {
        Py_INCREF(unicode_empty);
        v = (PyObject *)unicode_empty;
    }
    else
        v = PyUnicode_Decode(s, len, encoding, errors);

It's not until PyUnicode_Decode that there's any attempt to make sense of 'encoding'.  This doesn't seem like a serious bug to me, but I agree that it would be cleaner to fail on unknown encodings even for an empty string.

Ori:  are you interested in working on a patch?

----------
components: +Interpreter Core -None
nosy: +mark.dickinson
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7961>
_______________________________________

From report at bugs.python.org  Thu Feb 18 22:53:10 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Feb 2010 21:53:10 +0000
Subject: [issue7434] pprint doesn't know how to print a namedtuple
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1266529990.5.0.822217204289.issue7434@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Will ponder this a bit more but will likely close this specific request (leaving open the possibility of a more general rewrite of pprint).

----------
assignee:  -> rhettinger
priority:  -> low
versions: +Python 2.7, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7434>
_______________________________________

From report at bugs.python.org  Thu Feb 18 23:25:52 2010
From: report at bugs.python.org (Ori Avtalion)
Date: Thu, 18 Feb 2010 22:25:52 +0000
Subject: [issue7961] Py3k: decoding empty bytestring with invalid encoding
	throws no error
In-Reply-To: <1266529462.35.0.7496345471.issue7961@psf.upfronthosting.co.za>
Message-ID: <1266531952.48.0.065087708626.issue7961@psf.upfronthosting.co.za>


Ori Avtalion <ori at avtalion.name> added the comment:

OK.

The attached patch removes the empty string check before decoding.

I'm not sure where tests should go, since I can only find them in Lib/test/ and this is not a library change.

----------
keywords: +patch
Added file: http://bugs.python.org/file16254/decode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7961>
_______________________________________

From report at bugs.python.org  Thu Feb 18 23:28:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Feb 2010 22:28:56 +0000
Subject: [issue1726687] Bug found in datetime for Epoch time = -1
Message-ID: <1266532136.71.0.968702228362.issue1726687@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I wonder: with year bounds being checked in gettmarg() and mktime accepting arbitrary values for the rest of the tm structure members (at least it appears to on my Mac), is it possible trigger "mktime argument out of range"?

If it is possible, then a unit test should be added for such case.  Note that the issue2736 patch contains a typo that assures that overflow is never reported, but the unit test presented here does not catch that bug:

"""
+	buf.tm_wday = -1;
 	tt = mktime(&buf);
-	if (tt == (time_t)(-1)) {
+	if (tt == (time_t)(-1) && buf.tm_wday == 1) {
 		PyErr_SetString(PyExc_OverflowError,
 				"mktime argument out of range");
"""
(Note missing '-' in buf.tm_wday == 1 check. See issue2736.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1726687>
_______________________________________

From report at bugs.python.org  Thu Feb 18 23:30:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 18 Feb 2010 22:30:37 +0000
Subject: [issue7961] Py3k: decoding empty bytestring with invalid encoding
	throws no error
In-Reply-To: <1266529462.35.0.7496345471.issue7961@psf.upfronthosting.co.za>
Message-ID: <1266532237.5.0.618897099045.issue7961@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the patch.

Rather than remove that optimization entirely, I'd consider pushing it into PyUnicode_Decode.

All tests (whether for the standard library or for the core) go into Lib/test, so that would be the right place.  test_codecs_errors in Lib/test/test_unicode.py looks appropriate.

Adding Marc-Andr? to the nosy list:  this is much more his domain than mine.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7961>
_______________________________________

From report at bugs.python.org  Thu Feb 18 23:35:06 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 18 Feb 2010 22:35:06 +0000
Subject: [issue7961] Py3k: decoding empty bytestring with invalid encoding
	throws no error
In-Reply-To: <1266529462.35.0.7496345471.issue7961@psf.upfronthosting.co.za>
Message-ID: <1266532506.44.0.672764394436.issue7961@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I take that back:  test_codecs_errors isn't the right function to add these tests to.  I actually don't see any current tests for invalid codecs.  Part of the problem would be coming up with an invalid codec name in the first place:  as I understand it, new codecs can be registered at run time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7961>
_______________________________________

From report at bugs.python.org  Thu Feb 18 23:38:54 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 18 Feb 2010 22:38:54 +0000
Subject: [issue7961] Py3k: decoding empty bytestring with invalid encoding
	throws no error
In-Reply-To: <1266529462.35.0.7496345471.issue7961@psf.upfronthosting.co.za>
Message-ID: <1266532734.61.0.682019833251.issue7961@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

And PyUnicode_Decode doesn't look up the encoding in the registry either:  that's somewhere in PyCodec_Decode.

I'm going to butt out now and leave this to those who know the code better. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7961>
_______________________________________

From report at bugs.python.org  Thu Feb 18 23:42:47 2010
From: report at bugs.python.org (Ori Avtalion)
Date: Thu, 18 Feb 2010 22:42:47 +0000
Subject: [issue7961] Py3k: decoding empty bytestring with invalid encoding
	throws no error
In-Reply-To: <1266529462.35.0.7496345471.issue7961@psf.upfronthosting.co.za>
Message-ID: <1266532967.06.0.637542494838.issue7961@psf.upfronthosting.co.za>


Ori Avtalion <ori at avtalion.name> added the comment:

Ignoring the custom utf-8/latin-8 conversion functions, the actual checking if a codec exists is done in Python/codecs.c's PyCodec_Decode.

Is that where I should move the aforementioned optimization to?
Is it safe to assume that the decoded object is always a string/bytestring?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7961>
_______________________________________

From report at bugs.python.org  Thu Feb 18 23:58:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Feb 2010 22:58:04 +0000
Subject: [issue2736] datetime needs an "epoch" method
In-Reply-To: <1209675808.9.0.995048704016.issue2736@psf.upfronthosting.co.za>
Message-ID: <1266533884.51.0.696693787224.issue2736@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Victor,

As you explain in your own documentation, the proposed method is equivalent to ``(time.mktime(self.timetuple()), self.microsecond)``, so all it does is replacing a less than a one-liner.  Moreover, I am not sure time.mktime(self.timetuple()) is something that people would want to do with a TZ-aware datetime.  If the tzinfo of the datetime object does not match the system TZ used by mktime, the result will be quite misleading.

On the patch itself:

1. See my comment at Issue1726687 about the tm_wday == 1 typo.

2. I don't think time_t to long cast is safe on all platforms.

----------
nosy: +Alexander.Belopolsky
title: datetime needs and "epoch" method -> datetime needs an "epoch" method
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2736>
_______________________________________

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: [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 01:29:48 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Fri, 19 Feb 2010 00:29:48 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1266539388.44.0.685229338419.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Thanks for fixing the argument positions;
unfortunately, it seems, there might be some other problem, that makes my code work differently than the builtin re;
it seems, in the character classes the ignorcase flag is ignored somehow: 

>>> regex.findall(r"[ab]", "aB", regex.I)
['a']
>>> re.findall(r"[ab]", "aB", re.I)
['a', 'B']
>>> 

(The same with the flag set in the pattern.)

Outside of the character class the case seems to be handled normally, or am I missing something?

vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Feb 19 01:30:50 2010
From: report at bugs.python.org (Phillip J. Eby)
Date: Fri, 19 Feb 2010 00:30:50 +0000
Subject: [issue7250] wsgiref.handlers.CGIHandler caches os.environ,
	leaking info between requests
In-Reply-To: <1257147245.14.0.668660104401.issue7250@psf.upfronthosting.co.za>
Message-ID: <1266539450.0.0.400020225019.issue7250@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

What sort of test did you have in mind?  To test the desired outcome, it seems we'd need to poison os.environ, reload wsgiref.handlers, remove the poison, and then make sure it didn't get in.  That seems a bit like overkill (as well as hard to get right), while the alternative of simply testing that CGIHandler has an empty os_environ seems a bit like a cheat.  Any thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7250>
_______________________________________

From report at bugs.python.org  Fri Feb 19 02:02:24 2010
From: report at bugs.python.org (Meador Inge)
Date: Fri, 19 Feb 2010 01:02:24 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1266541344.83.0.151604601978.issue3132@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Mark,

> I think a lot of this discussion needs to go back to python-dev;  with 
> luck, we can get some advice and clarifications from the PEP authors 
> there.

So the next step is to kick off a thread on python-dev summarizing the questions\problems we have come up with?  I can get that started.

> Are there other discussions that I'm missing?

I did a quick search and came up with the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Fri Feb 19 02:31:24 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 19 Feb 2010 01:31:24 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1266543084.64.0.894923996007.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20100219.zip is a new version of the regex module.

The regex module should give the same results as the re module for backwards compatibility.

The ignorecase bug is now fixed.

This new version releases the GIL when matching on str and bytes (str and unicode in Python 2.x).

----------
Added file: http://bugs.python.org/file16255/issue2636-20100219.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Feb 19 02:43:31 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 19 Feb 2010 01:43:31 +0000
Subject: [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: <1266543811.72.0.924811821188.issue7951@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

On a related note, this doesn't work either:

>>> "{-1}".format("x", "y", "z")
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    "{-1}".format("x", "y", "z")
KeyError: '-1'

It could return "z".

It also rejects a leading '+', but that would be optional anyway.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Fri Feb 19 04:39:11 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Fri, 19 Feb 2010 03:39:11 +0000
Subject: [issue1540] Refleak tests: test_doctest and test_gc are failing
In-Reply-To: <1196606516.14.0.848950318684.issue1540@psf.upfronthosting.co.za>
Message-ID: <1266550751.24.0.762194216435.issue1540@psf.upfronthosting.co.za>


Jeremy Hylton <jhylton at gmail.com> added the comment:

I spent some time to understand the example script today.  The specific issue is that a set of objects get put into the list of unreachable objects with finalizers (both Immutable and Finalizer instances).  When Cycle's __dict__ is cleared, it also decrefs Immutable which resurrects it and Finalizer.  The garbage collector is not prepared for an unreachable finalizer object to become reachable again.  More generally, it's hard to assume anything about the state of the finalizers after unreachable trash is collected.  I'll think more about what to do, but I don't see any easy solutions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1540>
_______________________________________

From report at bugs.python.org  Fri Feb 19 06:06:16 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 19 Feb 2010 05:06:16 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266555976.21.0.97056691894.issue7900@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I'm not seeing the same issue on my Macbook Pro. I can get all this info from my desktop machine (Mac Pro) when I return from PyCon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Fri Feb 19 06:23:08 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Fri, 19 Feb 2010 05:23:08 +0000
Subject: [issue1540] Refleak tests: test_doctest and test_gc are failing
In-Reply-To: <1196606516.14.0.848950318684.issue1540@psf.upfronthosting.co.za>
Message-ID: <1266556988.3.0.0322229542801.issue1540@psf.upfronthosting.co.za>


Jeremy Hylton <jhylton at gmail.com> added the comment:

One last thought on this bug.  The problem is that after we try to delete garbage, we really can't know much about the state of the objects in the finalizers list.  If any of the objects that are cleared end up causing a finalizer to run, then any of the objects in the finalizers list may be reachable again.  One possibility is to do nothing with the objects in the finalizers list if there was any garbage to delete.  That means objects with finalizers would be harder to get to gc.collect()--for example, you'd need to call gc.collect() twice in a row.  The first time to clear garbage, the second time to handle unreachable objects with finalizers.  Or the GC could run a second time if garbage was cleared and finalizers was non-empty.

A more complicated possibility would be to track some object state about when a finalizer was run.  If any of the objects in finalizers had a finalizer that ran while garbage was cleared, we could skip the finalizers list.  I don't know how to implement this, since an arbitrary C type could run Python code in tp_dealloc without notifying GC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1540>
_______________________________________

From report at bugs.python.org  Fri Feb 19 07:11:41 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 19 Feb 2010 06:11:41 +0000
Subject: [issue7005] ConfigParser does not handle options without values
In-Reply-To: <1254032044.95.0.187935622211.issue7005@psf.upfronthosting.co.za>
Message-ID: <1266559901.02.0.203246286518.issue7005@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Patch and documentation merged to the py3k branch (r78233).

Work on this is complete.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7005>
_______________________________________

From report at bugs.python.org  Fri Feb 19 08:47:32 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 19 Feb 2010 07:47:32 +0000
Subject: [issue7904] urlparse.urlsplit mishandles novel schemes
In-Reply-To: <1265844290.89.0.139975092944.issue7904@psf.upfronthosting.co.za>
Message-ID: <1266565652.2.0.872228816519.issue7904@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in the r78234 and merged back to other branches.
I fell back to RFC's definition of scheme, as anything before the ://.
I did not see the need to add s3 specifically as a valid scheme type, because s3 itself is not registered a schemetype.
So, the fix should work for s3 and other undefined schemes as per RFC.

Thanks for the patch.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7904>
_______________________________________

From report at bugs.python.org  Fri Feb 19 10:05:39 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 19 Feb 2010 09:05:39 +0000
Subject: [issue7891] add links to SVN for documentation developers
In-Reply-To: <1265706845.29.0.564813905696.issue7891@psf.upfronthosting.co.za>
Message-ID: <1266570339.28.0.660889026925.issue7891@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added a link to the checkout FAQ in r12861.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7891>
_______________________________________

From report at bugs.python.org  Fri Feb 19 11:24:10 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Feb 2010 10:24:10 +0000
Subject: [issue7961] Py3k: decoding empty bytestring with invalid encoding
	throws no error
In-Reply-To: <1266532237.5.0.618897099045.issue7961@psf.upfronthosting.co.za>
Message-ID: <4B7E66C6.9000608@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Mark Dickinson wrote:
> 
> Mark Dickinson <dickinsm at gmail.com> added the comment:
> 
> Thanks for the patch.
> 
> Rather than remove that optimization entirely, I'd consider pushing it into PyUnicode_Decode.
> 
> All tests (whether for the standard library or for the core) go into Lib/test, so that would be the right place.  test_codecs_errors in Lib/test/test_unicode.py looks appropriate.
> 
> Adding Marc-Andr? to the nosy list:  this is much more his domain than mine.

I think this is a case for "practicality beats purity": an empty
encoded object will in all practical cases result in an empty Unicode
object when decoded, regardless of which encoding is used.

It's not a 100% clean approach, but does help performance a lot since
you avoid the intermediate conversions, lookups, etc.

If you want to check whether an encoding is registered or not,
you should normally use the codecs.lookup() function.

In which specific case did you find the problem you mentioned ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7961>
_______________________________________

From report at bugs.python.org  Fri Feb 19 11:28:45 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 19 Feb 2010 10:28:45 +0000
Subject: [issue7963] Misleading error message from object(arg)
In-Reply-To: <1266534865.21.0.144393400814.issue7963@psf.upfronthosting.co.za>
Message-ID: <1266575325.42.0.340538780209.issue7963@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The latter is no inconsistency; tuples are immutable, lists are not.  Therefore, for lists, __init__ is the initializer, not __new__.  In order not to duplicate argument checking, __new__ does nothing special with them.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7963>
_______________________________________

From report at bugs.python.org  Fri Feb 19 11:31:37 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Feb 2010 10:31:37 +0000
Subject: [issue7961] Py3k: decoding empty bytestring with invalid encoding
	throws no error
In-Reply-To: <1266532967.06.0.637542494838.issue7961@psf.upfronthosting.co.za>
Message-ID: <4B7E6885.5030203@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ori Avtalion wrote:
> 
> Ori Avtalion <ori at avtalion.name> added the comment:
> 
> Ignoring the custom utf-8/latin-8 conversion functions, the actual checking if a codec exists is done in Python/codecs.c's PyCodec_Decode.
> 
> Is that where I should move the aforementioned optimization to?

That's not a good idea, since codecs that are not used for decoding
into Unicode may very well return something other than an empty
string if passed an empty string on input, e.g.

'x\x9c\x03\x00\x00\x00\x00\x01'

> Is it safe to assume that the decoded object is always a string/bytestring?

No, that's not safe, esp. not in the codecs module. Codecs
can return arbitrary types. It's up to the codecs to decide
what type combinations they support.

In Python 3.x we check the types in the unicode.encode()/
bytes.decode() methods, but that's only a specific use case
in those helper methods, not a general limitation of the
codec architecture.

It's planned to add new .transform()/.untransform() methods
to unicode and bytes which will then provide access to
same-type codecs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7961>
_______________________________________

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: [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 16:44:07 2010
From: report at bugs.python.org (Shashwat Anand)
Date: Fri, 19 Feb 2010 15:44:07 +0000
Subject: [issue7966] mhlib uses deprecated module
In-Reply-To: <1266590877.1.0.984068009408.issue7966@psf.upfronthosting.co.za>
Message-ID: <1266594247.48.0.761678670351.issue7966@psf.upfronthosting.co.za>


Shashwat Anand <anand.shashwat at gmail.com> added the comment:

There is a discussion going on python-dev too, the author being sjoerd.
http://mail.python.org/pipermail/python-dev/2010-February/097772.html
GvR reply : http://mail.python.org/pipermail/python-dev/2010-February/097774.html

----------
nosy: +l0nwlf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7966>
_______________________________________

From report at bugs.python.org  Fri Feb 19 17:43:46 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 19 Feb 2010 16:43:46 +0000
Subject: [issue5930] Transient error in multiprocessing
In-Reply-To: <1241472804.71.0.981647805709.issue5930@psf.upfronthosting.co.za>
Message-ID: <1266597826.9.0.966738434934.issue5930@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Again, but with more details:
http://www.python.org/dev/buildbot/all/builders/i386%20Ubuntu%203.1/builds/302

test_multiprocessing
Process Process-49:
Traceback (most recent call last):
  File "/scratch/pybot-buildarea/3.1.klose-ubuntu-i386/build/Lib/multiprocessing/process.py", line 233, in _bootstrap
    self.run()
  File "/scratch/pybot-buildarea/3.1.klose-ubuntu-i386/build/Lib/multiprocessing/process.py", line 88, in run
    self._target(*self._args, **self._kwargs)
  File "/scratch/pybot-buildarea/3.1.klose-ubuntu-i386/build/Lib/test/test_multiprocessing.py", line 616, in f
    woken.release()
  File "/scratch/pybot-buildarea/3.1.klose-ubuntu-i386/build/Lib/multiprocessing/managers.py", line 962, in release
    return self._callmethod('release')
  File "/scratch/pybot-buildarea/3.1.klose-ubuntu-i386/build/Lib/multiprocessing/managers.py", line 750, in _callmethod
    raise convert_to_error(kind, result)
multiprocessing.managers.RemoteError: 
---------------------------------------------------------------------------
Traceback (most recent call last):
  File "/scratch/pybot-buildarea/3.1.klose-ubuntu-i386/build/Lib/multiprocessing/managers.py", line 219, in serve_client
    obj, exposed, gettypeid = id_to_obj[ident]
KeyError: 'cc9dc3c'
---------------------------------------------------------------------------
test test_multiprocessing failed -- Traceback (most recent call last):
  File "/scratch/pybot-buildarea/3.1.klose-ubuntu-i386/build/Lib/test/test_multiprocessing.py", line 1077, in test_number_of_objects
    self.assertEqual(refs, EXPECTED_NUMBER)
AssertionError: 9 != 1

----------
keywords: +buildbot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5930>
_______________________________________

From report at bugs.python.org  Fri Feb 19 17:51:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 19 Feb 2010 16:51:55 +0000
Subject: [issue7966] mhlib uses deprecated module
In-Reply-To: <1266590877.1.0.984068009408.issue7966@psf.upfronthosting.co.za>
Message-ID: <1266598315.75.0.1950647527.issue7966@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The outcome of that discussion is that what this implies is that there is insufficient test coverage of mhlib, such that no one noticed that mhlib was generating deprecation messages.

mhlib is itself effectively deprecated, since it no longer exists in py3k.  If someone wants to propose patches to fix mhlib that's fine, but this is a very low priority issue.

----------
nosy: +r.david.murray
priority:  -> low
stage:  -> test needed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7966>
_______________________________________

From report at bugs.python.org  Fri Feb 19 17:58:18 2010
From: report at bugs.python.org (Sjoerd Mullender)
Date: Fri, 19 Feb 2010 16:58:18 +0000
Subject: [issue7966] mhlib uses deprecated module
In-Reply-To: <1266590877.1.0.984068009408.issue7966@psf.upfronthosting.co.za>
Message-ID: <1266598698.56.0.297219764508.issue7966@psf.upfronthosting.co.za>


Sjoerd Mullender <sjoerd at acm.org> added the comment:

What's difficult about just doing:

import mhlib

?  That's all it takes to get the warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7966>
_______________________________________

From report at bugs.python.org  Fri Feb 19 18:09:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 19 Feb 2010 17:09:18 +0000
Subject: [issue7966] mhlib does not emit deprecation warning
In-Reply-To: <1266590877.1.0.984068009408.issue7966@psf.upfronthosting.co.za>
Message-ID: <1266599358.65.0.297032902564.issue7966@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  Apparently the actual bug is that mhlib itself does not produce a deprecated message.  The test was explicitly changed to mark the module as one that is deprecated.

----------
title: mhlib uses deprecated module -> mhlib does not emit deprecation warning

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7966>
_______________________________________

From report at bugs.python.org  Fri Feb 19 19:40:54 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 19 Feb 2010 18:40:54 +0000
Subject: [issue7962] Demo/ directory needs to be tested and pruned
In-Reply-To: <1266531589.82.0.915519058153.issue7962@psf.upfronthosting.co.za>
Message-ID: <1266604854.39.0.847609394803.issue7962@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

There's only so much free time developers can spend on Python.  Also, most demos still work in 2.x, even if they are unmaintained, ugly or demonstrate old concepts.  In contrast, most demos weren't tested after porting to 3.x, so many of them don't even run there (and nobody runs them, otherwise we'd have got at least some reports in the tracker).

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7962>
_______________________________________

From report at bugs.python.org  Fri Feb 19 21:06:36 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Fri, 19 Feb 2010 20:06:36 +0000
Subject: [issue1540] Refleak tests: test_doctest and test_gc are failing
In-Reply-To: <1196606516.14.0.848950318684.issue1540@psf.upfronthosting.co.za>
Message-ID: <1266609996.88.0.0907940121528.issue1540@psf.upfronthosting.co.za>


Jeremy Hylton <jhylton at gmail.com> added the comment:

Amaury-- I think that will work.  I put together a small patch that seems to pass all the tests, but it too messy.  We need some care to make sure we don't spin forever if there's some degenerate case where we never escape GC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1540>
_______________________________________

From report at bugs.python.org  Fri Feb 19 21:13:15 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 19 Feb 2010 20:13:15 +0000
Subject: [issue7962] Demo/ directory needs to be tested and pruned
In-Reply-To: <1266531589.82.0.915519058153.issue7962@psf.upfronthosting.co.za>
Message-ID: <1266610395.68.0.0498321797822.issue7962@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, these demos are not meant to demonstrate the fastest algorithms, but to demonstrate how easy and readable simple algorithms can be written in Python.

That said, if you can write better versions that are also very readable, they'll make a good addition.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7962>
_______________________________________

From report at bugs.python.org  Fri Feb 19 22:06:24 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 19 Feb 2010 21:06:24 +0000
Subject: [issue7967] PyXML is dead
In-Reply-To: <1266607202.83.0.579866933028.issue7967@psf.upfronthosting.co.za>
Message-ID: <1266613584.73.0.0587230887276.issue7967@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Maybe the PyXML hack can be removed, too?
http://svn.python.org/view/python/trunk/Lib/xml/__init__.py?view=markup

----------
nosy: +flox
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7967>
_______________________________________

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: [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:03:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 19 Feb 2010 22:03:46 +0000
Subject: [issue7968] __dict__ Exception using class attributes
In-Reply-To: <1266615630.29.0.231312214018.issue7968@psf.upfronthosting.co.za>
Message-ID: <1266617026.2.0.587852094383.issue7968@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

That's because the attribute values don't exist in the instance until you make an assignment to them.  Before that the exist only as class attributes.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
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: [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  Fri Feb 19 23:52:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 19 Feb 2010 22:52:52 +0000
Subject: [issue7964] "-m pdb" SyntaxError for "\r\n" formatted py files
In-Reply-To: <1266583937.16.0.516750395183.issue7964@psf.upfronthosting.co.za>
Message-ID: <1266619972.95.0.374572882896.issue7964@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It's a bug, and the bug is fixed (indirectly) in py3k trunk via improvements to the 'compile' function.  That fix can't be backported because it is a behavior change, so fixing this in 3.1 would require fixing pdb to deal with universal new lines.  I don't think that is worth it, but if someone wants to propose a patch I'll reopen the issue.

----------
nosy: +r.david.murray
priority:  -> normal
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7964>
_______________________________________

From jeremy at alum.mit.edu  Fri Feb 19 23:56:53 2010
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Fri, 19 Feb 2010 17:56:53 -0500
Subject: [issue7806] httplib.HTTPConnection.getresponse closes socket 
	which destroys the response
In-Reply-To: <1265062987.89.0.571102322477.issue7806@psf.upfronthosting.co.za>
References: <1264777311.04.0.988942468984.issue7806@psf.upfronthosting.co.za>
	<1265062987.89.0.571102322477.issue7806@psf.upfronthosting.co.za>
Message-ID: <e8bf7a531002191456o27f5f57fude5e6a4a52bb746@mail.gmail.com>

I don't think the HTTPConnection class was designed to work with
sockets that don't follow the Python socket API.  If you want to use a
different socket, you should create some wrapper that emulates the
Python socket ref count behavior.

Jeremy

On Mon, Feb 1, 2010 at 5:23 PM, Robert Buchholz <report at bugs.python.org> wrote:
>
> Robert Buchholz <rbu at freitagsrunde.org> added the comment:
>
> An example cannot be constructed using the standard python socket class. As you point out, the response.will_close attribute is set correctly: The client is supposed to close to connect after completion of the request (as does the server). However, when the HTTPConnection object calls close() on the socket, reading the request is not completed -- the request object merely created a file-like object representing the socket.
>
> The reason why this is not an issue is that the Python socket library does reference counting to determine when to close a socket object. When the HTTPConnection calls close(), its own socket object is destroyed and unreferenced. However, the file-like object in the HTTPResponse still has a copy of the socket.
>
> In alternative socket implementations (like Paramiko SOCKS-proxied sockets), this poses a problem: When the socket user calls close(), they actually close the socket -- as the original socket API documentation describes:
>
> ? ?close()
> ? ?Close the socket. ?It cannot be used after this call.
>
> ? ?makefile([mode[, bufsize]]) -> file object
> ? ?Return a regular file object corresponding to the socket. ?The mode
> ? ?and bufsize arguments are as for the built-in open() function.
>
> Consequently, I do not consider this to be a bug in Paramiko and reported it for the httplib. I can present example code using a paramiko tunneled socket (client and server) if you like.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7806>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

From report at bugs.python.org  Fri Feb 19 23:57:07 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Fri, 19 Feb 2010 22:57:07 +0000
Subject: [issue7806] httplib.HTTPConnection.getresponse closes socket which
	destroys the response
In-Reply-To: <1265062987.89.0.571102322477.issue7806@psf.upfronthosting.co.za>
Message-ID: <e8bf7a531002191456o27f5f57fude5e6a4a52bb746@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

I don't think the HTTPConnection class was designed to work with
sockets that don't follow the Python socket API.  If you want to use a
different socket, you should create some wrapper that emulates the
Python socket ref count behavior.

Jeremy

On Mon, Feb 1, 2010 at 5:23 PM, Robert Buchholz <report at bugs.python.org> wrote:
>
> Robert Buchholz <rbu at freitagsrunde.org> added the comment:
>
> An example cannot be constructed using the standard python socket class. As you point out, the response.will_close attribute is set correctly: The client is supposed to close to connect after completion of the request (as does the server). However, when the HTTPConnection object calls close() on the socket, reading the request is not completed -- the request object merely created a file-like object representing the socket.
>
> The reason why this is not an issue is that the Python socket library does reference counting to determine when to close a socket object. When the HTTPConnection calls close(), its own socket object is destroyed and unreferenced. However, the file-like object in the HTTPResponse still has a copy of the socket.
>
> In alternative socket implementations (like Paramiko SOCKS-proxied sockets), this poses a problem: When the socket user calls close(), they actually close the socket -- as the original socket API documentation describes:
>
> ? ?close()
> ? ?Close the socket. ?It cannot be used after this call.
>
> ? ?makefile([mode[, bufsize]]) -> file object
> ? ?Return a regular file object corresponding to the socket. ?The mode
> ? ?and bufsize arguments are as for the built-in open() function.
>
> Consequently, I do not consider this to be a bug in Paramiko and reported it for the httplib. I can present example code using a paramiko tunneled socket (client and server) if you like.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7806>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

----------
nosy: +jhylton

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7806>
_______________________________________

From report at bugs.python.org  Sat Feb 20 00:13:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 19 Feb 2010 23:13:03 +0000
Subject: [issue7964] "-m pdb" SyntaxError for "\r\n" formatted py files
In-Reply-To: <1266583937.16.0.516750395183.issue7964@psf.upfronthosting.co.za>
Message-ID: <1266621183.06.0.565783763698.issue7964@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It's a bug, and the bug is fixed (indirectly) in py3k trunk via improvements to the 'compile' function.  That fix can't be backported because it is a behavior change.

On the other hand, it appears as though the fix is to change the open statement from using 'rb' to using 'r'.  I'm not at all sure why it is opened in 'rb' mode, and it's possible it should be changed in trunk as well.

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7964>
_______________________________________

From report at bugs.python.org  Sat Feb 20 00:22:13 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 19 Feb 2010 23:22:13 +0000
Subject: [issue7806] httplib.HTTPConnection.getresponse closes socket which
	destroys the response
In-Reply-To: <1264777311.04.0.988942468984.issue7806@psf.upfronthosting.co.za>
Message-ID: <1266621733.48.0.719668342428.issue7806@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

But a goal is for the standard library to work with Python implementations other than CPython, and the reference counting behavior described won't happen in non-reference counting implementations.  So I don't think that requiring emulation of ref-counting behavior is valid.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7806>
_______________________________________

From report at bugs.python.org  Sat Feb 20 00:49:40 2010
From: report at bugs.python.org (Andrew Shuiu)
Date: Fri, 19 Feb 2010 23:49:40 +0000
Subject: [issue7968] __dict__ Exception using class attributes
In-Reply-To: <1266617026.2.0.587852094383.issue7968@psf.upfronthosting.co.za>
Message-ID: <493606534.20100220014940@bitdefender.com>


Andrew Shuiu <asuiu at bitdefender.com> added the comment:

Hello Murray,
That seems a little strange to me, because if an object is instance of
a class, it should inherit all of it attributes.

Is it an optimization issue? because I observed that all
instances of a class that has such "static" attributes, shares that
attributes for less memory using.

Anyway, thank you for explications.

Saturday, February 20, 2010, 12:03:46 AM, you wrote:

> R. David Murray <rdmurray at bitdance.com> added the comment:

> That's because the attribute values don't exist in the instance
> until you make an assignment to them.  Before that the exist only as class attributes.

priority:  ->> normal
resolution:  ->> invalid
stage:  ->> committed/rejected
status: open ->> closed

> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7968>
> _______________________________________

-- 
Best regards,
Andrei SUIU
Virus Researcher, BitDefender
  asuiu at bitdefender.com                          mailto:asuiu at bitdefender.com
--------------------------------
Phone : +40 232 232 222
www.bitdefender.com
--------------------------------
The content of this message and attachments are confidential and are 
classified as BitDefender's Proprietary Information. The content of 
this message is intended solely for the use of the individual or entity 
to whom it is addressed and others authorized to receive it. If you are 
not the intended recipient you are hereby notified that any disclosure, 
copying, distribution or taking any action based on this information are 
strictly prohibited and may be precluded by law. If you have received 
this message in error, please notify us immediately and then delete it 
from your system. BitDefender SRL is neither liable for the proper and 
complete transmission of the information contained in this message nor 
for any delay in its receipt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7968>
_______________________________________

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: [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 05:29:55 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Sat, 20 Feb 2010 04:29:55 +0000
Subject: [issue7806] httplib.HTTPConnection.getresponse closes socket which
	destroys the response
In-Reply-To: <1266621733.48.0.719668342428.issue7806@psf.upfronthosting.co.za>
Message-ID: <e8bf7a531002192029j3fa8ce49vbe48765671fd3621@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

On Fri, Feb 19, 2010 at 6:22 PM, R. David Murray <report at bugs.python.org> wrote:
>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> But a goal is for the standard library to work with Python implementations other than CPython, and the reference counting behavior described won't happen in non-reference counting implementations. ?So I don't think that requiring emulation of ref-counting behavior is valid.

I don't think an implementation of Python sockets would be considered
correct unless it supported this behavior.  CPython goes to elaborate
lengths to make it work across platforms.

Jeremy

> ----------
> nosy: +r.david.murray
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7806>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7806>
_______________________________________

From report at bugs.python.org  Sat Feb 20 05:32:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Feb 2010 04:32:23 +0000
Subject: [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: <1266640343.25.0.192232689885.issue7970@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The problem only arises with HeaderParser.  The full parser turns the body into a list containing a Message object, because that's how the email package models the message structure.  HeaderParser treats the body as a single string.  All that is fine, but generator's flatten method has special handlers for certain mime types, and message/rfc822 is one of them.  It is looking for what it "knows" the message/rfc822 body looks like (a list containing a Message), but what it finds is a string.

The fix is probably to special case get_payload returning a string inside the _handle_message.  I've attached a patch that adds your test file as a unit test and provides that fix.

----------
assignee:  -> r.david.murray
nosy: +r.david.murray
priority:  -> normal
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7970>
_______________________________________

From report at bugs.python.org  Sat Feb 20 06:06:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Feb 2010 05:06:01 +0000
Subject: [issue7806] httplib.HTTPConnection.getresponse closes socket which
	destroys the response
In-Reply-To: <1264777311.04.0.988942468984.issue7806@psf.upfronthosting.co.za>
Message-ID: <1266642361.4.0.665486577298.issue7806@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

But the docs (which presumably describe the API) say that the socket is unusable after the call to close, which argues that the paramiko sockets are following the documented API.  Do the docs need to be corrected?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7806>
_______________________________________

From report at bugs.python.org  Sat Feb 20 06:38:07 2010
From: report at bugs.python.org (Danny Milosavljevic)
Date: Sat, 20 Feb 2010 05:38:07 +0000
Subject: [issue7971] hidraw Linux module
In-Reply-To: <1266644179.93.0.424583318112.issue7971@psf.upfronthosting.co.za>
Message-ID: <1266644287.93.0.992397102674.issue7971@psf.upfronthosting.co.za>


Danny Milosavljevic <danny_milo at yahoo.com> added the comment:

Usage example:

>>>import hidraw
>>>import os
>>>hidraw.get_info(os.open("/dev/hidraw0", os.O_RDONLY))
hidraw.Info(3, 0x0E20, 0x0200)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7971>
_______________________________________

From report at bugs.python.org  Sat Feb 20 07:28:43 2010
From: report at bugs.python.org (zhou wei)
Date: Sat, 20 Feb 2010 06:28:43 +0000
Subject: [issue7898] rlcompleter add "real tab" when text is empty feature
In-Reply-To: <1265789959.13.0.400404108309.issue7898@psf.upfronthosting.co.za>
Message-ID: <1266647323.6.0.25504613992.issue7898@psf.upfronthosting.co.za>


zhou wei <lilaboc.cn at gmail.com> added the comment:

Pitrou,

I think you are right on "On the other hand, it will appear quite bizarre to people who have another, dedicated key for auto-completion." If I assign another key for auto-completion, the behavior becomes really strange.  It happens in ipython too.

But I guess most people just use tab as the default key for auto-completion, and the readline module document say:"
get_begidx( ) 
    Get the beginning index of the readline tab-completion scope. 
get_endidx( ) 
    Get the ending index of the readline tab-completion scope. 
set_completer_delims( string) 
    Set the readline word delimiters for tab-completion. 
get_completer_delims( ) 
    Get the readline word delimiters for tab-completion. 
"
And now, I think the problem becomes:convenience for the majority or protection for the minority. If we decide to protect the minority, I think I can submit another patch for the readline module document, to make the document constant, so, the document looks like:
get_endidx( ) 
    Get the ending index of the readline auto-completion scope. 

PS: Is there a way to find out the current key-binding on auto-completion? If we can find this, I think we can "if else" this behavior to satisfy everybody.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7898>
_______________________________________

From report at bugs.python.org  Sat Feb 20 11:43:29 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 20 Feb 2010 10:43:29 +0000
Subject: [issue7805] test_multiprocessing failure
In-Reply-To: <1264773760.19.0.248393154087.issue7805@psf.upfronthosting.co.za>
Message-ID: <1266662609.18.0.0324534910985.issue7805@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I found the problem. On a loaded machine, an attempt is made to
get the pid of the worker before the process has properly started.

There are several places where a sleep could be inserted. Perhaps
Process.start() should wait until the child's pid is not None?

----------
keywords: +patch
Added file: http://bugs.python.org/file16265/issue7805_problem_outline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7805>
_______________________________________

From report at bugs.python.org  Sat Feb 20 13:32:27 2010
From: report at bugs.python.org (Ori Avtalion)
Date: Sat, 20 Feb 2010 12:32:27 +0000
Subject: [issue7961] Py3k: decoding empty bytestring with invalid encoding
	throws no error
In-Reply-To: <1266529462.35.0.7496345471.issue7961@psf.upfronthosting.co.za>
Message-ID: <1266669147.3.0.91027151633.issue7961@psf.upfronthosting.co.za>


Ori Avtalion <ori at avtalion.name> added the comment:

> In which specific case did you find the problem you mentioned ?

I didn't. I only pointed out the inconsistency.
I'm happy with rejecting this bug, if it's not seen as a problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7961>
_______________________________________

From report at bugs.python.org  Sat Feb 20 15:33:02 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 20 Feb 2010 14:33:02 +0000
Subject: [issue7971] hidraw Linux module
In-Reply-To: <1266644179.93.0.424583318112.issue7971@psf.upfronthosting.co.za>
Message-ID: <1266676382.56.0.629762168105.issue7971@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The bug tracker is not the right place to release your modules. If you have a distributable module rather than a patch, PyPi may be a better place to put your results.

----------
nosy: +brian.curtin
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7971>
_______________________________________

From report at bugs.python.org  Sat Feb 20 16:34:47 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 20 Feb 2010 15:34:47 +0000
Subject: [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: <1266680087.93.0.503529378571.issue7944@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Does anyone prefer if this should be done on a patch-per-module basis, or just throw together one huge change? 

Also, I've found a few places where context managers aren't supported where they probably should be, so I'll spin off separate issues for those.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7944>
_______________________________________

From report at bugs.python.org  Sat Feb 20 16:37:26 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Feb 2010 15:37:26 +0000
Subject: [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: <1266680246.05.0.114765556094.issue7944@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

There are several standard library modules that deliberately maintain compatibility with earlier versions of Python. The 'with' statement shouldn't be used for tests of any modules that still need compatibility with Python 2.4.

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7944>
_______________________________________

From report at bugs.python.org  Sat Feb 20 17:00:55 2010
From: report at bugs.python.org (=?utf-8?q?Reto_Sch=C3=BCttel?=)
Date: Sat, 20 Feb 2010 16:00:55 +0000
Subject: [issue5125] Strange locale problem with Python 3
In-Reply-To: <1233517710.32.0.869509955584.issue5125@psf.upfronthosting.co.za>
Message-ID: <1266681655.5.0.693022396561.issue5125@psf.upfronthosting.co.za>


Reto Sch?ttel <reto-company-python-bugs at schuettel.ch> added the comment:

Hey Mark, Stefan

I've got the example working again with 3.1 and it appears like the behaviour has been reverted to the pre-3.0 days. So the problem is fixed for me :)! 

with 3.1 (and 2.6) atof only accepts a '.' as a decimal delimiter, regardless of the configured locale.

Thanks for your help! I'll close this bug report.

Reto

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5125>
_______________________________________

From report at bugs.python.org  Sat Feb 20 17:01:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Feb 2010 16:01:42 +0000
Subject: [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: <1266681702.71.0.733945861452.issue7970@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  You are right.  Not sure if that was user error or browser error.  Let's try again.

----------
keywords: +patch
Added file: http://bugs.python.org/file16266/email_message_rfc822.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7970>
_______________________________________

From report at bugs.python.org  Sat Feb 20 18:07:32 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 20 Feb 2010 17:07:32 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1266685652.54.0.712716960286.issue3426@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The attached patch proposes a decorator which can be used to strengthen any test which is affected by the CWD. (and fixes for test_(mac|nt|posix)path too)

----------
Added file: http://bugs.python.org/file16267/issue3426_any_cwd.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3426>
_______________________________________

From report at bugs.python.org  Sat Feb 20 18:55:22 2010
From: report at bugs.python.org (Martin Manns)
Date: Sat, 20 Feb 2010 17:55:22 +0000
Subject: [issue7721] Code in xrange documentation does not work
In-Reply-To: <1263678962.32.0.0144056263369.issue7721@psf.upfronthosting.co.za>
Message-ID: <1266688522.51.0.730151585926.issue7721@psf.upfronthosting.co.za>


Martin Manns <mmanns at gmx.net> added the comment:

So could we replace

"If a larger range is needed, an alternate version can be crafted using the itertools module: islice(count(start, step), (stop-start+step-1)//step)."

by

"If a larger range is needed, an alternate version can be crafted using the itertools module: takewhile(lambda x: x<stop, (start+i*step for i in count()))."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7721>
_______________________________________

From report at bugs.python.org  Sat Feb 20 19:37:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Feb 2010 18:37:09 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266691029.14.0.528551749896.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Michael,

Can you post the output of "groups" and "id" command from your Mac?  It looks like posix_getgroups cannot handle more than NGROUPS_MAX groups and NGROUPS_MAX is 16 on Mac OS.

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Sat Feb 20 20:13:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Feb 2010 19:13:57 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266693237.23.0.212867199564.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I was able to reproduce the error.  First, add your user name to multiple test groups as follows:

$ sudo dscl . -create /Groups/testN GroupMembership username
(repeat 16 times with different Ns)

$ ./python.exe 
Python 2.7a3+ (trunk:78265M, Feb 20 2010, 13:18:22) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import posix
>>> posix.getgroups()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Sat Feb 20 21:14:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Feb 2010 20:14:09 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266696849.46.0.822112121186.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I am submitting a fix.  I am using the following feature documented in getgroups(2):
"""
If _DARWIN_C_SOURCE is defined, getgroups() can return more than {NGROUPS_MAX} groups.
"""

It appears that _DARWIN_C_SOURCE is defined in the standard python configuration on Mac OS X.  Tested on 10.6 only.

----------
keywords: +patch
Added file: http://bugs.python.org/file16269/issue7900.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

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: [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  Sat Feb 20 21:43:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Feb 2010 20:43:27 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266698607.3.0.13844116025.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

It looks like the current implementation is not POSIX compliant because it assumes that NGROUPS_MAX is compile time constant.  However, according to <http://www.opengroup.org/onlinepubs/000095399/functions/getgroups.html>, "Application writers should note that {NGROUPS_MAX} is not necessarily a constant on all implementations."

I would suggest using my _DARWIN_C_SOURCE implementation unconditionally and make similar changes to posix_setgroups, but this is probably a subject for a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Sat Feb 20 21:43:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Feb 2010 20:43:37 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266698617.49.0.943459516922.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

It looks like the current implementation is not POSIX compliant because it assumes that NGROUPS_MAX is compile time constant.  However, according to <http://www.opengroup.org/onlinepubs/000095399/functions/getgroups.html>, "Application writers should note that {NGROUPS_MAX} is not necessarily a constant on all implementations."

I would suggest using my _DARWIN_C_SOURCE implementation unconditionally and make similar changes to posix_setgroups, but this is probably a subject for a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Sat Feb 20 22:22:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Feb 2010 21:22:20 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1266700940.92.0.749691982395.issue6280@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Francesco,

You have my +1 for implementing both 1 and 2 below.
"""
1. Use timegm(3) function where HAVE_TIMEGM is defined (i have a working patch for it)

2. Implement a more portable timegm function with tzset and mktime where HAVE_MKTIME and 
HAVE_WORKING_TZSET is defined (i have a working patch for it)
"""

I don't think "3. Doing some calculation taking calendar.timegm as example" is a good idea.  IMHO, its is more important that timegm is a proper inverse of gmtime on any given platform than to have the same values produced by timegm across platforms.  If system timegm (or mktime) thinks that 1900 is a leap year, for example, python should not attempt to correct that.  Maybe doing "some calculation" on systems that don't have mktime is a reasonable last resort, but I am not sure it is worth the effort.

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Sat Feb 20 22:33:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Feb 2010 21:33:36 +0000
Subject: [issue7968] __dict__ Exception using class attributes
In-Reply-To: <1266615630.29.0.231312214018.issue7968@psf.upfronthosting.co.za>
Message-ID: <1266701616.2.0.742985184869.issue7968@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> That seems a little strange to me, because if an object is instance of
> a class, it should inherit all of it attributes.

An instance does not "inherit" attributes of its class.  Instead, when
looking up an attribute for an instance, attributes of the class (most
prominently methods) are considered after looking in the instance
__dict__.

> Is it an optimization issue? because I observed that all
> instances of a class that has such "static" attributes, shares that
> attributes for less memory using.

No, this has nothing to do with optimization.  The main point, which
may be surprising if you come from a background of more static
languages, is that in Python, the class itself is an object of its own
right, and can have attributes (it has its own __dict__).  Therefore,
class attributes exist only once, and appear to be "shared" when
accessed through a class instance.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7968>
_______________________________________

From report at bugs.python.org  Sat Feb 20 23:07:29 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 20 Feb 2010 22:07:29 +0000
Subject: [issue7751] urllib.urlopen("///C|/foo/bar/spam.foo") IOError: [Errno
	22]
In-Reply-To: <1264114525.88.0.153808488744.issue7751@psf.upfronthosting.co.za>
Message-ID: <1266703649.02.0.425920672411.issue7751@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

cgohlke, thanks for the patches and sorry for the delay. The fix however is not to replace the %HH character of '|' with '|', in the nturl2path, but the keep the '|' as safe character in the urllib.urlopen.

-        fullurl = quote(fullurl, safe="%/:=&?~#+!$,;'@()*[]")
+        fullurl = quote(fullurl, safe="%/:=&?~#+!$,;'@()*[]|")

Fixed in the revision 78268 with tests added.

----------
assignee:  -> orsenthil
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7751>
_______________________________________

From report at bugs.python.org  Sun Feb 21 00:49:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Feb 2010 23:49:17 +0000
Subject: [issue7751] urllib.urlopen("///C|/foo/bar/spam.foo") IOError: [Errno
	22]
In-Reply-To: <1264114525.88.0.153808488744.issue7751@psf.upfronthosting.co.za>
Message-ID: <1266709757.11.0.994057001156.issue7751@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

I?m no Windows expert but from what I know I?m puzzled by the test and the fix that have been committed. I thought the path C:\something would correspond to the URI file:///C|/something. Could you enlighten me?

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7751>
_______________________________________

From report at bugs.python.org  Sun Feb 21 04:48:14 2010
From: report at bugs.python.org (Asheesh Laroia)
Date: Sun, 21 Feb 2010 03:48:14 +0000
Subject: [issue7794] Document zipfile and directory execution in What's New
	for 2.6/3.1
In-Reply-To: <1264597975.95.0.291487626688.issue7794@psf.upfronthosting.co.za>
Message-ID: <1266724094.78.0.715847563379.issue7794@psf.upfronthosting.co.za>


Asheesh Laroia <asheesh at asheesh.org> added the comment:

Hey dudes and/or dudettes,

I think this is already done. Check out this old commit to trunk:

http://svn.python.org/view/python/trunk/Misc/NEWS?r1=58963&r2=59039&pathrev=59039 

When I check out Python trunk right now, Line 3759 of Misc/NEWS mentions this new feature.

Therefore, I think this bug can be closed -- it's already documented.

If it should instead be documented in some *other* way, let me know and I'll see if I can do it!

----------
nosy: +Asheesh.Laroia

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7794>
_______________________________________

From report at bugs.python.org  Sun Feb 21 04:53:37 2010
From: report at bugs.python.org (Asheesh Laroia)
Date: Sun, 21 Feb 2010 03:53:37 +0000
Subject: [issue6414] struct module : processor endianness descriptions
	misleading
In-Reply-To: <1246693590.67.0.013392500744.issue6414@psf.upfronthosting.co.za>
Message-ID: <1266724417.15.0.170797366671.issue6414@psf.upfronthosting.co.za>


Asheesh Laroia <asheesh at asheesh.org> added the comment:

Hey all,

I (a person who just wandered by) think that Alexey Shamrin's suggested text is great.

For that reason, I have turned it into a unified diff created by 'svn diff'.

I hope that would help move this bug along!

I'm attaching that patch against trunk right now.

----------
keywords: +patch
nosy: +Asheesh.Laroia
Added file: http://bugs.python.org/file16272/issue6416-trunk.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6414>
_______________________________________

From report at bugs.python.org  Sun Feb 21 05:00:24 2010
From: report at bugs.python.org (Asheesh Laroia)
Date: Sun, 21 Feb 2010 04:00:24 +0000
Subject: [issue6414] struct module : processor endianness descriptions
	misleading
In-Reply-To: <1246693590.67.0.013392500744.issue6414@psf.upfronthosting.co.za>
Message-ID: <1266724824.0.0.497638610437.issue6414@psf.upfronthosting.co.za>


Asheesh Laroia <asheesh at asheesh.org> added the comment:

I'm attaching (basically) the same patch, this time against the py3k branch.

I'm open to improvements to the text. If the text is okay, please just ship these!

Sincerely,

A dude sitting in an open space at PyCon.

----------
Added file: http://bugs.python.org/file16273/issue6414-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6414>
_______________________________________

From report at bugs.python.org  Sun Feb 21 05:00:57 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 21 Feb 2010 04:00:57 +0000
Subject: [issue7751] urllib.urlopen("///C|/foo/bar/spam.foo") IOError: [Errno
	22]
In-Reply-To: <1264114525.88.0.153808488744.issue7751@psf.upfronthosting.co.za>
Message-ID: <1266724857.72.0.776017257571.issue7751@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

The reason the problem was appearing in windows was, it is where, the | is normally observed in URLS, Without | being a safe character, that is it can appear literally in the url, the open method was translating it to %7C. Christopher's patch was to reconvert it to '|' later. 
I thought about it a bit and added '|' to safe characters.
Also, the tests were not very specific to windows, but to test the functionality of the open method leaving the safe characters unquoted.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7751>
_______________________________________

From report at bugs.python.org  Sun Feb 21 05:40:21 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Sun, 21 Feb 2010 04:40:21 +0000
Subject: [issue1736483] os.popen('yes | echo hello') stuck
Message-ID: <1266727221.4.0.146138111924.issue1736483@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

I don't think this is a bug in python (see below for analysis). Furthermore, os.popen() is deprecated, so I think this issue can be closed.


Here is my understanding of what's happening.

When you execute :

 python -c 'import sys, os; sys.stdout.write(os.popen("while :; do echo  yes ; done | echo hello").read())'

popen() forks and then execs() a /bin/sh like this

 /bin/sh -c "while :; do echo  yes ; done | echo hello"

But exec() (on Linux at least) inherits the signal handling from the pre-exec process for the signals which were set to SIG_IGN or SIG_DFL (see e.g here: http://www.gnu.org/software/libc/manual/html_node/Initial-Signal-Actions.html), so in this case shell will inherit SIG_IGN setting from python for SIGPIPE.

Furthermore, the "sh" manpage explicitly says that shell will wait for all processes in the pipeline. 

So, the sequence of events will be as follows: echo exits, SIGPIPE is delivered to the shell and is ignored by the shell and so the shell keeps running the while loop forever, so .read() call never reaches the eof and your script blocks.

The original "yes|echo" example on MacOsX has likely been caused by the same sequence of events. (if "yes" inherits signal handling from shell, then "yes|echo"
would not block when invoked from command line, but would block when invoked from python)

Installling your own SIGPIPE handler (or resetting SIGPIPE to SIG_DFL as ilgiz suggested) should work around this issue.

----------
nosy: +isandler

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1736483>
_______________________________________

From report at bugs.python.org  Sun Feb 21 05:50:12 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 21 Feb 2010 04:50:12 +0000
Subject: [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: <1266727812.4.0.920479370191.issue7970@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Applied to trunk in r78274, 2.6 in r78275, py3k in r78276, and 3.1 in r78277.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7970>
_______________________________________

From report at bugs.python.org  Sun Feb 21 05:53:08 2010
From: report at bugs.python.org (Ryan Arana)
Date: Sun, 21 Feb 2010 04:53:08 +0000
Subject: [issue6538] MatchObject is not a hyperlink in the 're' module
	documentation
In-Reply-To: <1248215363.5.0.63292386695.issue6538@psf.upfronthosting.co.za>
Message-ID: <1266727988.37.0.089435834636.issue6538@psf.upfronthosting.co.za>


Ryan Arana <ryan.arana at gmail.com> added the comment:

Changed all occurrences of :class:`MatchObjects` to :ref:`match-objects` in /Doc/library/re.rst

These changes were made to rev 78277.

----------
keywords: +patch
nosy: +rarana
Added file: http://bugs.python.org/file16274/MatchObjectLinksFix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6538>
_______________________________________

From report at bugs.python.org  Sun Feb 21 11:35:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Feb 2010 10:35:53 +0000
Subject: [issue7751] urllib.urlopen("///C|/foo/bar/spam.foo") IOError: [Errno
	22]
In-Reply-To: <1266724857.72.0.776017257571.issue7751@psf.upfronthosting.co.za>
Message-ID: <4B810C81.9020302@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

Ok, thanks for clarifying :)

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7751>
_______________________________________

From report at bugs.python.org  Sun Feb 21 12:25:36 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 21 Feb 2010 11:25:36 +0000
Subject: [issue3426] os.path.abspath with unicode argument should call
	os.getcwdu
In-Reply-To: <1216737133.71.0.70086601319.issue3426@psf.upfronthosting.co.za>
Message-ID: <1266751536.0.0.262419511665.issue3426@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r78247 (trunk) and r78248 (release26-maint) (plus a fix in r78272 and r78279 to avoid test failures when the filesystem encoding is ascii).
I didn't use the any_cwd decorator -- I might consider it in future if it turns out that there are more tests like these.

----------
dependencies:  -Add a context manager to change cwd in test.test_support and run the test suite in a temp dir.
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3426>
_______________________________________

From report at bugs.python.org  Sun Feb 21 13:58:10 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 21 Feb 2010 12:58:10 +0000
Subject: [issue4999] multiprocessing.Queue does not order objects
In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>
Message-ID: <1266757090.79.0.575640297481.issue4999@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I think it would be nice to update the documentation if this isn't
resolved yet. The patch adds a warning that FIFO behavior is not
guaranteed.

----------
keywords: +patch
nosy: +skrah
Added file: http://bugs.python.org/file16276/warn_fifo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4999>
_______________________________________

From report at bugs.python.org  Sun Feb 21 13:58:46 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Feb 2010 12:58:46 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1266757126.81.0.52241914851.issue5211@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Apologies for the delay;  tomorrow was a long time coming...

The patch looks great---thank you!  I added a ".. versionchanged" note to the documentation, and fixed a couple of whitespace issues; apart from that I didn't change anything.  Applied in r78280.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________

From report at bugs.python.org  Sun Feb 21 14:05:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Feb 2010 13:05:25 +0000
Subject: [issue2395] [Py3k] struct module changes of PEP 3118
In-Reply-To: <1205856060.67.0.357097820084.issue2395@psf.upfronthosting.co.za>
Message-ID: <1266757525.58.0.669739705895.issue2395@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think this can be closed as a duplicate of issue 3132.  (Yes, this issue came first, but all the interesting(?) discussion is over in issue 3132.)

----------
dependencies:  -implement PEP 3118 struct changes
nosy: +mark.dickinson
resolution:  -> duplicate
status: open -> closed
superseder:  -> implement PEP 3118 struct changes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2395>
_______________________________________

From report at bugs.python.org  Sun Feb 21 14:09:19 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Feb 2010 13:09:19 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1266757759.88.0.224207825807.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Meador Inge]
> So the next step is to kick off a thread on python-dev summarizing the
> questions\problems we have come up with?  I can get that started.

Sounds good.  I'd really like to see some examples of how these struct-module additions would be used in real life.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Sun Feb 21 14:33:12 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Feb 2010 13:33:12 +0000
Subject: [issue7384] curses crash on FreeBSD
In-Reply-To: <1259006628.77.0.121355571453.issue7384@psf.upfronthosting.co.za>
Message-ID: <1266759192.95.0.905787504007.issue7384@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> It does appear that curses itself is broken on FreeBSD

Rereading this, it doesn't say what I meant it to say:  I meant that the Python curses module seems to be broken, not that the system-level curses library is broken (though that seems possible too).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7384>
_______________________________________

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: [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 15:14:12 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Feb 2010 14:14:12 +0000
Subject: [issue7974] Valgrind error when running Python command within Vim
In-Reply-To: <1266761062.18.0.173748987708.issue7974@psf.upfronthosting.co.za>
Message-ID: <1266761652.9.0.681813207828.issue7974@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The code you identify looks okay to me:  in PyMarshal_ReadObjectFromString, isn't it only the temporary variable rf that has a pointer to the string?

Have you read Misc/README.valgrind in the Python source?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7974>
_______________________________________

From report at bugs.python.org  Sun Feb 21 15:36:53 2010
From: report at bugs.python.org (=?utf-8?q?Dominique_Pell=C3=A9?=)
Date: Sun, 21 Feb 2010 14:36:53 +0000
Subject: [issue7974] Valgrind error when running Python command within Vim
In-Reply-To: <1266761062.18.0.173748987708.issue7974@psf.upfronthosting.co.za>
Message-ID: <1266763013.58.0.996846542756.issue7974@psf.upfronthosting.co.za>


Dominique Pell? <dominique.pelle at gmail.com> added the comment:

> Have you read Misc/README.valgrind in the Python source?

No, I had not see this file.
Thanks for pointing it to me.

I've just read it, reconfigured & recompiled Python-2.6.4 with:

./configure --without-pymalloc

It now runs without Valgrind error.

Sorry for the noise. 
This issue can thus be closed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7974>
_______________________________________

From report at bugs.python.org  Sun Feb 21 15:38:16 2010
From: report at bugs.python.org (=?utf-8?q?Dominique_Pell=C3=A9?=)
Date: Sun, 21 Feb 2010 14:38:16 +0000
Subject: [issue7974] Valgrind error when running Python command within Vim
In-Reply-To: <1266761062.18.0.173748987708.issue7974@psf.upfronthosting.co.za>
Message-ID: <1266763096.68.0.838510578783.issue7974@psf.upfronthosting.co.za>


Dominique Pell? <dominique.pelle at gmail.com> added the comment:

Closed: this was not a bug, I had to build Python lib with "configure --without-pymalloc" to avoid valgrind errors.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7974>
_______________________________________

From report at bugs.python.org  Sun Feb 21 15:46:42 2010
From: report at bugs.python.org (Alex Willmer)
Date: Sun, 21 Feb 2010 14:46:42 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1266435346.5.0.870584792242.issue2636@psf.upfronthosting.co.za>
Message-ID: <425e93af1002210646v7dd3d595hf3962d4da409f65@mail.gmail.com>


Alex Willmer <alex at moreati.org.uk> added the comment:

On 17 February 2010 19:35, Matthew Barnett <report at bugs.python.org> wrote:
> The main text at http://pypi.python.org/pypi/regex appears to have lost its backslashes, for example:
>
> ?? ??The Unicode escapes uxxxx and Uxxxxxxxx are supported.
>
> instead of:
>
> ?? ??The Unicode escapes \uxxxx and \Uxxxxxxxx are supported.

Matthew, As you no doubt realised that text is read straight from the
Features.txt file. PyPI interprets it as RestructuredText, which uses
\ as an escape character in various cases. Do you intentionally write
Features.txt as RestructuredText? If so here is a patch that escapes
the \ characters as appropriate, otherwise I'll work out how to make
PyPI read it as plain text.

Regards, Alex
-- 
Alex Willmer <alex at moreati.org.uk>
http://moreati.org.uk/blog

----------
Added file: http://bugs.python.org/file16278/Features-backslashes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________
-------------- next part --------------
=== modified file 'Features.txt'
--- Features.txt	2010-02-17 12:22:14 +0000
+++ Features.txt	2010-02-21 14:44:13 +0000
@@ -61,7 +61,7 @@
     regex.findall and regex.finditer support an 'overlapped' flag which permits overlapped matches
 
 Unicode escapes (#3665)
-    The Unicode escapes \uxxxx and \Uxxxxxxxx are supported.
+    The Unicode escapes \\uxxxx and \\Uxxxxxxxx are supported.
 
 Large patterns (#1160)
     Patterns can be much larger.
@@ -94,23 +94,23 @@
     Named groups can be named with (?<name>...) as well as the current (?P<name>...).
 
 Group references
-    Groups can be referenced within a pattern with \g<name>. This also allows there to be more than 99 groups.
+    Groups can be referenced within a pattern with \\g<name>. This also allows there to be more than 99 groups.
 
 Named characters
-    \N{name}
+    \\N{name}
     Named characters are supported.
 
 Unicode properties
-    \p{name}
-    \P{name}
-    Unicode properties are supported. \p{name} matches a character which has property 'name' and \P{name} matches a character which doesn't have property 'name'.
+    \\p{name}
+    \\P{name}
+    Unicode properties are supported. \\p{name} matches a character which has property 'name' and \\P{name} matches a character which doesn't have property 'name'.
 
 Posix character classes
     [[:alpha:]]
     Posix character classes are supported.
 
 Search anchor
-    \G
+    \\G
     A search anchor has been added. It matches at the position where each search started/continued and can be used for contiguous matches or in negative variable-length lookbehinds to limit how far back the lookbehind goes:
 
     >>> regex.findall(r"\w{2}", "abcd ef")


From report at bugs.python.org  Sun Feb 21 16:08:02 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Feb 2010 15:08:02 +0000
Subject: [issue7974] Valgrind error when running Python command within Vim
In-Reply-To: <1266761062.18.0.173748987708.issue7974@psf.upfronthosting.co.za>
Message-ID: <1266764882.48.0.249506516037.issue7974@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the update!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7974>
_______________________________________

From report at bugs.python.org  Sun Feb 21 16:08:31 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Feb 2010 15:08:31 +0000
Subject: [issue7974] Valgrind error when running Python command within Vim
In-Reply-To: <1266761062.18.0.173748987708.issue7974@psf.upfronthosting.co.za>
Message-ID: <1266764911.13.0.645023322546.issue7974@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> invalid

_______________________________________
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: [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 17:49:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 21 Feb 2010 16:49:19 +0000
Subject: [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: <1266770959.46.0.0879279805186.issue7975@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Could you please provide a complete example that demonstrates the problem?  A naive example using shelve with a dbhash database seems to work fine.

----------
nosy: +r.david.murray
priority:  -> normal
stage:  -> test needed
type:  -> behavior
versions: +Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7975>
_______________________________________

From report at bugs.python.org  Sun Feb 21 18:11:55 2010
From: report at bugs.python.org (sorin)
Date: Sun, 21 Feb 2010 17:11:55 +0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1266772315.95.0.479282473375.issue1722344@psf.upfronthosting.co.za>


sorin <sorin.sbarnea at gmail.com> added the comment:

Any idea if there is a nightly build for Python 2.6? The latest release was 2.6.4 and was 2 days before submitting the patch. 

Or the only alternative is to build it myself? Any ideas on when we could see 2.6.5? - I tried to look for a release timeline but I wasn't able to locate one.

----------
nosy: +sorin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_______________________________________

From report at bugs.python.org  Sun Feb 21 18:14:12 2010
From: report at bugs.python.org (Adam Collard)
Date: Sun, 21 Feb 2010 17:14:12 +0000
Subject: [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: <1266772452.51.0.569490358318.issue7975@psf.upfronthosting.co.za>


Adam Collard <adam.collard at gmail.com> added the comment:

Attached a simple example.

----------
Added file: http://bugs.python.org/file16280/dbshelve_example.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7975>
_______________________________________

From report at bugs.python.org  Sun Feb 21 19:40:06 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Feb 2010 18:40:06 +0000
Subject: [issue7977] I found Python 3.1 xmlrpc lib use "<param>" not properly.
	and i have fixed it.
In-Reply-To: <1266774979.92.0.0106793526152.issue7977@psf.upfronthosting.co.za>
Message-ID: <1266777606.4.0.0399725253505.issue7977@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Please could you generate and upload a patch against the Python source?  (For Windows, you can do this using the WinMerge tool, amongst others.)  I'm unable to open the file you attached on my machine:

"""No application knows how to open ... xmlrpc.client.modify.rar."""

If you could explain how "<param>" is being used improperly, that might also help.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7977>
_______________________________________

From report at bugs.python.org  Sun Feb 21 19:58:38 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Feb 2010 18:58:38 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1266698607.3.0.13844116025.issue7900@psf.upfronthosting.co.za>
Message-ID: <4B81825A.6040503@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I would suggest using my _DARWIN_C_SOURCE implementation
> unconditionally and make similar changes to posix_setgroups, but this
> is probably a subject for a separate issue.

I would propose a different strategy: if _SC_NGROUPS_MAX is defined, use
that to find out how much memory to allocate, otherwise, fall back to
the current max array size. Can you find out whether doing so would also
fix the issue at hand?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Sun Feb 21 20:23:10 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Feb 2010 19:23:10 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1266780190.16.0.213975872831.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

About long doubles again:  I just encountered someone on the #python IRC channel who wanted to know whether struct.pack and struct.unpack supported reading and writing of x87 80-bit long doubles (padded to 12 bytes each in the input).  A few quotes from him/her, with permission (responses from others, including me, edited out;  I can supply a fuller transcript if necessary, but I hope what's below isn't misleading).

[18:39] bdesk: Hi, is struct.pack able to handle 80-bit x86 extended floats?
[18:40] bdesk: How can I read and write these 80-bit floats, in binary, using python?
[18:44] bdesk: dickinsm: I have a C program that uses binary files as input and output, and I want to deal with these files using python if possible.
[18:49] bdesk: I don't need to do arithmetic with the full 80 bits of precision within the python program, although It would be better if I could.
[18:50] bdesk: I would need to use the float in a more semantically useful manner than treating it as a black box of 12 bytes.
[18:55] bdesk: Until python gets higher precision floats, my preferred interface would be to lose some precision when unpacking the floats.

The main thing that I realized from this is that unpacking as a ctypes long double isn't all that useful for someone who wants to be able to do arithmetic on the unpacked result.  And if you don't want to do arithmetic on the unpacked result, then you're probably just shuffling the bytes around without caring about their meaning, so there's no need to unpack as anything other than a sequence of 12 bytes.

On the other hand, I suppose it's enough to be able to unpack as a ctypes c_longdouble and then convert to a Python float (losing precision) for the arithmetic.  Alternatively, we might consider simply unpacking a long double directly into a Python float (and accepting the loss of precision);  that seems to be what would be most useful for the use-case above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Sun Feb 21 21:09:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 21 Feb 2010 20:09:34 +0000
Subject: [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: <1266782974.54.0.148166154671.issue7975@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The bug seems to have been introduced by an incomplete or incorrect translation to the newer idiom (DictMixin to MutableMapping).  Since bsddb is gone in py3, I'm inclined to fix it by just going back to using DictMixin.  There are no tests for the DictMixin functionality added in Python 2.3.

----------
components: +Library (Lib)
keywords: +easy
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7975>
_______________________________________

From report at bugs.python.org  Sun Feb 21 21:12:26 2010
From: report at bugs.python.org (Michael Newman)
Date: Sun, 21 Feb 2010 20:12:26 +0000
Subject: [issue6436] trace module doesn't seem to produce .cover files for Py3
	(but does for Py2)
In-Reply-To: <1247035057.94.0.368292747718.issue6436@psf.upfronthosting.co.za>
Message-ID: <1266783146.03.0.945566392413.issue6436@psf.upfronthosting.co.za>


Michael Newman <michael.b.newman at gmail.com> added the comment:

I noticed the same behavior today.

Let's consider a test case using my python script "version_check.py" (attached).

Normally the script does the following on my Ubuntu 9.10 box:

# Python 2.6 example:
mike at ebx2009:~/test$ which python
/usr/bin/python
mike at ebx2009:~/test$ python version_check.py
2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1]

# Python 3.1 example:
mike at ebx2009:~/test$ which python3
/usr/local/bin/python3
mike at ebx2009:~/test$ python3 version_check.py
3.1.1 (r311:74480, Feb  7 2010, 16:32:28) 
[GCC 4.4.1]

# Starting with a directory with only the script in it:
mike at ebx2009:~/test$ ls
version_check.py
# I use the "-C ." to force the ".cover" files to be dumped in my current directory:
mike at ebx2009:~/test$ python -m trace --count -C . version_check.py 
2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1]
mike at ebx2009:~/test$ ls
threading.cover  version_check.cover  version_check.py
# So this worked fine.

# Let's remove the cover files and try with Python 3.1:
mike at ebx2009:~/test$ rm *.cover
mike at ebx2009:~/test$ ls
version_check.py
mike at ebx2009:~/test$ python3 -m trace --count -C . version_check.py 
3.1.1 (r311:74480, Feb  7 2010, 16:32:28) 
[GCC 4.4.1]
mike at ebx2009:~/test$ ls
threading.cover  version_check.py
# Its annoying that the threading.cover is still being made, but "version_check.cover" did not get generated in any case...

I tracked the problem down inside of lib/trace.py (same code in both python versions):

    def localtrace_count(self, frame, why, arg):
        if why == "line":
            filename = frame.f_code.co_filename
            print(frame.f_code.co_filename)  # my new debug line
            lineno = frame.f_lineno
            key = filename, lineno
            self.counts[key] = self.counts.get(key, 0) + 1
        return self.localtrace

If you put my print debug line in, we get some more interesting behavior from my example runs:

mike at ebx2009:~/test$ python -m trace --count -C . version_check.py 
/usr/lib/python2.6/threading.py
<string>
version_check.py
version_check.py
version_check.py
version_check.py
version_check.py
version_check.py
2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1]

mike at ebx2009:~/test$ python3 -m trace --count -C . version_check.py 
/usr/local/lib/python3.1/threading.py
<string>
<string>
<string>
<string>
<string>
<string>
<string>
3.1.1 (r311:74480, Feb  7 2010, 16:32:28) 
[GCC 4.4.1]

So python3 is not retaining the module name correctly. Instead its just giving "<string>". So the bottom line is "frame.f_code.co_filename" is now behaving differently. I'm not sure how to fix that.

----------
nosy: +mnewman
versions: +Python 3.2
Added file: http://bugs.python.org/file16282/version_check.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6436>
_______________________________________

From report at bugs.python.org  Sun Feb 21 21:23:07 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Sun, 21 Feb 2010 20:23:07 +0000
Subject: [issue7806] httplib.HTTPConnection.getresponse closes socket which
	destroys the response
In-Reply-To: <1266642361.4.0.665486577298.issue7806@psf.upfronthosting.co.za>
Message-ID: <e8bf7a531002211223p4ff2941es5240b517f8d87e49@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

On Sat, Feb 20, 2010 at 12:06 AM, R. David Murray
<report at bugs.python.org> wrote:
>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> But the docs (which presumably describe the API) say that the socket is unusable after the call to close, which argues that the paramiko sockets are following the documented API. ?Do the docs need to be corrected?

I mean the documented socket API.

Jeremy

> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7806>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7806>
_______________________________________

From report at bugs.python.org  Sun Feb 21 21:32:23 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Sun, 21 Feb 2010 20:32:23 +0000
Subject: [issue7806] httplib.HTTPConnection.getresponse closes socket which
	destroys the response
In-Reply-To: <e8bf7a531002211223p4ff2941es5240b517f8d87e49@mail.gmail.com>
Message-ID: <e8bf7a531002211232o9d7331asa856368f763208a0@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

In particular, I mean this part of the socket API:

socket.makefile([mode[, bufsize]])
Return a file object associated with the socket. (File objects are
described in File Objects.) The file object references a dup()ped
version of the socket file descriptor, so the file object and socket
object may be closed or garbage-collected independently. The socket
must be in blocking mode (it can not have a timeout). The optional
mode and bufsize arguments are interpreted the same way as by the
built-in file() function.

The language may be a little vague, but it means that closing the file
generated by makefile() should not close the underlying socket.

Jeremy

On Sun, Feb 21, 2010 at 3:23 PM, Jeremy Hylton <report at bugs.python.org> wrote:
>
> Jeremy Hylton <jeremy at alum.mit.edu> added the comment:
>
> On Sat, Feb 20, 2010 at 12:06 AM, R. David Murray
> <report at bugs.python.org> wrote:
>>
>> R. David Murray <rdmurray at bitdance.com> added the comment:
>>
>> But the docs (which presumably describe the API) say that the socket is unusable after the call to close, which argues that the paramiko sockets are following the documented API. ?Do the docs need to be corrected?
>
> I mean the documented socket API.
>
> Jeremy
>
>> ----------
>>
>> _______________________________________
>> Python tracker <report at bugs.python.org>
>> <http://bugs.python.org/issue7806>
>> _______________________________________
>>
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7806>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7806>
_______________________________________

From jeremy at alum.mit.edu  Sun Feb 21 21:32:19 2010
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Sun, 21 Feb 2010 15:32:19 -0500
Subject: [issue7806] httplib.HTTPConnection.getresponse closes socket 
	which destroys the response
In-Reply-To: <e8bf7a531002211223p4ff2941es5240b517f8d87e49@mail.gmail.com>
References: <1266642361.4.0.665486577298.issue7806@psf.upfronthosting.co.za>
	<e8bf7a531002211223p4ff2941es5240b517f8d87e49@mail.gmail.com>
Message-ID: <e8bf7a531002211232o9d7331asa856368f763208a0@mail.gmail.com>

In particular, I mean this part of the socket API:

socket.makefile([mode[, bufsize]])
Return a file object associated with the socket. (File objects are
described in File Objects.) The file object references a dup()ped
version of the socket file descriptor, so the file object and socket
object may be closed or garbage-collected independently. The socket
must be in blocking mode (it can not have a timeout). The optional
mode and bufsize arguments are interpreted the same way as by the
built-in file() function.

The language may be a little vague, but it means that closing the file
generated by makefile() should not close the underlying socket.

Jeremy

On Sun, Feb 21, 2010 at 3:23 PM, Jeremy Hylton <report at bugs.python.org> wrote:
>
> Jeremy Hylton <jeremy at alum.mit.edu> added the comment:
>
> On Sat, Feb 20, 2010 at 12:06 AM, R. David Murray
> <report at bugs.python.org> wrote:
>>
>> R. David Murray <rdmurray at bitdance.com> added the comment:
>>
>> But the docs (which presumably describe the API) say that the socket is unusable after the call to close, which argues that the paramiko sockets are following the documented API. ?Do the docs need to be corrected?
>
> I mean the documented socket API.
>
> Jeremy
>
>> ----------
>>
>> _______________________________________
>> Python tracker <report at bugs.python.org>
>> <http://bugs.python.org/issue7806>
>> _______________________________________
>>
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7806>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

From report at bugs.python.org  Sun Feb 21 21:34:13 2010
From: report at bugs.python.org (Michael Newman)
Date: Sun, 21 Feb 2010 20:34:13 +0000
Subject: [issue7929] Update copyright notice on python websites to 2010
In-Reply-To: <1266187576.54.0.0602259952978.issue7929@psf.upfronthosting.co.za>
Message-ID: <1266784453.98.0.0416155727262.issue7929@psf.upfronthosting.co.za>


Michael Newman <michael.b.newman at gmail.com> added the comment:

Perhaps this is now really a "bug":

# Response to e-mail to "webmaster at python.org":
#

This is the mail system at host mail.python.org.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                  The mail system

<webmaster-replybot at mail.python.org> (expanded from <webmaster at python.org>):
   Command died with status 1: "/usr/bin/replybot -C /etc/replybot.cfg -s
   WEBMASTER". Command output: Traceback (most recent call last):   File
   "/usr/bin/replybot", line 5, in <module>     from pkg_resources import
   load_entry_point ImportError: No module named pkg_resources

Final-Recipient: rfc822; webmaster-replybot at mail.python.org
Original-Recipient: rfc822;webmaster at python.org
Action: failed
Status: 5.3.0
Diagnostic-Code: x-unix; Traceback (most recent call last):   File
   "/usr/bin/replybot", line 5, in <module>     from pkg_resources import
   load_entry_point ImportError: No module named pkg_resources


---------- Forwarded message ----------
From: Michael Newman <michael.b.newman at gmail.com>
To: webmaster at python.org
Date: Sun, 21 Feb 2010 15:31:31 -0500
Subject: please update copyright to show 2010
Please consider fixing this bug:

"Update copyright notice on python websites to 2010"
http://bugs.python.org/issue7929

Thanks for maintaining a great website.

-Mike

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7929>
_______________________________________

From report at bugs.python.org  Sun Feb 21 21:42:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 21 Feb 2010 20:42:25 +0000
Subject: [issue7806] httplib.HTTPConnection.getresponse closes socket which
	destroys the response
In-Reply-To: <1264777311.04.0.988942468984.issue7806@psf.upfronthosting.co.za>
Message-ID: <1266784945.18.0.803665392273.issue7806@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

So do I.  I'm saying that paramiko appears to be following the socket API as documented in the python docs (ie: that closing the socket means it is no longer usable).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7806>
_______________________________________

From report at bugs.python.org  Sun Feb 21 21:45:28 2010
From: report at bugs.python.org (Michael Newman)
Date: Sun, 21 Feb 2010 20:45:28 +0000
Subject: [issue7929] Update copyright notice on python websites to 2010
In-Reply-To: <1266187576.54.0.0602259952978.issue7929@psf.upfronthosting.co.za>
Message-ID: <1266785128.26.0.947671222643.issue7929@psf.upfronthosting.co.za>


Michael Newman <michael.b.newman at gmail.com> added the comment:

I posted the copyright note, and the reply bot bug on the wiki at:
http://wiki.python.org/moin/SiteImprovements

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7929>
_______________________________________

From report at bugs.python.org  Sun Feb 21 21:49:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 21 Feb 2010 20:49:00 +0000
Subject: [issue7806] httplib.HTTPConnection.getresponse closes socket which
	destroys the response
In-Reply-To: <1264777311.04.0.988942468984.issue7806@psf.upfronthosting.co.za>
Message-ID: <1266785340.11.0.591960751436.issue7806@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

So HTTConnection is closing the thing returned by makefile and that is closing the socket, except that the socket library makes sure it doesn't actually close the socket until the dupped file handle is also closed?  I guess I need to look at this more closely when I have time in order to fully understand it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7806>
_______________________________________

From report at bugs.python.org  Sun Feb 21 21:50:25 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 21 Feb 2010 20:50:25 +0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1266785425.44.0.22603294541.issue1722344@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I have seen somewhere (ask google), that python 2.6.5 would be released mid-march.
But except for a few platforms, python.org does not provide compiled binaries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_______________________________________

From report at bugs.python.org  Sun Feb 21 22:33:12 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 21 Feb 2010 21:33:12 +0000
Subject: [issue7964] "-m pdb" SyntaxError for "\r\n" formatted py files
In-Reply-To: <1266583937.16.0.516750395183.issue7964@psf.upfronthosting.co.za>
Message-ID: <1266787992.88.0.0791996374702.issue7964@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I'm interested in finding a workaround for this issue in the next 24 hours. I can also help contribute a test case. I'll investigate further.

----------
nosy: +jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7964>
_______________________________________

From report at bugs.python.org  Sun Feb 21 22:55:11 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Feb 2010 21:55:11 +0000
Subject: [issue7929] Update copyright notice on python websites to 2010
In-Reply-To: <1266187576.54.0.0602259952978.issue7929@psf.upfronthosting.co.za>
Message-ID: <1266789311.39.0.463313858809.issue7929@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Closing as fixed, as the replybot issue is listed on the wiki.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7929>
_______________________________________

From report at bugs.python.org  Sun Feb 21 23:13:22 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 21 Feb 2010 22:13:22 +0000
Subject: [issue7964] "-m pdb" SyntaxError for "\r\n" formatted py files
In-Reply-To: <1266583937.16.0.516750395183.issue7964@psf.upfronthosting.co.za>
Message-ID: <1266790402.19.0.722272363764.issue7964@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Attached is a patch against the py3k branch that fixes the issue by changing the mode used to open the target script. It includes a unittest that elicits the issue and validates the fix.

The patch should also probably be applied to the 31maint branch.

----------
keywords: +patch
Added file: http://bugs.python.org/file16283/issue 7964 fix with test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7964>
_______________________________________

From report at bugs.python.org  Sun Feb 21 23:15:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 21 Feb 2010 22:15:20 +0000
Subject: [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: <1266790520.54.0.228265854321.issue7975@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here's a patch.  test_bsddb3 still passes with this patch applied on trunk.

----------
assignee:  -> r.david.murray
keywords: +patch
stage: test needed -> patch review
Added file: http://bugs.python.org/file16284/dbshelve_dictmixin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7975>
_______________________________________

From report at bugs.python.org  Sun Feb 21 23:29:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 21 Feb 2010 22:29:14 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <4B81825A.6040503@v.loewis.de>
Message-ID: <d38f5331002211429k1e1d6d2ar20d26b094f665282@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Sun, Feb 21, 2010 at 1:58 PM, Martin v. L?wis <report at bugs.python.org> wrote:
..
> I would propose a different strategy: if _SC_NGROUPS_MAX is defined, use
> that to find out how much memory to allocate, otherwise, fall back to
> the current max array size. Can you find out whether doing so would also
> fix the issue at hand?

I am afraid that the following is the evidence that it won't:

Python 2.7a3+ (trunk:78265M, Feb 20 2010, 15:20:36)
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.sysconf('SC_NGROUPS_MAX')
16
>>> len(os.getgroups())  # with the patch
22

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Sun Feb 21 23:38:20 2010
From: report at bugs.python.org (Robert Buchholz)
Date: Sun, 21 Feb 2010 22:38:20 +0000
Subject: [issue7806] httplib.HTTPConnection.getresponse closes socket which
	destroys the response
In-Reply-To: <1264777311.04.0.988942468984.issue7806@psf.upfronthosting.co.za>
Message-ID: <1266791900.19.0.0648832406097.issue7806@psf.upfronthosting.co.za>


Robert Buchholz <rbu at freitagsrunde.org> added the comment:

almost... HTTPConnection is calling close() on the socket object, but HTTPResponse still has an open file-like object from a previous makefile() call. That object still has an internal reference to the socket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7806>
_______________________________________

From report at bugs.python.org  Sun Feb 21 23:56:37 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Sun, 21 Feb 2010 22:56:37 +0000
Subject: [issue7806] httplib.HTTPConnection.getresponse closes socket which
	destroys the response
In-Reply-To: <1266791900.19.0.0648832406097.issue7806@psf.upfronthosting.co.za>
Message-ID: <e8bf7a531002211456v7d99c833rbc07d666f5c33455@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

On Sun, Feb 21, 2010 at 5:38 PM, Robert Buchholz <report at bugs.python.org> wrote:
>
> Robert Buchholz <rbu at freitagsrunde.org> added the comment:
>
> almost... HTTPConnection is calling close() on the socket object, but HTTPResponse still has an open file-like object from a previous makefile() call. That object still has an internal reference to the socket.

That's right.  The makefile() method on sockets works that way, and
the HTTP library depends on that behavior (and pretty much always
has).

Jeremy

>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7806>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7806>
_______________________________________

From report at bugs.python.org  Mon Feb 22 01:30:44 2010
From: report at bugs.python.org (Meador Inge)
Date: Mon, 22 Feb 2010 00:30:44 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1266798644.17.0.525858365169.issue5211@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> I added a ".. versionchanged" note to the documentation, and fixed a 
> couple of whitespace issues;

Thanks.  I checked out the changes you made so that I will know what to do next time :).

> Fixed now, with apologies to Meador.

No worries.  Thanks for applying the patch!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________

From report at bugs.python.org  Mon Feb 22 02:39:49 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 22 Feb 2010 01:39:49 +0000
Subject: [issue7232] Support of 'with' statement fo TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1266802789.93.0.804931063555.issue7232@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Here is a patch which expands on Jaime's patch. I was converting tests for #7944 and looked at test_tarfile, and implemented the same feature that he did.

All places where context managers should be used in the test, they are used. Includes a doc update with a small example.

----------
keywords: +needs review
nosy: +brian.curtin
Added file: http://bugs.python.org/file16285/issue7944_tarfile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________

From report at bugs.python.org  Mon Feb 22 02:44:42 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 22 Feb 2010 01:44:42 +0000
Subject: [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: <1266803082.55.0.0175333911651.issue7944@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'm going to go ahead with the patch-per-module approach, but anyone feel free to stop me from doing that.

Here's a patch for test_gzip on trunk.

----------
Added file: http://bugs.python.org/file16286/issue7944_gzip.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7944>
_______________________________________

From report at bugs.python.org  Mon Feb 22 03:15:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Feb 2010 02:15:05 +0000
Subject: [issue7806] httplib.HTTPConnection.getresponse closes socket which
	destroys the response
In-Reply-To: <1264777311.04.0.988942468984.issue7806@psf.upfronthosting.co.za>
Message-ID: <1266804905.74.0.0468763180166.issue7806@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

OK, then I think I understand Jeremy's point now: the paramiko socket is apparently not implementing makefile in a way that matches the documented API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7806>
_______________________________________

From report at bugs.python.org  Mon Feb 22 03:19:39 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Mon, 22 Feb 2010 02:19:39 +0000
Subject: [issue7245] better Ctrl-C support in pdb (program can be resumed)
In-Reply-To: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
Message-ID: <1266805179.97.0.909638132189.issue7245@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

I fixed some of the style issues mentioned on appspot. (I was not sure about some of them and responded to them in appspot comments).

Also sigHandler became sighandler for consistency with the rest of pdb.py.  

The new version of the patch is attached.

However, it appears that I've been a bit over-optimistic about the lack of side-effects. In particular, the patch results in an very ugly error message when Ctrl-C is pressed while at pdb prompt..


*** AttributeError: AttributeError("'NoneType' object has no attribute 'f_globals'",)

Everything still seems to be working, but it's definitely ugly (and behaves differently on Windows and Linux).

I will try to summarize possible Ctrl-C scenarios in a separate post

----------
Added file: http://bugs.python.org/file16288/sig.patch.v1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7245>
_______________________________________

From report at bugs.python.org  Mon Feb 22 03:21:45 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 22 Feb 2010 02:21:45 +0000
Subject: [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: <1266805305.16.0.73468143351.issue7944@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Here's a patch for test_tempfile on trunk. The rest will just be silently added since this is already annoying.

----------
Added file: http://bugs.python.org/file16289/issue7944_tempfile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7944>
_______________________________________

From report at bugs.python.org  Mon Feb 22 03:58:58 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 22 Feb 2010 02:58:58 +0000
Subject: [issue4199] add shorthand global and nonlocal statements
In-Reply-To: <1224887535.03.0.272495603252.issue4199@psf.upfronthosting.co.za>
Message-ID: <1266807538.13.0.356720589807.issue4199@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Bumping priority so this doesn't get forgotten before 3.2; it seems important because it fixes noncompliance with a PEP.

----------
nosy: +akuchling
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4199>
_______________________________________

From report at bugs.python.org  Mon Feb 22 04:00:52 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Mon, 22 Feb 2010 03:00:52 +0000
Subject: [issue7245] better Ctrl-C support in pdb (program can be resumed)
In-Reply-To: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
Message-ID: <1266807652.76.0.40947482415.issue7245@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

Here is a list of Ctrl-C scenarios: ("current" below means the prepatch version of pdb).

1. program is running (last command was "c", "n", etc). Currently, Ctrl-C throws debugger into postmortem. Desired behavior: interrupt the program. This is the only scenario supported by the patch.

2. Program is stopped (debugger is interacting with the user). Currently, Ctrl-C will throw debugger into postmortem. Desired behaviour: either ignore Ctrl-C or abandon the current command (that's what gdb does).

3. Program is stopped and pdb runs one of the commands which catch exceptions (e.g "p"). Currently, Ctrl-C will abort the command and return pdb to the prompt. I think this behavior should be kept.

4. Program finished (debugger is in postmortem). Currently, Ctrl-C will quit the debugger. Desired behavior: either ignore Ctrl-C or abandon the current command.

Essentially, I think the best behavior is to have Ctrl-C to interrupt whatever pdb is doing and return to the fresh prompt.

I am assuming that behavior on Windows and Linux should be identical/nearly identical.

Does the above list make sense?

I would greatly appreciate any feedback/comments/guidance/etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7245>
_______________________________________

From report at bugs.python.org  Mon Feb 22 04:22:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Feb 2010 03:22:25 +0000
Subject: [issue7232] Support of 'with' statement fo TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1266808945.61.0.69227701504.issue7232@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Woops, I accidentally deleted one of the patch files.  Adding back.

----------
nosy: +r.david.murray
Added file: http://bugs.python.org/file16291/tarfileWithSupportv2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________

From report at bugs.python.org  Mon Feb 22 05:12:11 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 22 Feb 2010 04:12:11 +0000
Subject: [issue1481] test_uuid is warning about unreliable functions
In-Reply-To: <1195633068.63.0.82173012127.issue1481@psf.upfronthosting.co.za>
Message-ID: <1266811931.66.0.690383541049.issue1481@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

They were disabled in r50949, with the comment:
========
Disable these tests until they are reliable across platforms.  
These problems may mask more important, real problems.

One or both methods are known to fail on: Solaris, OpenBSD, Debian, Ubuntu.
They pass on Windows and some Linux boxes.
========

Some of them seem to only work on one platform, so maybe someone could write some platform-checking code to skip tests as necessary.

----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481>
_______________________________________

From report at bugs.python.org  Mon Feb 22 05:13:55 2010
From: report at bugs.python.org (Meador Inge)
Date: Mon, 22 Feb 2010 04:13:55 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1266812035.18.0.0739013208388.issue3132@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> The main thing that I realized from this is that unpacking as a ctypes long 
> double isn't all that useful for someone who wants to be able to do arithmetic
> on the unpacked result.  

I agree.  Especially since ctypes 'long double' maps to a Python float and
'.value' would have to be referenced on the ctype 'long double' instance
for doing arithmetic.

> And if you don't want to do arithmetic on the unpacked result, then you're 
> probably just shuffling the bytes around without caring about their meaning,
> so there's no need to unpack as anything other than a sequence of 12 bytes.

One benefit of having a type code for 'long double' (assuming you are mapping
the value to the platform's 'long double') is that the you don't have to know 
how many bytes are in the underlying representation.  As you know, it isn't 
always just 12 bytes.  It depends on the architecture and ABI being used.  Which
from a quick sample, I am seeing can be anywhere from 8 to 16
bytes:

===========================================
| Compiler  | Arch     | Bytes            |
===========================================
| VC++ 8.0  | x86      | 8                |
| VC++ 9.0  | x86      | 8                |
| GCC 4.2.4 | x86      | 12 (default), 16 |
| GCC 4.2.4 | x86-64   | 12, 16 (default) |  
| GCC 4.2.4 | PPC IBM  | 16               |
| GCC 4.2.4 | PPC IEEE | 16               |
===========================================

> On the other hand, I suppose it's enough to be able to unpack as a ctypes 
> c_longdouble and then convert to a Python float (losing precision) for the 
> arithmetic.  Alternatively, we might consider simply unpacking a long double 
> directly into a Python float (and accepting the loss of precision);
 
I guess that would be acceptable.  The only thing that I don't like is that
since the transformation is lossy, you can't round trip:

   # this will not hold
   pack('g', unpack('g', byte_str)[0]) == byte_str

> that seems to be what would be most useful for the use-case above.

Which use case?  From the given IRC trace it seems that 'bdesk' was mainly
concerned with (1) pushing bytes around, but (2) thought it "it would be better"
to be able to do arithmetic and thought it would be more useful if it were
not a "black box of 12 bytes".  For use case (1) the loss of precision would 
probably not be acceptable, due to the round trip issue mentioned above.

So using ctypes 'long double' is easier to implement, but is lossy and clunky 
for arithmetic.  Using Python 'float' is easy to implement and easy for 
arithmetic, but is lossy.  Using Decimal is non-lossy and easy for arithmetic, 
but the implementation would be non-trivial and architecture specific 
(unless we just picked a fixed number of bytes regardless of the architecture).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Mon Feb 22 05:23:26 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 22 Feb 2010 04:23:26 +0000
Subject: [issue5099] subprocess.POpen.__del__() AttributeError (os module ==
	None!)
In-Reply-To: <1233244808.27.0.922840300181.issue5099@psf.upfronthosting.co.za>
Message-ID: <1266812606.89.0.796450505609.issue5099@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Gabriel: could you please update the patch to take Antoine's comment into account?

----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5099>
_______________________________________

From report at bugs.python.org  Mon Feb 22 10:02:28 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Feb 2010 09:02:28 +0000
Subject: [issue7961] Py3k: decoding empty bytestring with invalid encoding
	throws no error
In-Reply-To: <1266529462.35.0.7496345471.issue7961@psf.upfronthosting.co.za>
Message-ID: <1266829348.9.0.115684045612.issue7961@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I think it's better to close the ticket as "won't fix".

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7961>
_______________________________________

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: [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 12:23:32 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 22 Feb 2010 11:23:32 +0000
Subject: [issue7573] Python build issue on Ubuntu 9.10
In-Reply-To: <1261653981.05.0.861950270955.issue7573@psf.upfronthosting.co.za>
Message-ID: <1266837812.07.0.138262629763.issue7573@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This is documented, so I'd recommend to close this issue.

http://docs.python.org/3.1/c-api/intro.html#include-files

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7573>
_______________________________________

From report at bugs.python.org  Mon Feb 22 12:31:43 2010
From: report at bugs.python.org (Jelly Chen)
Date: Mon, 22 Feb 2010 11:31:43 +0000
Subject: [issue7977] I found Python 3.1 xmlrpc lib use "<param>" not properly.
	and i have fixed it.
In-Reply-To: <1266777606.4.0.0399725253505.issue7977@psf.upfronthosting.co.za>
Message-ID: <c37e78d81002220331g40d45e16v5468f2a63a195ec6@mail.gmail.com>


Jelly Chen <sinojelly at gmail.com> added the comment:

I can't modify the issue. so i replay this email.
The old xmlrpc lib don't use <param> surround a param. please take a look at
wrong.xml and right.xml.

2010/2/22 Mark Dickinson <report at bugs.python.org>

>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Please could you generate and upload a patch against the Python source?
>  (For Windows, you can do this using the WinMerge tool, amongst others.)
>  I'm unable to open the file you attached on my machine:
>
> """No application knows how to open ... xmlrpc.client.modify.rar."""
>
> If you could explain how "<param>" is being used improperly, that might
> also help.
>
> ----------
> nosy: +mark.dickinson
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7977>
> _______________________________________
>

----------
keywords: +patch
Added file: http://bugs.python.org/file16292/unnamed
Added file: http://bugs.python.org/file16293/xmlrpc.patch
Added file: http://bugs.python.org/file16294/wrong.xml
Added file: http://bugs.python.org/file16295/right.xml

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7977>
_______________________________________
-------------- next part --------------
I can&#39;t modify the issue. so i replay this email.<div>The old xmlrpc lib don&#39;t use &lt;param&gt;&nbsp;surround a param. please take a look at wrong.xml and right.xml.<br><br><div class="gmail_quote">2010/2/22 Mark Dickinson <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Mark Dickinson &lt;<a href="mailto:dickinsm at gmail.com">dickinsm at gmail.com</a>&gt; added the comment:<br>
<br>
Please could you generate and upload a patch against the Python source? &nbsp;(For Windows, you can do this using the WinMerge tool, amongst others.) &nbsp;I&#39;m unable to open the file you attached on my machine:<br>
<br>
&quot;&quot;&quot;No application knows how to open ... xmlrpc.client.modify.rar.&quot;&quot;&quot;<br>
<br>
If you could explain how &quot;&lt;param&gt;&quot; is being used improperly, that might also help.<br>
<br>
----------<br>
nosy: +mark.dickinson<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue7977" target="_blank">http://bugs.python.org/issue7977</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Contact me: &nbsp;<br>QQ: 2578717<br>MSN: <a href="mailto:sinojelly at msn.cn">sinojelly at msn.cn</a><br>???????????????<a href="http://t.sina.com.cn/sinojelly">http://t.sina.com.cn/sinojelly</a><br>
???????????????<a href="http://sinojelly.20x.cc">http://sinojelly.20x.cc</a><br><br><br>
</div>
-------------- next part --------------
diff -Nur xmlrpc\client.py modify\xmlrpc\client.py
--- xmlrpc\client.py	Thu Jun 04 17:11:52 2009
+++ modify\xmlrpc\client.py	Mon Feb 22 19:13:37 2010
@@ -49,6 +49,7 @@
 # 2003-07-12 gp  Correct marshalling of Faults
 # 2003-10-31 mvl Add multicall support
 # 2004-08-20 mvl Bump minimum supported Python version to 2.1
+# 2010-02-22 cgd Reorganize xmlrpc request message format (Chenguodong email:sinojelly at gmail.com)
 #
 # Copyright (c) 1999-2002 by Secret Labs AB.
 # Copyright (c) 1999-2002 by Fredrik Lundh.
@@ -508,9 +509,7 @@
             # is for now.  See @XMLRPC3 for more information. /F
             write("<params>\n")
             for v in values:
-                write("<param>\n")
                 dump(v, write)
-                write("</param>\n")
             write("</params>\n")
         result = "".join(out)
         return result
@@ -588,13 +587,25 @@
             raise TypeError("cannot marshal recursive sequences")
         self.memo[i] = None
         dump = self.__dump
+        for v in value:
+            write("<param>\n")
+            dump(v, write)
+            write("</param>\n")
+        del self.memo[i]
+    dispatch[tuple] = dump_array
+
+    def dump_list(self, value, write):
+        i = id(value)
+        if i in self.memo:
+            raise TypeError("cannot marshal recursive sequences")
+        self.memo[i] = None
+        dump = self.__dump
         write("<value><array><data>\n")
         for v in value:
             dump(v, write)
         write("</data></array></value>\n")
         del self.memo[i]
-    dispatch[tuple] = dump_array
-    dispatch[list] = dump_array
+    dispatch[list] = dump_list
 
     def dump_struct(self, value, write, escape=escape):
         i = id(value)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wrong.xml
Type: text/xml
Size: 516 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20100222/d77f9e97/attachment.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: right.xml
Type: text/xml
Size: 898 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20100222/d77f9e97/attachment-0001.xml>

From report at bugs.python.org  Mon Feb 22 13:05:24 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 22 Feb 2010 12:05:24 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1266840324.64.0.523035667238.issue7980@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

With 10.6's stock python, I've had this test either work or crash Python.

On trunk, I get it to either work or give the same error as the original report.

Unfortunately I've been unable to get it to crash again in a debugger so I can get a stack trace. But I'm still trying.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7980>
_______________________________________

From report at bugs.python.org  Mon Feb 22 13:24:22 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 22 Feb 2010 12:24:22 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1266841462.77.0.387661932776.issue7980@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Oops, sorry for not specifying that. It's:
Python 2.6.4 (r264:75706, Jan 27 2010, 12:09:19) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7980>
_______________________________________

From report at bugs.python.org  Mon Feb 22 13:35:25 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 22 Feb 2010 12:35:25 +0000
Subject: [issue7794] Document zipfile and directory execution in What's New
	for 2.6/3.1
In-Reply-To: <1264597975.95.0.291487626688.issue7794@psf.upfronthosting.co.za>
Message-ID: <1266842125.38.0.597131907062.issue7794@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As RDM said, it is AMK's What's New that is missing a description of this new feature. A lot of Python developers just read that document rather than trawling through the whole NEWS file for each major release.

I actually thought I had got AMK to add this before the 2.6 release, but it obviously slipped through the cracks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7794>
_______________________________________

From report at bugs.python.org  Mon Feb 22 13:53:08 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Feb 2010 12:53:08 +0000
Subject: [issue6625] UnicodeEncodeError on pydoc's CLI
In-Reply-To: <1249218048.23.0.0483172452601.issue6625@psf.upfronthosting.co.za>
Message-ID: <1266843188.47.0.79699211371.issue6625@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Patch with same tests as the previous one, but using better heuristic for output encoding (like Christoph patch).
Added the "replace" error handling, if the output encoding cannot encode all characters.

----------
Added file: http://bugs.python.org/file16296/issue6625_pydoc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6625>
_______________________________________

From report at bugs.python.org  Mon Feb 22 14:31:40 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 22 Feb 2010 13:31:40 +0000
Subject: [issue7928] String formatting: grammar wrongly limits [index] to
	integer
In-Reply-To: <1266146946.63.0.7361643831.issue7928@psf.upfronthosting.co.za>
Message-ID: <1266845500.89.0.376403856264.issue7928@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'm not exactly sure what wording to use here.

      element_index: `integer` | `identifier`

is not exactly correct, because it can be a non-identifier (as the example that eddy quotes points out. It's really "any sequence of characters except ']'".

Any ideas on the best way to express that? Maybe taking a clue from string literals, this would be:
      element_index: `integer` | index_string
      index_string: <any source character except "]"> +

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7928>
_______________________________________

From report at bugs.python.org  Mon Feb 22 14:39:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Feb 2010 13:39:04 +0000
Subject: [issue7977] I found Python 3.1 xmlrpc lib use "<param>" not properly.
	and i have fixed it.
In-Reply-To: <1266774979.92.0.0106793526152.issue7977@psf.upfronthosting.co.za>
Message-ID: <1266845944.02.0.690589390097.issue7977@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

The patch causes failures in test_xmlrpc, using Py3k branch.

----------
nosy: +flox
priority:  -> normal
stage:  -> test needed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7977>
_______________________________________

From report at bugs.python.org  Mon Feb 22 14:40:27 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 22 Feb 2010 13:40:27 +0000
Subject: [issue7928] String formatting: grammar wrongly limits [index] to
	integer
In-Reply-To: <1266146946.63.0.7361643831.issue7928@psf.upfronthosting.co.za>
Message-ID: <1266846027.13.0.561259711386.issue7928@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Proposed patch attached. The rest of the documentation in the following 2 paragraphs looks correct. It refers to __getitem__, which is how either strings or integers is looked up.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file16302/issue7928.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7928>
_______________________________________

From report at bugs.python.org  Mon Feb 22 15:01:09 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 22 Feb 2010 14:01:09 +0000
Subject: [issue7049] decimal.py: Three argument power issues
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1266847269.64.0.0753550909812.issue7049@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This is a very loosely related issue, but I think it fits in here.
To be consistent with the documentation, the three argument power
should use the ideal exponent:

>>> c = getcontext()
>>> c.prec = 400
>>> Decimal('1E400') % Decimal('1123123E5')
Decimal('8.45074E+10')
>>> pow(Decimal('1E400'), 1, (Decimal('1123123E5')))
Decimal('84507400000')

----------
title: decimal.py: NaN result in pow(x, y, z) with prec 1 -> decimal.py: Three argument power issues

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7049>
_______________________________________

From report at bugs.python.org  Mon Feb 22 15:19:16 2010
From: report at bugs.python.org (Jelly Chen)
Date: Mon, 22 Feb 2010 14:19:16 +0000
Subject: [issue7977] I found Python 3.1 xmlrpc lib use "<param>" not properly.
	and i have fixed it.
In-Reply-To: <1266845944.02.0.690589390097.issue7977@psf.upfronthosting.co.za>
Message-ID: <c37e78d81002220619j386228b3tf9c976831f068fe9@mail.gmail.com>


Jelly Chen <sinojelly at gmail.com> added the comment:

Can i have a look at the failure tests???
I just check out code at http://svn.python.org/projects/python/branches/py3k
It's very slow. and i'm afraid that i don't know how to run the tests.

The <param> tag use improperly is very clear.

the wrong case: very ugly, there is no difference between <param> and
<params>.
<params>
<param>
<value><data>
<value><int>1</int></value>
<value><string>sinojelly</string></value>
<value><string>123456</string></value>
<value><struct>
<member>
<name>description</name>
<value><string>Test description4</string></value>
</member>
<member>
<name>title</name>
<value><string>Test article3</string></value>
</member>
</struct></value>
<value><boolean>1</boolean></value>
</data></value>
</param>
</params>

the right one: there is a <param> around every parameter.
 <params>
  <param>
   <value>
    <string>479153</string>
   </value>
  </param>
  <param>
   <value>
    <string>sinojelly</string>
   </value>
  </param>
  <param>
   <value>
    <string>123456</string>
   </value>
  </param>
  <param>
   <value>
    <struct>
     <member>
      <name>title</name>
      <value>
       <string>Just Test.</string>
      </value>
     </member>
     <member>
      <name>description</name>
      <value>
       <string>&lt;p&gt;Just Test wlw post.&lt;/p&gt;</string>
      </value>
     </member>
     <member>
      <name>categories</name>
      <value>
       <array>
        <data />
       </array>
      </value>
     </member>
    </struct>
   </value>
  </param>
  <param>
   <value>
    <boolean>1</boolean>
   </value>
  </param>
 </params>

2010/2/22 Florent Xicluna <report at bugs.python.org>

>
> Florent Xicluna <laxyf at yahoo.fr> added the comment:
>
> The patch causes failures in test_xmlrpc, using Py3k branch.
>
> ----------
> nosy: +flox
> priority:  -> normal
> stage:  -> test needed
> versions: +Python 3.2
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7977>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file16303/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7977>
_______________________________________
-------------- next part --------------
Can i have a look at the failure tests???<div>I just check out code at&nbsp;<span class="Apple-style-span" style="font-family: Arial, Verdana, Geneva, &#39;Bitstream Vera Sans&#39;, Helvetica, sans-serif; font-size: 15px; line-height: 17px; -webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px; "><a class="reference external" href="http://svn.python.org/projects/python/branches/py3k" style="color: rgb(0, 0, 170); text-decoration: none; ">http://svn.python.org/projects/python/branches/py3k</a></span><br>
It&#39;s very slow. and i&#39;m afraid that i don&#39;t know how to run the tests.</div><div><br></div><div>The &lt;param&gt; tag use improperly is very clear.</div><div><br></div><div>the wrong case: very ugly, there is no difference between &lt;param&gt; and &lt;params&gt;.</div>
<div><div>&lt;params&gt;</div><div>&lt;param&gt;</div><div>&lt;value&gt;&lt;data&gt;</div><div>&lt;value&gt;&lt;int&gt;1&lt;/int&gt;&lt;/value&gt;</div><div>&lt;value&gt;&lt;string&gt;sinojelly&lt;/string&gt;&lt;/value&gt;</div>
<div>&lt;value&gt;&lt;string&gt;123456&lt;/string&gt;&lt;/value&gt;</div><div>&lt;value&gt;&lt;struct&gt;</div><div>&lt;member&gt;</div><div>&lt;name&gt;description&lt;/name&gt;</div><div>&lt;value&gt;&lt;string&gt;Test description4&lt;/string&gt;&lt;/value&gt;</div>
<div>&lt;/member&gt;</div><div>&lt;member&gt;</div><div>&lt;name&gt;title&lt;/name&gt;</div><div>&lt;value&gt;&lt;string&gt;Test article3&lt;/string&gt;&lt;/value&gt;</div><div>&lt;/member&gt;</div><div>&lt;/struct&gt;&lt;/value&gt;</div>
<div>&lt;value&gt;&lt;boolean&gt;1&lt;/boolean&gt;&lt;/value&gt;</div><div>&lt;/data&gt;&lt;/value&gt;</div><div>&lt;/param&gt;</div><div>&lt;/params&gt;</div></div><div><br></div><div>the right one: there is a &lt;param&gt; around every parameter.</div>
<div><div>&nbsp;&lt;params&gt;</div><div>&nbsp;&nbsp;&lt;param&gt;</div><div>&nbsp;&nbsp; &lt;value&gt;</div><div>&nbsp;&nbsp; &nbsp;&lt;string&gt;479153&lt;/string&gt;</div><div>&nbsp;&nbsp; &lt;/value&gt;</div><div>&nbsp;&nbsp;&lt;/param&gt;</div><div>&nbsp;&nbsp;&lt;param&gt;</div><div>&nbsp;&nbsp; &lt;value&gt;</div>
<div>&nbsp;&nbsp; &nbsp;&lt;string&gt;sinojelly&lt;/string&gt;</div><div>&nbsp;&nbsp; &lt;/value&gt;</div><div>&nbsp;&nbsp;&lt;/param&gt;</div><div>&nbsp;&nbsp;&lt;param&gt;</div><div>&nbsp;&nbsp; &lt;value&gt;</div><div>&nbsp;&nbsp; &nbsp;&lt;string&gt;123456&lt;/string&gt;</div><div>&nbsp;&nbsp; &lt;/value&gt;</div>
<div>&nbsp;&nbsp;&lt;/param&gt;</div><div>&nbsp;&nbsp;&lt;param&gt;</div><div>&nbsp;&nbsp; &lt;value&gt;</div><div>&nbsp;&nbsp; &nbsp;&lt;struct&gt;</div><div>&nbsp;&nbsp; &nbsp; &lt;member&gt;</div><div>&nbsp;&nbsp; &nbsp; &nbsp;&lt;name&gt;title&lt;/name&gt;</div><div>&nbsp;&nbsp; &nbsp; &nbsp;&lt;value&gt;</div><div>
&nbsp;&nbsp; &nbsp; &nbsp; &lt;string&gt;Just Test.&lt;/string&gt;</div><div>&nbsp;&nbsp; &nbsp; &nbsp;&lt;/value&gt;</div><div>&nbsp;&nbsp; &nbsp; &lt;/member&gt;</div><div>&nbsp;&nbsp; &nbsp; &lt;member&gt;</div><div>&nbsp;&nbsp; &nbsp; &nbsp;&lt;name&gt;description&lt;/name&gt;</div><div>&nbsp;&nbsp; &nbsp; &nbsp;&lt;value&gt;</div>
<div>&nbsp;&nbsp; &nbsp; &nbsp; &lt;string&gt;&amp;lt;p&amp;gt;Just Test wlw post.&amp;lt;/p&amp;gt;&lt;/string&gt;</div><div>&nbsp;&nbsp; &nbsp; &nbsp;&lt;/value&gt;</div><div>&nbsp;&nbsp; &nbsp; &lt;/member&gt;</div><div>&nbsp;&nbsp; &nbsp; &lt;member&gt;</div><div>&nbsp;&nbsp; &nbsp; &nbsp;&lt;name&gt;categories&lt;/name&gt;</div>
<div>&nbsp;&nbsp; &nbsp; &nbsp;&lt;value&gt;</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &lt;array&gt;</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;&lt;data /&gt;</div><div>&nbsp;&nbsp; &nbsp; &nbsp; &lt;/array&gt;</div><div>&nbsp;&nbsp; &nbsp; &nbsp;&lt;/value&gt;</div><div>&nbsp;&nbsp; &nbsp; &lt;/member&gt;</div><div>&nbsp;&nbsp; &nbsp;&lt;/struct&gt;</div><div>
&nbsp;&nbsp; &lt;/value&gt;</div><div>&nbsp;&nbsp;&lt;/param&gt;</div><div>&nbsp;&nbsp;&lt;param&gt;</div><div>&nbsp;&nbsp; &lt;value&gt;</div><div>&nbsp;&nbsp; &nbsp;&lt;boolean&gt;1&lt;/boolean&gt;</div><div>&nbsp;&nbsp; &lt;/value&gt;</div><div>&nbsp;&nbsp;&lt;/param&gt;</div><div>&nbsp;&lt;/params&gt;</div>
</div><div><br><br><div class="gmail_quote">2010/2/22 Florent Xicluna <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Florent Xicluna &lt;<a href="mailto:laxyf at yahoo.fr">laxyf at yahoo.fr</a>&gt; added the comment:<br>
<br>
The patch causes failures in test_xmlrpc, using Py3k branch.<br>
<br>
----------<br>
nosy: +flox<br>
priority: &nbsp;-&gt; normal<br>
stage: &nbsp;-&gt; test needed<br>
versions: +Python 3.2<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue7977" target="_blank">http://bugs.python.org/issue7977</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Contact me: &nbsp;<br>QQ: 2578717<br>MSN: <a href="mailto:sinojelly at msn.cn">sinojelly at msn.cn</a><br>???????????????<a href="http://t.sina.com.cn/sinojelly">http://t.sina.com.cn/sinojelly</a><br>
???????????????<a href="http://sinojelly.20x.cc">http://sinojelly.20x.cc</a><br><br><br>
</div>

From report at bugs.python.org  Mon Feb 22 15:55:07 2010
From: report at bugs.python.org (Mezhenin Artyom)
Date: Mon, 22 Feb 2010 14:55:07 +0000
Subject: [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:00:29 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 22 Feb 2010 15:00:29 +0000
Subject: [issue5988] Delete PyOS_ascii_formatd, PyOS_ascii_strtod,
	and PyOS_ascii_atof
In-Reply-To: <1241981743.74.0.769562552261.issue5988@psf.upfronthosting.co.za>
Message-ID: <1266850829.75.0.0423096936589.issue5988@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

These were originally deprecated in issue 5835.

Removed them from py3k in r78306.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Deprecate PyOS_ascii_formatd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5988>
_______________________________________

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: [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:12:38 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 22 Feb 2010 15:12:38 +0000
Subject: [issue5988] Delete PyOS_ascii_formatd, PyOS_ascii_strtod,
	and PyOS_ascii_atof
In-Reply-To: <1241981743.74.0.769562552261.issue5988@psf.upfronthosting.co.za>
Message-ID: <1266851558.36.0.790849878632.issue5988@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I closed this even though the functions remain in 2.7. They would not be removed until 2.8, and since 2.8 seems unlikely I'll close this. Even if there is a 2.8, then these functions will still be present but do no harm.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5988>
_______________________________________

From report at bugs.python.org  Mon Feb 22 16:21:11 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 22 Feb 2010 15:21:11 +0000
Subject: [issue7049] decimal.py: Three argument power issues
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1266852071.05.0.341612687541.issue7049@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The ideal exponent for three-argument pow should definitely be zero.  You're returning what's essentially an integer, loosely disguised as a decimal instance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7049>
_______________________________________

From report at bugs.python.org  Mon Feb 22 16:27:46 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 22 Feb 2010 15:27:46 +0000
Subject: [issue7310] Unhelpful __repr__() in os.environ
In-Reply-To: <1258026841.53.0.960128215471.issue7310@psf.upfronthosting.co.za>
Message-ID: <1266852466.62.0.123572536916.issue7310@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Do you have any preference about the text that should appear in the repr?
There have been some discussion on #python-dev about it, and the two main proposal were:
1) _Environ({...}) -> the right class name but kind of "ugly" and probably unnecessary (if no one cares about the name of the real class);
2) environ({...}) -> non-existing name, but enough to clarify that it's not a plain dict and less "ugly" name;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7310>
_______________________________________

From report at bugs.python.org  Mon Feb 22 16:34:23 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 22 Feb 2010 15:34:23 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1266852863.27.0.896457155031.issue7980@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Lib/_strptime.py itself should be thread-safe. I am guessing that it has something to do with the way the C code in time.c imports _strptime.py. A possible solution if it is the C code's import stuff is to create a time.py that imports a _time.c, but that's a total guess as to whether that will solve anything.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7980>
_______________________________________

From report at bugs.python.org  Mon Feb 22 16:40:51 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 22 Feb 2010 15:40:51 +0000
Subject: [issue4852] Cleanup old stuff from pythread.h
In-Reply-To: <1231198131.15.0.910339238584.issue4852@psf.upfronthosting.co.za>
Message-ID: <1266853251.94.0.210743690751.issue4852@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

The patch seems obviously correct to me; there's no way a user of pythread.h can make NO_EXIT_PROG be undefined.  The patch no long applies cleanly to thread_nt.h -- one hunk is rejected -- but it looks like the change in that hunk has already been applied (though I can't try compiling on Windows to verify that everything still works).  I did try applying the patch and re-compiling on Linux.

I think you can just apply it; if you're cautious, you could ask someone to try it on Windows first.

----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4852>
_______________________________________

From report at bugs.python.org  Mon Feb 22 16:43:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Feb 2010 15:43:36 +0000
Subject: [issue7310] Unhelpful __repr__() in os.environ
In-Reply-To: <1258026841.53.0.960128215471.issue7310@psf.upfronthosting.co.za>
Message-ID: <1266853416.33.0.662263139558.issue7310@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I like (2).  If someone tries to use the repr to recreate the object, it will fail with a message that mentions _Environ.  So no information is lost, I think, by using (2).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7310>
_______________________________________

From report at bugs.python.org  Mon Feb 22 16:43:43 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 22 Feb 2010 15:43:43 +0000
Subject: [issue7049] decimal.py: Three argument power issues
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1266853423.44.0.736073045997.issue7049@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've fixed the docs to accurately describe three-argument pow results (the exponent in particular) in r78312 through r78315.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7049>
_______________________________________

From report at bugs.python.org  Mon Feb 22 16:54:28 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Feb 2010 15:54:28 +0000
Subject: [issue7977] I found Python 3.1 xmlrpc lib use "<param>" not properly.
	and i have fixed it.
In-Reply-To: <1266774979.92.0.0106793526152.issue7977@psf.upfronthosting.co.za>
Message-ID: <1266854068.1.0.720437339905.issue7977@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

I didn't look at this issue in details.
I'm not a specialist of xmlrpc. But it is unlikely that the patch will be accepted, if it fails the regression tests.

Could you investigate this failure and provide a patch which fixes the tests? You could add a specific test related to this issue, too.

Command to run the tests (on linux):
        python -m test.regrtest test_xmlrpc
 
I've tested with 3.1 branch, and test_xmlrpc fails too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7977>
_______________________________________

From report at bugs.python.org  Mon Feb 22 16:55:20 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 22 Feb 2010 15:55:20 +0000
Subject: [issue7038] test_curses fails on os x 10.6
In-Reply-To: <1254515384.63.0.944831963301.issue7038@psf.upfronthosting.co.za>
Message-ID: <1266854120.64.0.815486993893.issue7038@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Closing this bug is fine with me.

----------
nosy: +akuchling
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7038>
_______________________________________

From report at bugs.python.org  Mon Feb 22 16:57:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Feb 2010 15:57:41 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266854261.19.0.272852387087.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Here is another interesting fact: Mac OS 10.6 comes with python 2.5 and 2.6 preinstalled:

$ python2.5 -V
Python 2.5.3c1
$ python2.6 -V
Python 2.6.1

Neither of these exhibit the same bug, but both are broken in some way.  Given

$ cat tg.py
import os
g = os.getgroups()
print g
os.setgroups(g[:5])
print os.getgroups()

$ sudo python2.5 tg.py
[0, 101, 204, 100, 98, 80, 61, 29, 20, 12, 9, 8, 5, 4, 3, 2]
[0, 101, 204, 100, 98]
$ sudo python2.6 tg.py
[0, 101, 204, 100, 98, 80, 61, 29, 20, 12, 9, 8, 5, 4, 3, 2, 1, 401]
[0, 101, 204, 100, 98, 80, 61, 29, 20, 12, 9, 8, 5, 4, 3, 2, 1, 401]

Note that python2.5 truncates the group list which is 
$ sudo id -G
0 101 204 100 98 80 61 29 20 12 9 8 5 4 3 2 1 401

but setgroups works as expected.  In contrast, python2.6 reports all groups correctly, but setgroups has no effect.

----------
Added file: http://bugs.python.org/file16306/tg.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

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: [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 16:59:21 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 22 Feb 2010 15:59:21 +0000
Subject: [issue7232] Support of 'with' statement fo TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1266854361.29.0.600482105086.issue7232@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The last patch does more than it should for this issue. Here is a minimal patch with the change, test, and doc updates.

----------
Added file: http://bugs.python.org/file16307/issue7232.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________

From report at bugs.python.org  Mon Feb 22 16:59:28 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Feb 2010 15:59:28 +0000
Subject: [issue7977] I found Python 3.1 xmlrpc lib use "<param>" not properly.
	and i have fixed it.
In-Reply-To: <1266774979.92.0.0106793526152.issue7977@psf.upfronthosting.co.za>
Message-ID: <1266854368.51.0.157548124545.issue7977@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Attached, the output of the test with "-v test_xmlrpc".

----------
Added file: http://bugs.python.org/file16308/issue7977_test_xmlrpc.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7977>
_______________________________________

From report at bugs.python.org  Mon Feb 22 17:00:56 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 22 Feb 2010 16:00:56 +0000
Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module
In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za>
Message-ID: <1266854456.6.0.97793828765.issue1657@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

What exactly needs to be finished in the documentation?  There are sections for the epoll and kqueue objects, and the epoll section looks fine, if brief.  Is the problem that the kqueue section says things like 'filter-specific data' with no explanation?

----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1657>
_______________________________________

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: [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:05:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Feb 2010 16:05:25 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266854725.18.0.360966800058.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Apparently, Apple patches posix_[gs]etgroups functions as follows:

for 2.5: http://www.opensource.apple.com/source/python/python-44/2.5/fix/posixmodule.c.ed

for 2.6: http://www.opensource.apple.com/source/python/python-44/2.6/fix/posixmodule.c.ed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Mon Feb 22 17:09:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Feb 2010 16:09:46 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1266854986.98.0.108157160334.issue7980@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

FYI there's been a proposal to create a time.py module anyway in order to add some pure python functions not worth writing in c.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7980>
_______________________________________

From report at bugs.python.org  Mon Feb 22 17:10:04 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 22 Feb 2010 16:10:04 +0000
Subject: [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: <1266855004.42.0.498754929856.issue7987@psf.upfronthosting.co.za>


Florent Xicluna <laxyf at yahoo.fr> added the comment:

Duplicate of #6494: "This is not a bug in Python. You need to build Python with SSL support for this to work."

----------
nosy: +flox
priority:  -> low
resolution:  -> duplicate
status: open -> closed
superseder:  -> xmlrpc client does not support HTTPS

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7987>
_______________________________________

From report at bugs.python.org  Mon Feb 22 17:14:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 22 Feb 2010 16:14:48 +0000
Subject: [issue3132] implement PEP 3118 struct changes
In-Reply-To: <1213741832.59.0.0620778602246.issue3132@psf.upfronthosting.co.za>
Message-ID: <1266855288.06.0.620082490934.issue3132@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> One benefit of having a type code for 'long double' (assuming you are
> mapping the value to the platform's 'long double') is that the you
> don't have to know how many bytes are in the underlying representation.

Agreed:  it's nice to have struct.pack already know your machine.

Actually, this brings up (yet) another open question:  native packing/unpacking of a long double would presumably return something corresponding to the platform long double, as above;  but non-native packing/unpacking should do something standard, instead, for the sake of interoperability between platforms.  Currently, I believe that packing a Python float always---even in native mode---packs in IEEE 754 format, even when the platform doubles aren't IEEE 754.

For native packing/unpacking, I'm slowly becoming convinced that unpacking as a ctypes long double is the only thing that makes any sense, so that we keep round-tripping, as you point out.  The user can easily enough extract the Python float for numerical work.  I still don't like having the struct module depend on ctypes, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3132>
_______________________________________

From report at bugs.python.org  Mon Feb 22 17:17:40 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 22 Feb 2010 16:17:40 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266855460.34.0.245030519988.issue7900@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

And as usual they can't be bothered to describe what the patch does, or even use regular universal diffs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

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: [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 17:27:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Feb 2010 16:27:55 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266856075.17.0.794339023287.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I've converted apple patches to unified diffs, but I cannot reproduce 2.5 behavior.

----------
Added file: http://bugs.python.org/file16309/apple-2.5-fix-posixmodule.c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Mon Feb 22 17:33:53 2010
From: report at bugs.python.org (Jack Diederich)
Date: Mon, 22 Feb 2010 16:33:53 +0000
Subject: [issue4331] Can't use _functools.partial() created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1266856433.18.0.741826606159.issue4331@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

I'm having some trouble wrapping my head around this one.  It isn't obvious to me that
my_method(*args):
  print(args)
class A():
  meth = partial(my_method, 'argA')
ob = A()
ob.meth('argB')

should print (<A object at 0x1234>, 'argA', 'argB') and not
('argA', <A object at 0x1234>, 'argB')

The patch seems to prefer the first form but if you are using a partial shouldn't you expect 'argA' to always be the first argument to the partial-ized function?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4331>
_______________________________________

From report at bugs.python.org  Mon Feb 22 18:09:08 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 22 Feb 2010 17:09:08 +0000
Subject: [issue6243] getkey() can segfault in combination with curses.ungetch()
In-Reply-To: <1244493374.77.0.425204214179.issue6243@psf.upfronthosting.co.za>
Message-ID: <1266858548.24.0.379291193849.issue6243@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Backported to 2.6-maint in commit 78324.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6243>
_______________________________________

From report at bugs.python.org  Mon Feb 22 18:16:16 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 22 Feb 2010 17:16:16 +0000
Subject: [issue4174] Performance optimization for min() and max() over lists
In-Reply-To: <1224688689.45.0.882872543074.issue4174@psf.upfronthosting.co.za>
Message-ID: <1266858976.84.0.0750338119348.issue4174@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Should this patch just be rejected, then?  Or is the more general locking suggested in msg88021 of interest?

----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4174>
_______________________________________

From report at bugs.python.org  Mon Feb 22 18:20:54 2010
From: report at bugs.python.org (Jack Diederich)
Date: Mon, 22 Feb 2010 17:20:54 +0000
Subject: [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: <1266859254.58.0.356291785816.issue7850@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

-1, my Ubuntu laptop says "linux2" and not "ubuntu." This would also be an incompatible change that would cause headaches with little benefit to balance it out.

----------
nosy: +jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7850>
_______________________________________

From report at bugs.python.org  Mon Feb 22 18:23:06 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 22 Feb 2010 17:23:06 +0000
Subject: [issue7399] Possible bug in Python Tutorial
In-Reply-To: <1259253026.9.0.615339023248.issue7399@psf.upfronthosting.co.za>
Message-ID: <1266859386.86.0.729296028824.issue7399@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r78325, r78326.

----------
assignee: georg.brandl -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7399>
_______________________________________

From report at bugs.python.org  Mon Feb 22 18:24:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Feb 2010 17:24:02 +0000
Subject: [issue4174] Performance optimization for min() and max() over lists
In-Reply-To: <1224688689.45.0.882872543074.issue4174@psf.upfronthosting.co.za>
Message-ID: <1266859442.12.0.681395267387.issue4174@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think the patch should just be rejected. Workloads where min() / max() performance is a bottleneck have to be very rare.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4174>
_______________________________________

From report at bugs.python.org  Mon Feb 22 18:25:54 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 22 Feb 2010 17:25:54 +0000
Subject: [issue4174] Performance optimization for min() and max() over lists
In-Reply-To: <1224688689.45.0.882872543074.issue4174@psf.upfronthosting.co.za>
Message-ID: <1266859554.75.0.360459599505.issue4174@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I agree that the performance improvement isn't worth the extra code, or the risk of introducing bugs (the comments so far show that it's not trivial to get this right).

Closing as rejected.

----------
nosy: +mark.dickinson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4174>
_______________________________________

From report at bugs.python.org  Mon Feb 22 18:52:47 2010
From: report at bugs.python.org (=?utf-8?b?TWljaGFsIEJvxb5vxYg=?=)
Date: Mon, 22 Feb 2010 17:52:47 +0000
Subject: [issue6312] httplib fails with HEAD requests to pages with
	"transfer-encoding: chunked"
In-Reply-To: <1245419610.47.0.800823464354.issue6312@psf.upfronthosting.co.za>
Message-ID: <1266861167.66.0.775985747192.issue6312@psf.upfronthosting.co.za>


Michal Bo?o? <michal.bozon at gmail.com> added the comment:

i confirm..

in my case, the bug manifestated when calling HEAD method on a different server with chunked transfer encoding (http://obrazky.cz)

my workaround is to call response.read() always, except from cases when method == 'HEAD' and resp.getheader('transfer-encoding') == 'chunked

----------
nosy: +mykhal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6312>
_______________________________________

From report at bugs.python.org  Mon Feb 22 19:27:01 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 22 Feb 2010 18:27:01 +0000
Subject: [issue5368] curses patch add color_set and wcolor_set ,
	and addchstr family of functions
In-Reply-To: <1235583031.0.0.493464972804.issue5368@psf.upfronthosting.co.za>
Message-ID: <1266863221.69.0.528535480764.issue5368@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Thanks for the patches!  Two comments on the addchstr change:

* I think that, instead of checking for a list, the method should accept any Python sequence; a tuple is perfectly reasonable, for example, and if the code is changed to use PyCurses_ConvertToChType() instead of PyInt_Check(), it will accept a list of integers, a mixed list of ints and character strings, and even just strings.

* the documentation and error messages currently try to paper over all of the curses variants of addchstr(), waddchstr(), mvwaddchstr(), ..., covering them all up under the addchstr name.  This means that your submitted documentation patch is too detailed; it should look more like the insnstr() docs, which has [y,x,] as optional, and the text says something like "Moves to y,x if specified, and then ...'.

The color_set() changes look OK; I'm going to try to break them out into a separate patch and commit them on their own.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5368>
_______________________________________

From report at bugs.python.org  Mon Feb 22 19:27:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Feb 2010 18:27:08 +0000
Subject: [issue7989] Transition time/datetime C modules to Python
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1266863228.34.0.615357248971.issue7989@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

By 'convert', I believe you mean 'create a python implementation of'.  That is, there's no reason to drop any c code, just to create parallel python versions when possible.

Also note that one of the alternate implementations (IronPython I think) has an implementation of DateTime in Python that they plan to contribute.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Mon Feb 22 19:30:59 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 22 Feb 2010 18:30:59 +0000
Subject: [issue7989] Transition time/datetime C modules to Python
In-Reply-To: <1266855728.5.0.0452326559168.issue7989@psf.upfronthosting.co.za>
Message-ID: <1266863459.95.0.904716050091.issue7989@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Correct, your wording is better than mine.

I'll ask around and see where that datetime module may be and what it's state is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7989>
_______________________________________

From report at bugs.python.org  Mon Feb 22 19:31:37 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 22 Feb 2010 18:31:37 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1266863497.59.0.538662100413.issue7980@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I just tried it again under gdb on MacOS 10.6, the supplied python 2.6.4 and got this backtrace:

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to process 61133]
0x00007fff87a4b790 in __CFInitialize ()
(gdb) bt
#0  0x00007fff87a4b790 in __CFInitialize ()
#1  0x00007fff5fc0d5ce in __dyld__ZN16ImageLoaderMachO11doImageInitERKN11ImageLoader11LinkContextE ()
#2  0x00007fff5fc0d607 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
#3  0x00007fff5fc0bcec in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#4  0x00007fff5fc0bc9d in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#5  0x00007fff5fc0bc9d in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#6  0x00007fff5fc0bda6 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
#7  0x00007fff5fc08fbb in __dyld_dlopen ()
#8  0x00007fff8276fe00 in dlopen ()
#9  0x00000001000e876f in _PyImport_GetDynLoadFunc ()
#10 0x00000001000d2ce4 in _PyImport_LoadDynamicModule ()
#11 0x00000001000d0fbf in import_submodule ()
#12 0x00000001000d14da in load_next ()
#13 0x00000001000d17ec in PyImport_ImportModuleLevel ()
#14 0x00000001000aeeb3 in builtin___import__ ()
#15 0x000000010000c092 in PyObject_Call ()
#16 0x00000001000b00e7 in PyEval_CallObjectWithKeywords ()
#17 0x00000001000b43ae in PyEval_EvalFrameEx ()
#18 0x00000001000b8fd0 in PyEval_EvalCodeEx ()
#19 0x00000001000b90b6 in PyEval_EvalCode ()
#20 0x00000001000cdeb0 in PyImport_ExecCodeModuleEx ()
#21 0x00000001000cf112 in load_source_module ()
#22 0x00000001000d0fbf in import_submodule ()
#23 0x00000001000d14da in load_next ()
#24 0x00000001000d17ec in PyImport_ImportModuleLevel ()
#25 0x00000001000aeeb3 in builtin___import__ ()
#26 0x000000010000c092 in PyObject_Call ()
#27 0x00000001000b00e7 in PyEval_CallObjectWithKeywords ()
#28 0x00000001000b43ae in PyEval_EvalFrameEx ()
#29 0x00000001000b8fd0 in PyEval_EvalCodeEx ()
#30 0x00000001000b90b6 in PyEval_EvalCode ()
#31 0x00000001000cdeb0 in PyImport_ExecCodeModuleEx ()
#32 0x00000001000cf112 in load_source_module ()
#33 0x00000001000d0fbf in import_submodule ()
#34 0x00000001000d14da in load_next ()
#35 0x00000001000d17ec in PyImport_ImportModuleLevel ()
#36 0x00000001000aeeb3 in builtin___import__ ()
#37 0x000000010000c092 in PyObject_Call ()
#38 0x000000010000fbe5 in PyObject_CallFunction ()
#39 0x00000001000d1f9b in PyImport_Import ()
#40 0x00000001000d250f in PyImport_ImportModuleNoBlock ()
#41 0x0000000100515733 in time_strptime ()
#42 0x00000001000b8278 in PyEval_EvalFrameEx ()
#43 0x00000001000b8fd0 in PyEval_EvalCodeEx ()
#44 0x000000010003b355 in function_call ()
#45 0x000000010000c092 in PyObject_Call ()
#46 0x00000001000b00e7 in PyEval_CallObjectWithKeywords ()
#47 0x00000001000ef7ae in t_bootstrap ()
#48 0x00007fff827a2f8e in _pthread_start ()
#49 0x00007fff827a2e41 in thread_start ()
(gdb)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7980>
_______________________________________

From report at bugs.python.org  Mon Feb 22 19:36:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Feb 2010 18:36:48 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1266863808.02.0.656856427519.issue7980@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Attribute error confirmed on linux on trunk and py3k.

----------
priority:  -> normal
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7980>
_______________________________________

From report at bugs.python.org  Mon Feb 22 19:39:11 2010
From: report at bugs.python.org (Joel Pearson)
Date: Mon, 22 Feb 2010 18:39:11 +0000
Subject: [issue5584] json.loads(u'3.14') fails unexpectedly (minor scanner bug)
In-Reply-To: <1238219615.73.0.707210951472.issue5584@psf.upfronthosting.co.za>
Message-ID: <1266863951.28.0.589223375133.issue5584@psf.upfronthosting.co.za>


Joel Pearson <joel at pythonica.com> added the comment:

The fix for this bug was included in r72194.

I verified that the fix is included in trunk, the release31-maint branch, and the py3k branch. I also verified that json.loads(u'3.14') works in 2.7a3, and that json.loads('3.14') works in 3.1.1, so I believe that this bug can be closed.

----------
nosy: +joel.pearson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5584>
_______________________________________

From report at bugs.python.org  Mon Feb 22 19:43:22 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 22 Feb 2010 18:43:22 +0000
Subject: [issue7627] mailbox.MH.remove() lock handling is broken
In-Reply-To: <1262564711.76.0.763774175522.issue7627@psf.upfronthosting.co.za>
Message-ID: <1266864202.97.0.5539558907.issue7627@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Thanks for your bug report!

Unfortunately, the fix isn't quite right, because on Windows you can't delete files that are open.  I think an even simpler fix is just to remove that locking; if self._locked is true, this process presumably has exclusive access to the mailbox and can just go ahead and remove the file.

I've committed this to 2.7 trunk as rev78332.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7627>
_______________________________________

From report at bugs.python.org  Mon Feb 22 20:00:10 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 22 Feb 2010 19:00:10 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1266865210.03.0.149486616519.issue7649@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

New patch (issue7649v2.diff) with refleak fixed and improved unittests.

----------
keywords: +needs review
Added file: http://bugs.python.org/file16314/issue7649v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Mon Feb 22 20:03:00 2010
From: report at bugs.python.org (Gael)
Date: Mon, 22 Feb 2010 19:03:00 +0000
Subject: [issue1669349] make install fails if no previous Python installation
Message-ID: <1266865380.58.0.200375746139.issue1669349@psf.upfronthosting.co.za>


Gael <gael.pegliasco at makina-corpus.com> added the comment:

I have the same issue on Sun Solaris while compiling Python 2.4.5 on a Python-less system.

I was using GNU tools (tar, zlib, libgcc and bash).

I have noticed that the error appears while using --prefix=/something/ending/with/Python-2.4

But if I use --prefix=/something/ending/with/SomethingElse, like
--prefix=/something/ending/with/Python-24 or
--prefix=/something/ending/with/PythonTest

Everything goes well and make install no more fails.

It looks like a fail regex or a hard coded path error.

Hope this can help.

Best regards,

Ga?l,

----------
nosy: +gael

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1669349>
_______________________________________

From report at bugs.python.org  Mon Feb 22 20:11:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Feb 2010 19:11:43 +0000
Subject: [issue4331] Can't use _functools.partial() created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1266865903.77.0.153297173978.issue4331@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I would expect the second and would view the first as a bug.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4331>
_______________________________________

From report at bugs.python.org  Mon Feb 22 20:23:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Feb 2010 19:23:28 +0000
Subject: [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: <1266866608.05.0.472145845531.issue7946@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

And here is an experimental patch which enables the "priority requests" mechanism which was in the original new GIL patch. "Experimental" because it only enables them on a couple of socket methods (enough to affect the benchmarks).

Here are the UDP benchmark results (with 2 background threads):
* 2.x trunk (old GIL):
11.379 seconds (921515.168 bytes/sec)
* vanilla py3k (new GIL):
27.400 seconds (382689.529 bytes/sec)
* patched py3k (new GIL + priority requests):
1.828 seconds (5737130.676 bytes/sec)

And here's patched py3k with 8 background threads:
3.058 seconds (3429136.193 bytes/sec)

(benchmarks run on a 8-core Linux machine)

----------
keywords: +patch
Added file: http://bugs.python.org/file16317/gilprio.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Mon Feb 22 20:28:17 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 22 Feb 2010 19:28:17 +0000
Subject: [issue7988] complex.__format__ has incorrect default alignment
In-Reply-To: <1266855543.18.0.92695356509.issue7988@psf.upfronthosting.co.za>
Message-ID: <1266866897.04.0.710981395522.issue7988@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Checked in:
trunk r78329
py3k r78333
release31-maint r78334

----------
priority:  -> low
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7988>
_______________________________________

From report at bugs.python.org  Mon Feb 22 20:30:46 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 22 Feb 2010 19:30:46 +0000
Subject: [issue6857] float().__format__() default alignment
In-Reply-To: <1252338408.26.0.926307636667.issue6857@psf.upfronthosting.co.za>
Message-ID: <1266867046.27.0.0323613586284.issue6857@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

With the fixes for complex in issue 7988, I believe this issue is completed.

----------
priority:  -> normal
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6857>
_______________________________________

From report at bugs.python.org  Mon Feb 22 20:48:54 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 22 Feb 2010 19:48:54 +0000
Subject: [issue7920] urllib2.HTTPRedirectHandler incorrect redirect
In-Reply-To: <1266011084.83.0.0326673543999.issue7920@psf.upfronthosting.co.za>
Message-ID: <1266868134.91.0.636111862931.issue7920@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I disagree with this bug report.

First the responsibility of checking if something is not  malicious URL lies at the application/client end, urllib in its redirection never urlopen()'s the redirected url, so you are not harmed in anyway.
If you wanted to be extra careful of the BAD Server, you can always subclass the redirection methods and use those handlers.

Closing this bug as won't fix.

----------
assignee:  -> orsenthil
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7920>
_______________________________________

From report at bugs.python.org  Mon Feb 22 21:05:46 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 22 Feb 2010 20:05:46 +0000
Subject: [issue7049] decimal.py: Three argument power issues
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1266869146.73.0.563853655749.issue7049@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I've tried to pinpoint exactly what I don't like about the current
behavior, and the main reason is that it violates my mental model
of how the functions in the specification generally behave:

1) Functions take arbitrary precision input.

2) Functions try to preserve as much of the exponent
   information of the input as possible.


With these in mind, it's easy to specify powmod() as:

(a ** b) % c, calculated with unlimited precision. Raises if
the final result does not fit in the current precision.


It is not totally clear to me why the result should have exponent 0
because it is an integer. Decimal("1E3").to_integral() also preserves
the exponent information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7049>
_______________________________________

From report at bugs.python.org  Mon Feb 22 21:07:19 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 22 Feb 2010 20:07:19 +0000
Subject: [issue7647] Add statvfs flags to the posix module
In-Reply-To: <1262809121.07.0.608953880629.issue7647@psf.upfronthosting.co.za>
Message-ID: <1266869239.27.0.738668701844.issue7647@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Here's a patch that updates the 2.7 docs.

Adam, have you submitted a contributor agreement (http://www.python.org/psf/contrib/)?

----------
nosy: +akuchling
Added file: http://bugs.python.org/file16318/posix-statvfs-flag-docs.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7647>
_______________________________________

From report at bugs.python.org  Mon Feb 22 21:22:46 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 22 Feb 2010 20:22:46 +0000
Subject: [issue1708316] doctest work with Windows PyReadline
Message-ID: <1266870166.24.0.251803425197.issue1708316@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Does the attached, slightly simpler patch, also fix it?
The patch just sets the .encoding attribute after 
creating it with _SpoofOut().  

The revised patch doesn't seem to break anything on MacOS; I don't have access to Windows to test whether it still fixes the bug.

----------
nosy: +akuchling
Added file: http://bugs.python.org/file16319/doctest-patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708316>
_______________________________________

From report at bugs.python.org  Mon Feb 22 21:22:59 2010
From: report at bugs.python.org (Jack Diederich)
Date: Mon, 22 Feb 2010 20:22:59 +0000
Subject: [issue7646] test_telnetlib fails in Windows XP
In-Reply-To: <1262807945.09.0.76029719332.issue7646@psf.upfronthosting.co.za>
Message-ID: <1266870179.94.0.308876833887.issue7646@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

I was mistaken, the tests were backported to 3.1.x maint (In fact I was the one who did it).  So this is fixed in the next point release of 3.1.x.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7646>
_______________________________________

From report at bugs.python.org  Mon Feb 22 21:25:29 2010
From: report at bugs.python.org (Austin English)
Date: Mon, 22 Feb 2010 20:25:29 +0000
Subject: [issue7646] test_telnetlib fails in Windows XP
In-Reply-To: <1262807945.09.0.76029719332.issue7646@psf.upfronthosting.co.za>
Message-ID: <1266870329.82.0.957544377744.issue7646@psf.upfronthosting.co.za>


Austin English <austinenglish+python at gmail.com> added the comment:

Okay, thanks for the information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7646>
_______________________________________

From report at bugs.python.org  Mon Feb 22 21:30:10 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 22 Feb 2010 20:30:10 +0000
Subject: [issue7049] decimal.py: Three argument power issues
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1266870610.74.0.926570148354.issue7049@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Well, the real problem is that powmod doesn't really belong in the decimal module at all.  It's not a natural primitive arithmetic operation; it's certainly not naturally a floating-point operation; nothing like this appears in any floating-point standard that I'm aware of; and its (few) use cases are very different from typical decimal use cases.  I'd like to bet that it currently has precisely 0 users.  Trying to shoehorn powmod into the decimal module and make its semantics fit with the rest of the module seems a little pointless to me.

Really, what's the point of making any sort of attempt to preserve exponents in 3-argument pow?  Having the result exponent be 0 is clean, simple to understand, simple to implement (which your proposal is not), and matches the use-cases.  The restriction on the modulus also matches the use-cases:  typically, the modulus m is fixed, and you won't have any expectations about the output of powmod(a, b, m) except that you'll know the result is an integer in the range 0 <= x < m.  Having powmod reject m's for which only part of this range is representable avoids hard-to-find bugs where powmod(a, b, m) works for most values of a but then unexpectedly fails for some particular value of a because the result is just larger than can be represented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7049>
_______________________________________

From report at bugs.python.org  Mon Feb 22 21:32:54 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 22 Feb 2010 20:32:54 +0000
Subject: [issue1514] missing constants in socket module
In-Reply-To: <1196284052.76.0.985131774299.issue1514@psf.upfronthosting.co.za>
Message-ID: <1266870774.81.0.0341776201609.issue1514@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

The original problem has been fixed since 2007.  Improving the #if condition doesn't seem very important to anyone, so I'll just close this bug.

----------
nosy: +akuchling
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1514>
_______________________________________

From report at bugs.python.org  Mon Feb 22 21:49:51 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 22 Feb 2010 20:49:51 +0000
Subject: [issue6871] decimal.py: more format issues
In-Reply-To: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za>
Message-ID: <1266871791.59.0.791955193389.issue6871@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I think there are no remaining issues here that don't have their own issue. I'm going to close this unless one of you think otherwise.

----------
assignee:  -> eric.smith
resolution:  -> out of date
status: open -> pending
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6871>
_______________________________________

From report at bugs.python.org  Mon Feb 22 21:55:40 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 22 Feb 2010 20:55:40 +0000
Subject: [issue5584] json.loads(u'3.14') fails unexpectedly (minor scanner bug)
In-Reply-To: <1238219615.73.0.707210951472.issue5584@psf.upfronthosting.co.za>
Message-ID: <1266872140.7.0.975712674441.issue5584@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I tried json.loads(u'3.14') on trunk and release26-maint and it worked fine, on py3k and release31-maint json.loads('3.14') works too, so I'm closing this issue.

----------
nosy: +ezio.melotti
resolution: accepted -> out of date
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5584>
_______________________________________

From report at bugs.python.org  Mon Feb 22 22:07:46 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 22 Feb 2010 21:07:46 +0000
Subject: [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: <1266872866.2.0.778355345928.issue7975@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7975>
_______________________________________

From report at bugs.python.org  Mon Feb 22 22:14:32 2010
From: report at bugs.python.org (Jack Diederich)
Date: Mon, 22 Feb 2010 21:14:32 +0000
Subject: [issue7463] PyDateTime_IMPORT() causes compiler warnings
In-Reply-To: <1260352911.97.0.550126067946.issue7463@psf.upfronthosting.co.za>
Message-ID: <1266873272.66.0.901549661598.issue7463@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

changing the definition to (const char *) seems like the right thing to do - a quick grep of the Python source and a search on google codesearch only shows uses with either string literals or string literals cast to (char *) in order to silence a warning.  I tried changing it on the 2.x trunk and it compiles with no warnings.

+1, any other opinions?

----------
nosy: +jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7463>
_______________________________________

From report at bugs.python.org  Mon Feb 22 22:32:24 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 22 Feb 2010 21:32:24 +0000
Subject: [issue6871] decimal.py: more format issues
In-Reply-To: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za>
Message-ID: <1266874344.28.0.91005910732.issue6871@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I couldn't find other issues where #1 and #2 are addressed. This
is from py3k:


#1:

>>> format(float('nan'), '+08.4')
'+0000nan'
[70141 refs]
>>> format(Decimal('nan'), '+08.4')
'    +NaN'


#2:>>> format(float(123), "00")
'123.0'
[70141 refs]
>>> format(Decimal(123), "00")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/stefan/svn/py3k/Lib/decimal.py", line 3633, in __format__
    spec = _parse_format_specifier(specifier, _localeconv=_localeconv)
  File "/home/stefan/svn/py3k/Lib/decimal.py", line 5915, in _parse_format_specifier
    raise ValueError("Invalid format specifier: " + format_spec)
ValueError: Invalid format specifier: 00
[70141 refs]

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6871>
_______________________________________

From report at bugs.python.org  Mon Feb 22 22:41:38 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 22 Feb 2010 21:41:38 +0000
Subject: [issue6871] decimal.py: more format issues
In-Reply-To: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za>
Message-ID: <1266874898.95.0.527917324163.issue6871@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

[The tracker apparently set the status to 'open' without my intervention.]

To sum up what I said earlier about #1 and #2, I think that the C standard
and gcc's warning behavior support the way of Decimal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6871>
_______________________________________

From report at bugs.python.org  Mon Feb 22 22:43:48 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 22 Feb 2010 21:43:48 +0000
Subject: [issue1097797] Encoding for Code Page 273 used by EBCDIC Germany
	Austria
Message-ID: <1266875028.26.0.0093755927568.issue1097797@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

I tried figuring out to rebuild the codecs using the scripts in Tools/unicode/ but failed.  Is the use of that directory documented anywhere?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1097797>
_______________________________________

From report at bugs.python.org  Mon Feb 22 22:47:18 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 22 Feb 2010 21:47:18 +0000
Subject: [issue6871] decimal.py: more format issues
In-Reply-To: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za>
Message-ID: <1266875238.62.0.546244713263.issue6871@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

[If the status is pending, any comment turns it back to open, by design.]

I'd rather float.__format__ agree with %-formatting for floats than with anything else.

>>> '%+08.4f' % float('nan')
'+0000nan'
>>> "%00f" % float('123')
'123.000000'

(Not sure about the precision being displayed on that last one, I'll have to think about it.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6871>
_______________________________________

From report at bugs.python.org  Mon Feb 22 22:52:21 2010
From: report at bugs.python.org (David Beazley)
Date: Mon, 22 Feb 2010 21:52:21 +0000
Subject: [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: <1266875541.44.0.274313337326.issue7946@psf.upfronthosting.co.za>


David Beazley <dave at dabeaz.com> added the comment:

I posted some details about the priority GIL modifications I showed during my PyCON open-space session here:

http://www.dabeaz.com/blog/2010/02/revisiting-thread-priorities-and-new.html

I am attaching the .tar.gz file with modifications if anyone wants to look at them.  Note: I would not consider this to be solid enough to be any kind of official patch.   People should only look at it for the purposes of experimentation and for coming up with something better.

----------
Added file: http://bugs.python.org/file16324/prioritygil.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

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: [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:02:35 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Feb 2010 22:02:35 +0000
Subject: [issue1097797] Encoding for Code Page 273 used by EBCDIC Germany
	Austria
In-Reply-To: <1266875028.26.0.0093755927568.issue1097797@psf.upfronthosting.co.za>
Message-ID: <4B82FEF8.2050105@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

A.M. Kuchling wrote:
> 
> A.M. Kuchling <lists at amk.ca> added the comment:
> 
> I tried figuring out to rebuild the codecs using the scripts in Tools/unicode/ but failed.  Is the use of that directory documented anywhere?

See the Makefile in that directory - that's what I use to build the
codecs.

If you just want to create a single codec, have a look at the
gencodec.py module doc-string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1097797>
_______________________________________

From report at bugs.python.org  Mon Feb 22 23:05:49 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 22 Feb 2010 22:05:49 +0000
Subject: [issue6902] Built-in types format incorrectly with 0 padding.
In-Reply-To: <1252885004.98.0.012153138281.issue6902@psf.upfronthosting.co.za>
Message-ID: <1266876349.09.0.0932679258462.issue6902@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The root of this problem is an interaction with ',' formatting that was introduced in 2.7 and 3.1. I'm still trying to figure out how to implement it.

I'm changing the priority to low because I can't imagine this is a problem in practice. If anyone thinks otherwise, please comment and give a use case.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6902>
_______________________________________

From report at bugs.python.org  Mon Feb 22 23:09:44 2010
From: report at bugs.python.org (Justin Cappos)
Date: Mon, 22 Feb 2010 22:09:44 +0000
Subject: [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  Mon Feb 22 23:15:15 2010
From: report at bugs.python.org (Justin Cappos)
Date: Mon, 22 Feb 2010 22:15:15 +0000
Subject: [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: <1266876915.0.0.138671919143.issue7850@psf.upfronthosting.co.za>


Justin Cappos <justincappos at gmail.com> added the comment:

Perhaps the right way to fix the problem without breaking code would be to propose a new function for platform which would return a 'newbie readable' string of the system type?

----------
nosy: +Justin.Cappos

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7850>
_______________________________________

From jeremy at alum.mit.edu  Mon Feb 22 23:18:03 2010
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Mon, 22 Feb 2010 17:18:03 -0500
Subject: [issue4617] SyntaxError when free variable name is also an 
	exception target
In-Reply-To: <1265940553.34.0.0766783336387.issue4617@psf.upfronthosting.co.za>
References: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za>
	<1265940553.34.0.0766783336387.issue4617@psf.upfronthosting.co.za>
Message-ID: <e8bf7a531002221418qf706501t3e100b69f53782f8@mail.gmail.com>

It's an interesting bug.  Maybe the compiler shouldn't allow you to
use such a variable as a free variable in a nested function?

On Thu, Feb 11, 2010 at 9:09 PM, Craig McQueen <report at bugs.python.org> wrote:
>
> Craig McQueen <python at craig.mcqueen.id.au> added the comment:
>
> There's also this one which caught me out:
>
> def outer():
> ?x = 0
> ?y = (x for i in range(10))
> ?del x ?# SyntaxError
>
> ----------
> nosy: +cmcqueen1975
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4617>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

From report at bugs.python.org  Mon Feb 22 23:18:07 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Mon, 22 Feb 2010 22:18:07 +0000
Subject: [issue4617] SyntaxError when free variable name is also an exception
	target
In-Reply-To: <1265940553.34.0.0766783336387.issue4617@psf.upfronthosting.co.za>
Message-ID: <e8bf7a531002221418qf706501t3e100b69f53782f8@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

It's an interesting bug.  Maybe the compiler shouldn't allow you to
use such a variable as a free variable in a nested function?

On Thu, Feb 11, 2010 at 9:09 PM, Craig McQueen <report at bugs.python.org> wrote:
>
> Craig McQueen <python at craig.mcqueen.id.au> added the comment:
>
> There's also this one which caught me out:
>
> def outer():
> ?x = 0
> ?y = (x for i in range(10))
> ?del x ?# SyntaxError
>
> ----------
> nosy: +cmcqueen1975
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4617>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4617>
_______________________________________

From report at bugs.python.org  Mon Feb 22 23:20:57 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 22 Feb 2010 22:20:57 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1266877257.75.0.736836990506.issue7649@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Could you add a comment on why you're calling PyUnicode_FromString and then throwing away the result? I believe it's so you'll get the same error checking as PyUnicode_FromString, but it's sufficiently tricky that I think it deserves a comment.

Now that I think about it, having done the conversion in PyUnicode_FromString, why not use:
buf[0] = PyUnicode_AS_UNICODE(s)[0];
? This way you skip the cast and you know for a fact you're using the same interpretation as PyUnicode_FromString, having used its output.

Also, since you know the size you may as well call PyUnicode_FromStringAndSize. It's trivially faster and makes the intent clearer, I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Mon Feb 22 23:23:38 2010
From: report at bugs.python.org (Jack Diederich)
Date: Mon, 22 Feb 2010 22:23:38 +0000
Subject: [issue7366] weakref module example relies on behaviour not guaranteed
	by id()
In-Reply-To: <1258697255.57.0.532906770015.issue7366@psf.upfronthosting.co.za>
Message-ID: <1266877418.99.0.829296813282.issue7366@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

This is true but /any/ key in the WeakValueDictionary could be reused and result in similar behavior, not just the id() of the inserted value.  I'm closing at "won't fix"

----------
nosy: +jackdied
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7366>
_______________________________________

From report at bugs.python.org  Mon Feb 22 23:35:05 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Feb 2010 22:35:05 +0000
Subject: [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: <1266878105.13.0.219860621185.issue7850@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

platform.system() is a direct interface to platform.uname() which in return is an interface to the platform's uname() API, so the reasoning is much the same as for sys.platform on those platforms that do expose a uname() function (and command).

On Mac OS X, uname returns "Darwin".

What we can do, is add a new function parameter ''aliased'' (just like we have for platform.platform()) which then enables applying some aliasing to the returned uname() values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7850>
_______________________________________

From report at bugs.python.org  Mon Feb 22 23:43:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Feb 2010 22:43:25 +0000
Subject: [issue216285] Unicode encoders don't report errors properly
Message-ID: <1266878605.39.0.940579222503.issue216285@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution: remind -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue216285>
_______________________________________

From report at bugs.python.org  Mon Feb 22 23:50:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Feb 2010 22:50:31 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266879031.04.0.329078170686.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

After some head-scratching, I figured out how to reproduce stock python2.5 behavior.  It turns out that defining _DARWIN_C_SOURCE not only allows getgroups() output to exceed NGROUPS_MAX (as documented), but also effectively disables setgroups() which is not documented.

With no-darwin-ext.diff patch and previously attached tg.py, I see

$ cat tg.py
import os
g = os.getgroups()
print(g)
os.setgroups(g[:5])
print(os.getgroups())

$ sudo ./python.exe tg.py
[0, 101, 204, 100, 98, 80, 61, 29, 20, 12, 9, 8, 5, 4, 3, 2]
[0, 101, 204, 100, 98]

which is the same as with stock python2.5:

$ sudo python2.5 tg.py
[0, 101, 204, 100, 98, 80, 61, 29, 20, 12, 9, 8, 5, 4, 3, 2]
[0, 101, 204, 100, 98]

Note that root is a member of 18 groups on my system, but the last two are truncated by os.getgroups().

It is tempting to adopt no-darwin-ext.diff as a solution to this issue because allowing more than NGROUPS_MAX (or sysconf(_SC_NGROUPS_MAX) which should be the same) groups is really a Mac OS bug.

In order to have both working os.setgroups() and os.getgroups() supporting more than NGROUPS_MAX results, it appears that the two functions should be compiled in separate compilation units which is probably too big of a price to pay for the functionality.

Also, my issue7900.diff, while likely to work in most practical situation is vulnerable to a race condition if group membership is expanded between two calls to getgroups.

----------
Added file: http://bugs.python.org/file16326/no-darwin-ext.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Mon Feb 22 23:51:34 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Mon, 22 Feb 2010 22:51:34 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1266879094.92.0.228936529111.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Is the issue2636-20100222.zip archive supposed to be complete? I can't find not only the rst or html "features", but more importantly the py and pyd files for the particular versions.

Anyway, I just skimmed through the regular-expressions.info documentation and found, that most features, which I missed in the builtin re version seems to be present in the regex module;
a few possibly notable exceptions being some unicode features:
http://www.regular-expressions.info/unicode.html 
support for unicode script properties might be needlessly complex (maybe unless http://bugs.python.org/issue6331 is implemented)

On the other hand \X for matching any single grapheme might be useful, according to the mentioned page, the currently working equivalent would be 
\P{M}\p{M}*
However, I am not sure about the compatibility concerns; it is possible, that the modifier characters as a part of graphemes might cause some discrepancies in the text indices etc. 

A feature, where i personally (currently) can't find a usecase is \G and continuing matches (but no doubt, there would be some some cases for this).

regards
   vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Mon Feb 22 23:56:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Feb 2010 22:56:44 +0000
Subject: [issue1180002] locale.format question
Message-ID: <1266879404.24.0.452990201466.issue1180002@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The last comment set this issue to 'remind' in case someone wanted to fix it in the future...it's pretty much fixed now.  format_string was added in 2.5, and in 2.6 format only accepts a string containing just a format code.

----------
nosy: +r.david.murray
resolution: remind -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180002>
_______________________________________

From report at bugs.python.org  Tue Feb 23 00:08:35 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Feb 2010 23:08:35 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266880115.38.0.865820925612.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I am reclassifying this as a crash because os.getgroups() crashes the interpreter when python is running as root on an unmodified system:

$ sudo ./python.exe  -c "import os; os.getgroups()"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 22] Invalid argument

This is also a regression apparently introduced in r63955.

----------
type: behavior -> crash
versions: +Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Feb 23 00:10:54 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 22 Feb 2010 23:10:54 +0000
Subject: [issue4617] SyntaxError when free variable name is also an exception
	target
In-Reply-To: <1228911523.24.0.570670634565.issue4617@psf.upfronthosting.co.za>
Message-ID: <1266880254.52.0.863061255282.issue4617@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

All examples so far (*) have to do with our inability to have properly nested blocks. If we did, I'd make the except clause a block, and I'd issue a syntax warning or error if a nested block shadowed a variable referenced outside it. Ditto for generator expressions and comprehensions.

As long as we don't have nested blocks, I think it's okay to see the limitation on (implicit or explicit) "del" of a cell variable as a compiler deficiency and fix that deficiency.

__________
(*) However there's also this example:

>>> def f():
...  try: 1/0
...  except Exception as a:
...   def g(): return a
...   return g
... 
SyntaxError: can not delete variable 'a' referenced in nested scope
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4617>
_______________________________________

From report at bugs.python.org  Tue Feb 23 00:23:03 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 22 Feb 2010 23:23:03 +0000
Subject: [issue7796] No way to find out if an object is an instance of a
	namedtuple
In-Reply-To: <1264608669.85.0.379125118171.issue7796@psf.upfronthosting.co.za>
Message-ID: <1266880983.18.0.104472237757.issue7796@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Discussed this with GvR.
Here's a recap:

For 2.6 and 3.1 which are already released, check for the _fields attribute.  This is a guaranteed part of the API is not fragile.  For the C structures, check for the n_fields attribute.

In the future, the C API needs to grow to match the namedtuple() API and we should add an abstract base class describing the common API.  Then you'll be able to write: 
    if isinstance(obj, abc_namedtuple).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7796>
_______________________________________

From report at bugs.python.org  Tue Feb 23 00:28:31 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 22 Feb 2010 23:28:31 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1266881311.86.0.170939206918.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I don't know what happened there. I didn't notice that the zip file was way too small. Here's a replacement (still called issue2636-20100222.zip).

Unicode script properties are already included, at least those whose definitions at http://www.regular-expressions.info/unicode.html

I haven't notice \X before. I'll have a look at it.

As for \G, .findall performs searches normally, but when using \G it effectively performs contiguous matches only, which can be useful when you need it!

----------
Added file: http://bugs.python.org/file16327/issue2636-20100222.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Feb 23 00:30:59 2010
From: report at bugs.python.org (Jack Diederich)
Date: Mon, 22 Feb 2010 23:30:59 +0000
Subject: [issue7196] Clarify str.split() behavior
In-Reply-To: <1256358824.27.0.552818467808.issue7196@psf.upfronthosting.co.za>
Message-ID: <1266881459.94.0.426192173903.issue7196@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

I suggest this be closed WONTFIX.  The str.split() documentation accurately describes str.split() but doesn't happen to do what the OP wanted which was

list(filter(None, '00010001'.split('0')))

Instead split(sep) is the reciprocal of sep.join(), that is
txt == sep.join(txt.split(sep))

----------
nosy: +jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7196>
_______________________________________

From report at bugs.python.org  Tue Feb 23 00:35:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Feb 2010 23:35:39 +0000
Subject: [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: <1266881739.51.0.986867509762.issue7946@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is another patch based on a slightly different approach. Instead of being explicitly triggered in I/O methods, priority requests are decided based on the computed "interactiveness" of a thread. Interactiveness itself is a simple saturated counter (incremented when the GIL is dropped without request, decremented when the GIL is dropped after a request).

Benchmark numbers are basically the same as with gilprio2.patch.

----------
Added file: http://bugs.python.org/file16328/gilinter.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7946>
_______________________________________

From report at bugs.python.org  Tue Feb 23 00:39:40 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 22 Feb 2010 23:39:40 +0000
Subject: [issue1517495] memory leak threading or socketserver module
Message-ID: <1266881980.93.0.399583837316.issue1517495@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

I can no longer confirm this bug, either; trying the scripts with the current trunk doesn't seem to leak.  Backing out Jeffrey's r61011 didn't bring the problem back, so I'll just conclude that the problem has gotten fixed along the way somehow.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1517495>
_______________________________________

From report at bugs.python.org  Tue Feb 23 00:47:34 2010
From: report at bugs.python.org (Jack Diederich)
Date: Mon, 22 Feb 2010 23:47:34 +0000
Subject: [issue6886] cgi.py runs python, not python3
In-Reply-To: <1252695717.33.0.0393751627357.issue6886@psf.upfronthosting.co.za>
Message-ID: <1266882454.28.0.901408506256.issue6886@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

+0 I'm ambivalent.  The script uses a reasonable default and pyhton3 is a reasonable default for the 3k branch.  That said most people will have to edit the file anyway to use it: I had to chmod a+x the file and change the bang path to /usr/bin/python to get it to work on my machine.

----------
nosy: +jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6886>
_______________________________________

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: [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:51:10 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Mon, 22 Feb 2010 23:51:10 +0000
Subject: [issue4617] SyntaxError when free variable name is also an exception
	target
In-Reply-To: <1266880254.52.0.863061255282.issue4617@psf.upfronthosting.co.za>
Message-ID: <e8bf7a531002221551q1d65db03o84a6a9b63f908797@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

On Mon, Feb 22, 2010 at 6:10 PM, Guido van Rossum
<report at bugs.python.org> wrote:
>
> Guido van Rossum <guido at python.org> added the comment:
>
> All examples so far (*) have to do with our inability to have properly nested blocks. If we did, I'd make the except clause a block, and I'd issue a syntax warning or error if a nested block shadowed a variable referenced outside it. Ditto for generator expressions and comprehensions.

There's no reason we couldn't revise the language spec to explain that
except clauses and comprehensions are block statements, i.e.
statements that introduce a new block.  For the except case, there
would be some weird effects.

y = 10
try:
  ...
except SomeError as err:
  y = 12
print y  # prints 10

In the example above, y would be a local variable in the scope of the
except handler that shadows the local variable in the block that
contains the try/except.  It might be confusing that you couldn't
assign to a local variable in the except handler without using a
nonlocal statement.

> As long as we don't have nested blocks, I think it's okay to see the limitation on (implicit or explicit) "del" of a cell variable as a compiler deficiency and fix that deficiency.

The general request here is to remove all the SyntaxErrors about
deleting cell variables, right?  Instead, you'd get a NameError at
runtime saying that the variable is currently undefined.  You'd want
that change regardless of whether we change the language as described
above.

hoping-for-some-bdfl-pronouncements-ly y'rs,
Jeremy

> __________
> (*) However there's also this example:
>
>>>> def f():
> ... ?try: 1/0
> ... ?except Exception as a:
> ... ? def g(): return a
> ... ? return g
> ...
> SyntaxError: can not delete variable 'a' referenced in nested scope
>>>>
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4617>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4617>
_______________________________________

From report at bugs.python.org  Tue Feb 23 00:51:53 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 22 Feb 2010 23:51:53 +0000
Subject: [issue7196] Clarify str.split() behavior
In-Reply-To: <1256358824.27.0.552818467808.issue7196@psf.upfronthosting.co.za>
Message-ID: <1266882713.39.0.55219467166.issue7196@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Agreed.  Thanks Jack.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7196>
_______________________________________

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: [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 01:18:36 2010
From: report at bugs.python.org (Jack Diederich)
Date: Tue, 23 Feb 2010 00:18:36 +0000
Subject: [issue6931] dreadful performance in difflib: ndiff and HtmlDiff
In-Reply-To: <1253199298.69.0.280559653373.issue6931@psf.upfronthosting.co.za>
Message-ID: <1266884316.04.0.00621224791834.issue6931@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

Here is a profile run of the 200 line case, run on the 3.x trunk, and  with all the trivial functions removed.  quick_ratio and __contains__ dominate the time.  The process was CPU bound, memory usage stayed low.


17083154 function calls (17066360 primitive calls) in 248.779 CPU seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
 10660375   70.516    0.000   70.516    0.000 :0(__contains__)
   114482    1.048    0.000    1.048    0.000 :0(append)
  4434776   29.254    0.000   29.254    0.000 :0(get)
685047/685042    4.400    0.000    4.400    0.000 :0(len)
   197349    1.512    0.000    1.512    0.000 :0(min)
   197133    1.452    0.000    1.452    0.000 difflib.py:228(set_seq1)
     2500    1.632    0.001    3.092    0.001 difflib.py:299(__chain_b)
     1082    2.520    0.002    4.768    0.004 difflib.py:350(find_longest_match)
   339143    2.580    0.000    2.580    0.000 difflib.py:40(_calculate_ratio)
   141727  120.599    0.001  220.970    0.002 difflib.py:661(quick_ratio)
   196736    6.956    0.000   12.549    0.000 difflib.py:690(real_quick_ratio)
 8974/794    5.052    0.001  248.431    0.313 difflib.py:945(_fancy_replace)

----------
nosy: +jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6931>
_______________________________________

From report at bugs.python.org  Tue Feb 23 01:24:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 23 Feb 2010 00:24:38 +0000
Subject: [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: <1266884678.01.0.975767755512.issue7997@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This looks good!  Is it worth mentioning that autoreconf updates pyconfig.h.in as well as configure?

There's also an OS X oddity to be aware of, though I'm not sure whether it's worth mentioning in the FAQ.  On OS X 10.6, the system autoconf (/usr/bin/autoconf) *appears* at first sight to be autoconf 2.61 (e.g., using autoconf --version), but has actually been modified slightly by Apple:  it produces a whole bunch of

-rm -f conftest*
+rm -f -r conftest*

differences in the generated configure file.  I don't know how much this really matters---it can make checkins look a bit confusing at times but seems otherwise harmless.  But I've been sticking to GNU autoconf 2.61 and avoiding the Apple version for this reason.

Nitpick: Various occurrences of 2.6.1 in the above should probably be 2.61.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7997>
_______________________________________

From report at bugs.python.org  Tue Feb 23 01:30:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Feb 2010 00:30:55 +0000
Subject: [issue6292] Fix tests to work with -OO
In-Reply-To: <1245173156.41.0.295143421803.issue6292@psf.upfronthosting.co.za>
Message-ID: <1266885055.26.0.109748587704.issue6292@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Applied a slightly cleaned up (with help from Brian and Matias Torchinsky at the sprint) version of Brian's patch in r78351.  Leaving open until merged to py3k.

----------
assignee:  -> r.david.murray
nosy: +r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6292>
_______________________________________

From report at bugs.python.org  Tue Feb 23 01:31:02 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 23 Feb 2010 00:31:02 +0000
Subject: [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: <1266885062.61.0.65541234211.issue7997@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Isn't it true that after regenerating configure that you need to check it back in? Or is that so obvious to everyone except me that it's not worth mentioning?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7997>
_______________________________________

From report at bugs.python.org  Tue Feb 23 01:34:16 2010
From: report at bugs.python.org (manuelg)
Date: Tue, 23 Feb 2010 00:34:16 +0000
Subject: [issue1708316] doctest work with Windows PyReadline
Message-ID: <1266885256.58.0.367325917759.issue1708316@psf.upfronthosting.co.za>


manuelg <manuelg_ at users.sourceforge.net> added the comment:

The supported version and the trunk of pyreadline launchpad.net/pyreadline no long relies on sys.stdout for the encoding for the Windows console.

Getting .encoding from sys.__stdout__ seems reasonable.  If taken from sys.stdout at very last moment, only referencing sys.__stdout__ if sys.stdout is missing .encoding might be optimal, but since the bug was in pyreadline, and it is no longer trying to get .encoding from sys.stdout (which it shouldn't do anyway, because no guarantee is made that sys.stdout even has an attr .encoding), the whole point may be moot.

I rely on your judgement.  Since I only use the supported version of pyreadline, the error no longer happens in the unpatched code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708316>
_______________________________________

From report at bugs.python.org  Tue Feb 23 01:39:05 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 23 Feb 2010 00:39:05 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1266885545.8.0.945435119228.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

OK, you've convinced me, \X is supported. :-)

issue2636-20100223.zip is a new version of the regex module.

----------
Added file: http://bugs.python.org/file16331/issue2636-20100223.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Feb 23 01:47:50 2010
From: report at bugs.python.org (Alex Willmer)
Date: Tue, 23 Feb 2010 00:47:50 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1266873873.1.0.51415796949.issue2636@psf.upfronthosting.co.za>
Message-ID: <00764C7A-7D5E-45C5-95AF-05980A7EF83C@moreati.org.uk>


Alex Willmer <alex at moreati.org.uk> added the comment:

On 22 Feb 2010, at 21:24, Matthew Barnett <report at bugs.python.org>  
wrote:

> issue2636-20100222.zip is a new version of the regex module.
>
> This new version adds reverse searching.
>
> The 'features' now come in ReStructuredText (.rst) and HTML

Thank you matthew. My laptop is out of action, so it will be a few  
days before I can upload a new version to PyPI.

If you would prefer to have control of the pypi package, or to share  
control please let mr know.

Alex

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Feb 23 02:31:06 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Tue, 23 Feb 2010 01:31:06 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1266888666.64.0.321386078475.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Wow, that's what can be called rapid development :-), thanks very much!
I did'n noticed before, that \G had been implemented already.
\X works fine for me, it also maintains the input string indices correctly.

We can use unicode character properties \p{Letter} and unicode bloks \p{inBasicLatin} properties; 
the script properties like \p{Latin} or \p{IsLatin} return "undefined property name".
I guess, this would require the access to the respective information in unicodedata, where it isn't available now (there also seem to be much more scripts than those mentioned at regular-expressions.info
cf.
http://www.unicode.org/Public/UNIDATA/Scripts.txt
http://www.unicode.org/Public/UNIDATA/PropertyValueAliases.txt (under "# Script (sc)").

vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Feb 23 03:10:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Feb 2010 02:10:19 +0000
Subject: [issue7976] warnings could provide a pre-filled -W option for
	third-party tools
In-Reply-To: <1266771333.82.0.427614024661.issue7976@psf.upfronthosting.co.za>
Message-ID: <1266891019.12.0.727799405702.issue7976@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

Here?s another idea.

I seem to remember Python warnings can be turned into logging events. If these big apps and frameworks (that already use logging) turned warnings into logging calls, standard logging configuration mecanisms could be used to achieve your goal.

Does that makes sense to anyone else?

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7976>
_______________________________________

From report at bugs.python.org  Tue Feb 23 03:46:02 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 23 Feb 2010 02:46:02 +0000
Subject: [issue2134] function generate_tokens at tokenize.py yields wrong
	token for colon
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1266893162.05.0.0182278704766.issue2134@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Unfortunately I think this will break many users of tokenize.py.

e.g. http://browsershots.googlecode.com/svn/trunk/devtools/pep8/pep8.py 
has code like:
if (token_type == tokenize.OP and text in '([' and ...):

If tokenize now returns LPAR, this code will no longer work correctly.
Tools/i18n/pygettext.py, pylint, WebWare, pyfuscate, all have similar code.  So I think we can't change the API this radically.  Adding a parameter to enable more precise handling of tokens, and defaulting it to off, is probably the only way to change this.

----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
_______________________________________

From report at bugs.python.org  Tue Feb 23 04:43:38 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 23 Feb 2010 03:43:38 +0000
Subject: [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: <1266896618.25.0.997126176105.issue7997@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Eric Smith:
> Isn't it true that after regenerating configure that you need to check 
> it back in? Or is that so obvious to everyone except me that it's not 
> worth mentioning?
FWIW the above point wasn't obvious to me; if that's the case, then it needs to be spelled out.

My perspective here is as a developer without commit rights to svn; I'm developing patches to be attached to the issue tracker, and occasionally they require changing configure.in

BTW, should the changes to the generated "configure" be excluded from such patches, or should they be included? (to what extent do they contain meaningful information during review?)

Mark Dickinson:
> Eric:  interesting point.  Without having thought about it, I was 
> assuming this was about regenerating configure and pyconfig.h.in in 
> your own working copy (e.g., because you want to test locally some 
> configure script changes) rather than regenerating the configure 
> script in the central repository.

That's roughly what I was doing, yes; sorry for any confusion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7997>
_______________________________________

From report at bugs.python.org  Tue Feb 23 04:48:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Feb 2010 03:48:53 +0000
Subject: [issue7976] warnings could provide a pre-filled -W option for
	third-party tools
In-Reply-To: <1266771333.82.0.427614024661.issue7976@psf.upfronthosting.co.za>
Message-ID: <1266896933.51.0.066366717112.issue7976@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I believe the ability to log warning messages was added recently, but that it does not give you an control over what warnings are *generated*, just what happens to them (that is, allowing you to log them).

On the other hand, what is the motivation for wanting this control?  In 2.7/3.2, warnings will be silent by default.  Is it that you want the command/framework author to be able to allow users to turn warnings on?  This seems like an infrequent enough use case that it is probably better as a recipe rather than in the core (perhaps an example in the docs for warnings, but I'm not sure about that even).

In addition,

----------
nosy: +brett.cannon, r.david.murray
priority:  -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7976>
_______________________________________

From report at bugs.python.org  Tue Feb 23 05:20:48 2010
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 23 Feb 2010 04:20:48 +0000
Subject: [issue5939] Ensure that PyCapsule_GetPointer calls in ctypes handle
	errors appropriately
In-Reply-To: <1241509248.29.0.789883637669.issue5939@psf.upfronthosting.co.za>
Message-ID: <1266898848.07.0.895567929823.issue5939@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I finally reviewed this, and I think it does need additional armor against attack.  I think a user could insert a different object into the thread local dict with the hard-coded name and get CPython to crash.

This patch fixes the vulnerability:
http://codereview.appspot.com/217092/show

If this goes in, I'll add it to the backport for 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5939>
_______________________________________

From report at bugs.python.org  Tue Feb 23 07:02:47 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 23 Feb 2010 06:02:47 +0000
Subject: [issue5801] spurious empty lines in wsgiref code
In-Reply-To: <1240243437.89.0.00300959182441.issue5801@psf.upfronthosting.co.za>
Message-ID: <1266904967.59.0.639788574604.issue5801@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

empty lines were removed in r78367, r78369

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5801>
_______________________________________

From report at bugs.python.org  Tue Feb 23 07:18:17 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 23 Feb 2010 06:18:17 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1266905897.5.0.173493044642.issue7649@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Indeed some comments would be helpful, I'll add them.
I also tried already to reuse 's' and extract the first char using unicode_getitem, but it returns a PyObject and anyway it's probably more expensive/complicated than calling PyString_AS_STRING again. I'll try with [0] and/or with PyUnicode_FromStringAndSize and make a new patch this afternoon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Tue Feb 23 08:20:55 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 23 Feb 2010 07:20:55 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266909655.38.0.892015151078.issue7900@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Alexander:  What makes you think r63955 introduced the problem? 
 
Btw. This does not crash the interpreter: the example you give causes an exception and cleanly shuts down the interpreter. The exception is unwanted, but I wouldn't call it a crash.

The Apple fix for getgroups in python2.6 is odd, it uses an undocumented API (getgrouplist_2).

If I read the manpage correctly there is a posixly correct way to implement os.getgroups:

* call getgroups(MAX_GROUPS,...)
* if that fails: call getgroups(0,...), the result is groupcount
* allocate an array of groupcount gid_t's and call getgroups(groupcount)

I'll work on a patch that implements this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

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: [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 09:29:14 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 23 Feb 2010 08:29:14 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266913754.6.0.164189864496.issue7900@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On my system with the attached patch (os-getgroups.patch):

$ sudo ./python.exe
Python 2.7a3+ (trunk:78371M, Feb 23 2010, 09:19:44) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.getgroups()
[11, 0, 11, 0, 3, 61, 29, 20, 3511889, 1, 3368710, 1, 2, 0, 1537888, 1, 223]
>>> len(_)
17
>>> 


I haven't tested yet if this version works on other platforms, but at least on Linux and HP-UX the manpage is similar enough to the one on OSX that I expect it to work there as well. (All 3 manpage say that getroups(0, grouplist) returns the number of secondary groups without modifying the grouplist argument).


BTW. os.setgroups also needs fixing for OSX: as it is a python script cannot set the grouplist to a value with more than 16 entries, even though the system is obviously capable of doing just that.

BTW2. The patch is for the trunk.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file16333/os-getgroups.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Feb 23 10:18:43 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 23 Feb 2010 09:18:43 +0000
Subject: [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: <1266916723.39.0.370692152206.issue7997@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> BTW, should the changes to the generated "configure" be excluded
> from such patches, or should they be included? (to what extent do
> they contain meaningful information during review?)

Not sure.  I think it's fine to leave the configure changes out of a posted patch, especially if you also add a tracker comment reminding potential reviewers to regenerate configure.   If the generated configure changes are small, I don't see a problem with leaving them in the patch either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7997>
_______________________________________

From report at bugs.python.org  Tue Feb 23 10:23:36 2010
From: report at bugs.python.org (Francesco Del Degan)
Date: Tue, 23 Feb 2010 09:23:36 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1266917016.06.0.0336925154232.issue6280@psf.upfronthosting.co.za>


Francesco Del Degan <f.deldegan at ngi.it> added the comment:

I attached a patch that implements timegm according to two constraints:

1. If HAVE_TIMEGM is defined, use it

or

2. If HAVE_MKTIME and HAVE_WORKING_TZSET use a portable way, using mktime (taken from timegm(3) man)

Attached patches are for:

r264, r273a1, r311, trunk

What i'm missing just now are the tests (test_time.py) and docs update, if you like the patch, i can continue on that.

----------
Added file: http://bugs.python.org/file16334/timemodule-gmtime-r264.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Tue Feb 23 14:18:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 23 Feb 2010 13:18:30 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1266909655.38.0.892015151078.issue7900@psf.upfronthosting.co.za>
Message-ID: <d38f5331002230518w4f002736k449380997523ad12@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Tue, Feb 23, 2010 at 2:20 AM, Ronald Oussoren <report at bugs.python.org> wrote:
> ..
> Alexander: ??What makes you think r63955 introduced the problem?

That revision introduced _DARWIN_C_SOURCE which, as I explained, has
two effects on get/setgroups:

"""
It turns out that defining _DARWIN_C_SOURCE not only allows
getgroups() output to exceed NGROUPS_MAX (as documented), but also
effectively disables setgroups() which is not documented.
"""

I further added:

"""
In order to have both working os.setgroups() and os.getgroups()
supporting more than NGROUPS_MAX results, it appears that the two
functions should be compiled in separate compilation units which is
probably too big of a price to pay for the functionality.
"""

I agree that this is a important distinction, but I seem to recall
discussion on python-dev or elsewhere on the tracker that concluded
that unexpected exceptions can be classified as crashes.  For most
users the difference between hard and soft crash is purely academic -
in either case their python program terminates due to a bug in python
and the "type" menu does not have separate entries for hard and soft
crashes.

> The Apple fix for getgroups in python2.6 is odd, it uses an undocumented API
> (getgrouplist_2).

I agree, Apple patch is not acceptable.  Not only it is undocumented,
but I suspect it is simply wrong because getgrouplist_2 is likely to
be a variant of getgrouplist that handles memory allocation and
returns group list from system's group database rather than from
per-process setting. (I have not verified that point, though.)

>
> If I read the manpage correctly there is a posixly correct way to implement os.getgroups:
>
> * call getgroups(MAX_GROUPS,...)

Note that MAX_GROUPS is 65536 on Linux and may be even higher on other
systems.  Allocating 256K on heap is wasteful and allocating the same
on the stack may even hard crash python.

> * if that fails: call getgroups(0,...), the result is groupcount

Please note the following comment I found in GNU coreutils source code:

/* On at least Ultrix 4.3 and NextStep 3.2, getgroups (0, NULL) always
   fails.  On other systems, it returns the number of supplemental
   groups for the process.  This function handles that special case
   and lets the system-provided function handle all others.  However,
   it can fail with ENOMEM if memory is tight.  It is unspecified
   whether the effective group id is included in the list.  */

This is more or less what my original patch did, but it suffers from a
race condition.

I am attaching a patch that I wrote yesterday, but did not submit
because it does not fix setgroups.  I am attaching it now so that we
can compare our approaches.

----------
Added file: http://bugs.python.org/file16338/issue7900-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________
-------------- next part --------------
Index: Modules/posixmodule.c
===================================================================
--- Modules/posixmodule.c	(revision 78265)
+++ Modules/posixmodule.c	(working copy)
@@ -3833,17 +3833,20 @@
 posix_getgroups(PyObject *self, PyObject *noargs)
 {
     PyObject *result = NULL;
+        gid_t *grouplist;
+        int n, nbuf;
 
-#ifdef NGROUPS_MAX
-#define MAX_GROUPS NGROUPS_MAX
-#else
-        /* defined to be 16 on Solaris7, so this should be a small number */
-#define MAX_GROUPS 64
-#endif
-        gid_t grouplist[MAX_GROUPS];
-        int n;
-
-        n = getgroups(MAX_GROUPS, grouplist);
+	nbuf = 16;
+	while (1) {
+	    grouplist = PyMem_MALLOC(nbuf * sizeof(gid_t));
+	    if (grouplist == NULL)
+	        return PyErr_NoMemory();
+	    n = getgroups(nbuf, grouplist);
+	    if (n > 0 || errno != EINVAL)
+		break;
+	    PyMem_FREE(grouplist);
+	    nbuf *= 2;
+	}
         if (n < 0)
             posix_error();
         else {
@@ -3861,6 +3864,7 @@
                 }
             }
         }
+	PyMem_FREE(grouplist);
 
     return result;
 }
@@ -5713,35 +5717,35 @@
 posix_setgroups(PyObject *self, PyObject *groups)
 {
 	int i, len;
-        gid_t grouplist[MAX_GROUPS];
+        gid_t *grouplist;
+	PyObject *ret = NULL;
 
 	if (!PySequence_Check(groups)) {
 		PyErr_SetString(PyExc_TypeError, "setgroups argument must be a sequence");
 		return NULL;
 	}
 	len = PySequence_Size(groups);
-	if (len > MAX_GROUPS) {
-		PyErr_SetString(PyExc_ValueError, "too many groups");
-		return NULL;
-	}
+	grouplist = PyMem_MALLOC(len * sizeof(gid_t));
+	if (grouplist == NULL)
+	        return PyErr_NoMemory();
 	for(i = 0; i < len; i++) {
 		PyObject *elem;
 		elem = PySequence_GetItem(groups, i);
 		if (!elem)
-			return NULL;
+			goto done;
 		if (!PyInt_Check(elem)) {
 			if (!PyLong_Check(elem)) {
 				PyErr_SetString(PyExc_TypeError,
 						"groups must be integers");
 				Py_DECREF(elem);
-				return NULL;
+				goto done;
 			} else {
 				unsigned long x = PyLong_AsUnsignedLong(elem);
 				if (PyErr_Occurred()) {
 					PyErr_SetString(PyExc_TypeError, 
 							"group id too big");
 					Py_DECREF(elem);
-					return NULL;
+					goto done;
 				}
 				grouplist[i] = x;
 				/* read back to see if it fits in gid_t */
@@ -5749,7 +5753,7 @@
 					PyErr_SetString(PyExc_TypeError,
 							"group id too big");
 					Py_DECREF(elem);
-					return NULL;
+					goto done;
 				}
 			}
 		} else {
@@ -5759,7 +5763,7 @@
 				PyErr_SetString(PyExc_TypeError,
 						"group id too big");
 				Py_DECREF(elem);
-				return NULL;
+				goto done;
 			}
 		}
 		Py_DECREF(elem);
@@ -5767,8 +5771,11 @@
 
 	if (setgroups(len, grouplist) < 0)
 		return posix_error();
-	Py_INCREF(Py_None);
-	return Py_None;
+	ret = Py_None;
+	Py_INCREF(ret);
+ done:
+	PyMem_FREE(grouplist);
+	return ret;
 }
 #endif /* HAVE_SETGROUPS */
 

From report at bugs.python.org  Tue Feb 23 14:28:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 23 Feb 2010 13:28:40 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266931720.19.0.837614851453.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Ronald,

Have you tested your patch with issue7900-tests.diff?  

On my system:

$ ./python.exe Lib/test/test_posix.py
testNoArgFunctions (__main__.PosixTester) ... Segmentation fault

and

$ sudo ./python.exe Lib/test/test_posix.py
..
FAIL: test_setgroups (__main__.PosixGroupsTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_posix.py", line 403, in test_setgroups
    self.assertListEqual(groups, posix.getgroups())
AssertionError: Lists differ: [0] != [3419130827, 3419130827, 34191...

First differing element 0:
0
3419130827

Second list contains 17 additional elements.
First extra element 1:
3419130827

- [0]
+ [3419130827,
+  3419130827,
+  3419130827,
+  3419130827,
+  4227582923,
+  4227595259,
+  64507,
+  16777216,
+  3688580934,
+  3688618971,
+  4867048,
+  1,
+  3688618971,
+  3688618971,
+  3688618971,
+  3688618971,
+  3688618971,
+  3688618971]
..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Feb 23 14:42:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Feb 2010 13:42:31 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266932551.03.0.620830905758.issue7900@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Feb 23 14:43:30 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 23 Feb 2010 13:43:30 +0000
Subject: [issue4617] SyntaxError when free variable name is also an exception
	target
In-Reply-To: <e8bf7a531002221551q1d65db03o84a6a9b63f908797@mail.gmail.com>
Message-ID: <ca471dc21002230543y701f88b9q6a58bc86edd248d8@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

On Mon, Feb 22, 2010 at 6:51 PM, Jeremy Hylton <report at bugs.python.org> wrote:
> There's no reason we couldn't revise the language spec to explain that
> except clauses and comprehensions are block statements, i.e.
> statements that introduce a new block.

However (even apart from the below example) it would be tough to
implement cleanly in CPython.

> For the except case, there would be some weird effects.
>
> y = 10
> try:
> ?...
> except SomeError as err:
> ?y = 12
> print y ?# prints 10
>
> In the example above, y would be a local variable in the scope of the
> except handler that shadows the local variable in the block that
> contains the try/except. ?It might be confusing that you couldn't
> assign to a local variable in the except handler without using a
> nonlocal statement.

Yeah, there are all sorts of problems with less-conspicuous nested
scopes like this, for a language that defaults to local assignment
like Python. Hence the horrible hacks.

>> As long as we don't have nested blocks, I think it's okay to see the limitation on (implicit or explicit) "del" of a cell variable as a compiler deficiency and fix that deficiency.
>
> The general request here is to remove all the SyntaxErrors about
> deleting cell variables, right? ?Instead, you'd get a NameError at
> runtime saying that the variable is currently undefined. ?You'd want
> that change regardless of whether we change the language as described
> above.

Yeah, if we could kill those SyntaxErrors we can leave the rest as is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4617>
_______________________________________

From report at bugs.python.org  Tue Feb 23 14:45:43 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 23 Feb 2010 13:45:43 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1266932743.79.0.72190524807.issue7649@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here's a new patch that uses PyUnicode_FromStringAndSize and PyUnicode_AS_UNICODE(s)[0]. I also added some comments and tested it and it seems to work fine.

----------
Added file: http://bugs.python.org/file16339/issue7649v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Tue Feb 23 14:46:35 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 23 Feb 2010 13:46:35 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266932795.31.0.207724978264.issue7900@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

My patch is very lightly tested and I didn't try to use the additional testcases. 

I get test failures, but no crashes, when I do run the additional tests. I haven't had time to review the testcases though. 

What I did notice though is that the tests don't actually test the issue at hand: having more than 16 secondairy groups on OSX.

I'm not too thrilled about your approach of growing the grouplist argument of getgroups until the results fit, the comment in the coreutils sources refers to two very old unix flavors and IMHO it is not worthwhile to try to support those.

Wrt. the value of MAX_GROUPS on Linux: we could change the test that defined MAX_GROUPS to ensure that the value doesn't get too large, from:

#ifdef NGROUPS_MAX


to:

#if defined(NGROUPS_MAX) && NGROUPS_MAX <= 64

This combined with my patch would result in less stack usage while still working when a user has a lot of secondary groups.


I agree that Apple's patch is broken, it almost certainly reads the secondary groups from the user database instead of returning the actual value for the running process (based on the prototype and additional includes).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Feb 23 14:51:37 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 23 Feb 2010 13:51:37 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1266933097.89.0.879351603461.issue7649@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The patch looks good to me, in that it implements your desired functionality well.

I haven't been following the issue closely enough to know whether or not this new functionality is the right way to go. (I'm not saying it's not, just that I don't have an opinion on it.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Tue Feb 23 15:38:33 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 23 Feb 2010 14:38:33 +0000
Subject: [issue4617] SyntaxError when free variable name is also an exception
	target
In-Reply-To: <1266933144.1.0.618302987129.issue4617@psf.upfronthosting.co.za>
Message-ID: <ca471dc21002230638s7b58400j3d30ff578c7fa478@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

I don't think so. It's very marginal.

--Guido (on Android)

On Feb 23, 2010 8:52 AM, "Amaury Forgeot d&apos;Arc" <report at bugs.python.org>
wrote:

Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The above patch adds a new opcode (DELETE_DEREF), does the Moratorium apply
here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python...

----------
Added file: http://bugs.python.org/file16341/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4617>
_______________________________________
-------------- next part --------------
<p>I don&#39;t think so. It&#39;s very marginal. </p>
<p>--Guido (on Android)</p>
<p><blockquote type="cite">On Feb 23, 2010 8:52 AM, &quot;Amaury Forgeot d&amp;apos;Arc&quot; &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt; wrote:<br><br><br>
Amaury Forgeot d&#39;Arc &lt;<a href="mailto:amauryfa at gmail.com">amauryfa at gmail.com</a>&gt; added the comment:<br>
<br>
The above patch adds a new opcode (DELETE_DEREF), does the Moratorium apply here?<br>
<br>
----------<br>
<p><font color="#500050"><br>_______________________________________<br>Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&lt;http://bugs.python...</font></p></blockquote></p>

From report at bugs.python.org  Tue Feb 23 15:42:22 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 23 Feb 2010 14:42:22 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1266932795.31.0.207724978264.issue7900@psf.upfronthosting.co.za>
Message-ID: <d38f5331002230642q4cdab764kffeb3fa96c2b62bc@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Tue, Feb 23, 2010 at 8:46 AM, Ronald Oussoren <report at bugs.python.org> wrote:
..
> What I did notice though is that the tests don't actually test the issue at hand:
> having more than 16 secondairy groups on OSX.

This is easy to fix: just add another entry in groups

+    def test_setgroups(self):
+        for groups in [[0], range(16)]:

I did not do it for two reasons:

1. Laziness. :-)  It was easier for me to just replace "16" above with
other values in my tests than to introduce platform checks.  I believe
16 groups is supported on all relevant platforms.

2. I am not sure python should support non-posix behavior and allow
more than os.sysconf('SC_NGROUPS_MAX') groups to be returned from
os.getgroups().  IMO, users who need more than 16 groups on OSX should
bug Apple to fix sysconf(_SC_NGROUPS_MAX).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Feb 23 15:55:31 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 23 Feb 2010 14:55:31 +0000
Subject: [issue1669349] make install fails if no previous Python installation
Message-ID: <1266936931.93.0.328792423529.issue1669349@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Interesting. What is the content of sys.path when you start ./python from the build tree?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1669349>
_______________________________________

From report at bugs.python.org  Tue Feb 23 15:55:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Feb 2010 14:55:34 +0000
Subject: [issue7976] warnings could provide a pre-filled -W option for
	third-party tools
In-Reply-To: <1266771333.82.0.427614024661.issue7976@psf.upfronthosting.co.za>
Message-ID: <1266936934.05.0.0927838619569.issue7976@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I believe the OP?s request is partly motivated by the fact that there is a need to access a private function in warnings. See http://mail.python.org/pipermail/python-ideas/2010-February/006870.html where Nick Coghlan proposes that ?the idea of creating a public API in the warnings module to expose the functionality of warnings._processoptions in a clean fashion seems like a reasonable idea that achieves the same goal without coupling it to a particular command line parsing approach?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7976>
_______________________________________

From report at bugs.python.org  Tue Feb 23 16:05:40 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 23 Feb 2010 15:05:40 +0000
Subject: [issue7863] platform module doesn't detect Windows 7
In-Reply-To: <1266937095.75.0.652608468117.issue7863@psf.upfronthosting.co.za>
Message-ID: <4B83EEBC.4060500@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Brian Curtin wrote:
> 
> Brian Curtin <curtin at acm.org> added the comment:
> 
> Here is the patch which checks whether the new info is available and uses it, otherwise it falls back to the original way.

Thanks. Could you apply the same logic to the second hunk of the
patch ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7863>
_______________________________________

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: [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 16:24:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 23 Feb 2010 15:24:08 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1266932795.31.0.207724978264.issue7900@psf.upfronthosting.co.za>
Message-ID: <d38f5331002230724j5836f8e9p251f26216efa93d2@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Tue, Feb 23, 2010 at 8:46 AM, Ronald Oussoren <report at bugs.python.org> wrote:
> ..
> I get test failures, but no crashes, when I do run the additional tests.

The crash that I see is apparently due to underallocated  memory:

 alt_grouplist = PyMem_Malloc(n);

should be

 alt_grouplist = PyMem_Malloc(n * sizeof(gid_t));

..
> I'm not too thrilled about your approach of growing the grouplist argument of
> getgroups until the results fit, the comment in the coreutils sources refers to two > very old unix flavors and IMHO it is not worthwhile to try to support those.
>

You are probably right on this point, but the main issue with using
getgroups(0, ..) is the race condition that it introduces.  If another
thread adds a group between n = getgroups(0, ..) and getgroups(n, ..)
calls, the second call will fail.

Makes sense regardless of the approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Feb 23 16:29:06 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 23 Feb 2010 15:29:06 +0000
Subject: [issue8002] on OSX the file creation date not available in os.stat
In-Reply-To: <1266938492.4.0.0671883953878.issue8002@psf.upfronthosting.co.za>
Message-ID: <1266938946.84.0.599673556743.issue8002@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

To be more precise: see issue8001.

The OSX 10.5 introduces a new version of stat 'stat64' that exposes additional information to posix-style programs, amongst which is the file creation date. 

This field is not present in earlier editions of OSX and is also not present on other platforms. That is, the field is not the same as the "ctime" field which contains the timestamp for the last metadata change for a file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8002>
_______________________________________

From report at bugs.python.org  Tue Feb 23 16:33:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 23 Feb 2010 15:33:25 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266939205.6.0.731941087374.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

E-mail to tracker handling still seems to remove '>' quoted lines.   I am reposting a couple of comments that got clobbered:

--
> * allocate an array of groupcount gid_t's and call getgroups(groupcount)
>
This is more or less what my original patch did, but it suffers from a
race condition.

> I'll work on a patch that implements this.
>
I am attaching a patch that I wrote yesterday, but did not submit
because it does not fix setgroups.  I am attaching it now so that we
can compare our approaches.

--


> Wrt. the value of MAX_GROUPS on Linux: we could change the test that defined > MAX_GROUPS to ensure that the value doesn't get too large, from:
>
> #ifdef NGROUPS_MAX
>
>
> to:
>
> #if defined(NGROUPS_MAX) && NGROUPS_MAX <= 64
>
> This combined with my patch would result in less stack usage while still working > when a user has a lot of secondary groups.
>
Makes sense regardless of the approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Feb 23 16:53:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Feb 2010 15:53:58 +0000
Subject: [issue7976] warnings should provide a public API for accessing its
	option parsing code
In-Reply-To: <1266771333.82.0.427614024661.issue7976@psf.upfronthosting.co.za>
Message-ID: <1266940438.9.4.86444100982e-05.issue7976@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I see.  I agree with Nick, a public API function in Warnings is better than something specific to optparse or argparse.  If the op (or anyone else) wants to propose a patch to create such an API (with docs and tests), that would be welcome.  The docs for that API could then include the recipe for using it with argparse.

----------
nosy: +ncoghlan
priority: low -> normal
title: warnings could provide a pre-filled -W option for third-party tools -> warnings should provide a public API for accessing its option parsing code

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7976>
_______________________________________

From report at bugs.python.org  Tue Feb 23 17:29:04 2010
From: report at bugs.python.org (Jack Diederich)
Date: Tue, 23 Feb 2010 16:29:04 +0000
Subject: [issue6825] Minor documentation bug with os.path.split
In-Reply-To: <1251923724.11.0.872695091666.issue6825@psf.upfronthosting.co.za>
Message-ID: <1266942544.55.0.00765120744797.issue6825@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

how about "an equivalent path" instead of "equal path"?  The result of ntpath.join(ntpath.split(path)) should point to the same location even if it isn't literally the same string.

----------
nosy: +jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6825>
_______________________________________

From report at bugs.python.org  Tue Feb 23 17:52:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Feb 2010 16:52:07 +0000
Subject: [issue7530] doc of multiprocessing.managers is wrong (server_forever)
In-Reply-To: <1261053649.05.0.856911963743.issue7530@psf.upfronthosting.co.za>
Message-ID: <1266943927.02.0.934941207114.issue7530@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

There is a typo in the changed text that prevents correct reST interpretation. s/```/``/ would fix it.

Regards

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7530>
_______________________________________

From report at bugs.python.org  Tue Feb 23 18:01:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 23 Feb 2010 17:01:36 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266944496.46.0.928555778458.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I think I finally understand what is going on and ready to make what I believe is a reasonable proposal.

Setting _DARWIN_C_SOURCE (or _DARWIN_UNLIMITED_GETGROUPS) replaces getgroups with a Darwin extension, but does not change setgroups:

$ nm tg1 | grep etgroups
                 U _getgroups
                 U _setgroups
$ nm tg2 | grep etgroups
                 U _getgroups$DARWIN_EXTSN
                 U _setgroups

(here tg2 is compiled with -D_DARWIN_C_SOURCE=1)

The extended getgroups$DARWIN_EXTSN is not getgroups at all and instead is effectively a call to getgrouplist(getpwuid(..)->pw_name, ..).  In other words, it reads the system database instead of the per-process list. (This also explains the choice made in Apple patch.)

This means that _DARWIN_C_SOURCE is not appropriate for posixmodule.c.

My recommendation is now to close this bug by reverting _DARWIN_C_SOURCE setting locally in posixmodule.c or globally in pyconfig.h in favor of more targeted settings in the modules that need Darwin extensions.

This will leave a feature request to add os.getgrouplist() for users who actually want to read the system database instead of per-process group list.

The other ideas related to allocation of grouplist buffer can be left as a "resource usage" issue.

Lack of support for more than 16 groups in OSX get/setgroups() should be left for Apple to take care of.  This limitation can be documented possibly as a conditional appendix to get/setgroups() docstrings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Feb 23 18:11:25 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 23 Feb 2010 17:11:25 +0000
Subject: [issue7863] platform module doesn't detect Windows 7
In-Reply-To: <1265412745.93.0.400074024271.issue7863@psf.upfronthosting.co.za>
Message-ID: <1266945085.04.0.941202902095.issue7863@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Whoops, sorry. Here is the change as requested. It reverts to the old way when needed, which hardcodes the version to VER_NT_WORKSTATION as it effectively used to. 


Outside of a hackish and incredibly slow method, I have no idea how to figure out workstation vs. server when OSVERSIONINFOEX isn't available. The slow hack would be to use a subprocess to call "systeminfo" and parse the results, but that would take 4-5 seconds at best.

I'll try to get access to a Server 2008 box again after PyCon and see if there's anything I'm missing when trying to identify it.

----------
stage: test needed -> patch review
Added file: http://bugs.python.org/file16343/issue7863_trunk_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7863>
_______________________________________

From report at bugs.python.org  Tue Feb 23 18:16:15 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 23 Feb 2010 17:16:15 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266945375.82.0.284424312246.issue7900@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm -1 w.r.t changing the definition of _DARWIN_C_SOURCE, at least not without a thorough investigation on what else this changes. Removing _DARWIN_C_SOURCE without setting some other defines may well cause in removal of functions from header files (I'm  pretty sure that setting _POSIX_C_SOURCE without setting other defines removes anything that isn't posix from view).

How did you detect that the modern getgroups implementation doesn't query the kernel? That would be very odd.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Feb 23 18:18:34 2010
From: report at bugs.python.org (Jack Diederich)
Date: Tue, 23 Feb 2010 17:18:34 +0000
Subject: [issue6518] Enable 'with' statement in ossaudiodev module
In-Reply-To: <1247965666.73.0.755368316919.issue6518@psf.upfronthosting.co.za>
Message-ID: <1266945514.86.0.501720519003.issue6518@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

+1, the C patch looks good to me.  The test file needs a new test that checks the 'with' behavior.  Also, what changed so that the test now needs to ignore AttributeErrors in play_sound_file()?

----------
nosy: +jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6518>
_______________________________________

From report at bugs.python.org  Tue Feb 23 18:22:46 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 23 Feb 2010 17:22:46 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266945766.05.0.0892535801133.issue7900@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
nosy:  -michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Feb 23 18:28:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 23 Feb 2010 17:28:46 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1266946126.77.0.480550531229.issue6280@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

The patch (I reviewed timemodule-gmtime-trunk.diff) looks mostly correct.  One problem that I see is that it will likely produce compiler warnings on the systems without timegm and mktime.  The warnings will be due to unused static function time_timegm and use of uninitialized variable tt.  I suggest that you wrap time_timegm in appropriate #ifdefs.

I trust that you tested that it works, but

#ifdef HAVE_TIMEGM || (defined(HAVE_MKTIME) && defined(HAVE_WORKING_TZSET))

looks like a non-standard construct to me.  I would do

#if defined(HAVE_TIMEGM) || (defined(HAVE_MKTIME) && defined(HAVE_WORKING_TZSET))

instead.

Finally, tests and documentation are needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Tue Feb 23 18:32:12 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 23 Feb 2010 17:32:12 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266946332.9.0.113714724505.issue7900@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm probably being extremely dense at the moment, but the program below doesn't behave as I'd expect on OSX:

#include <unistd.h>

int main(void)
{
#if 1
	gid_t gids[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 };
	int r;
	r = setgroups(16, gids);
	if (r == -1) {
		perror("setgroups");
		return 1;
	}
#endif
	setgid(3);
	setuid(502);
	execl("/usr/bin/id", "/usr/bin/id", NULL);
	perror("exec");
	return 1;
}


I'd expect it to print something simular to this (when started as root, either through sudo or by logging in as root):

uid=502 gid=3(sys) groups=1(bin),2(daemon),3(sys),4,5(tty),6(disk),7(lp),8(www),9(kmem),10(wheel),11,12(mail),13(news),14(uucp),15(shadow),16(dialout)

That doesn't happen however, the output above is from a linux system. On OSX it prints the group information that's associated with the 502 account in the user database, and only prints the expected values when I call setuid(600), which is a UID that isn't in use on my system.

This is both with and without setting _DARWIN_C_SOURCE and even when compiling with deployment target 10.4 and using the 10.4 SDK.

I'm therefore in favor of keeping _DARWIN_C_SOURCE and adding the workaround for a larger number of groups as implemented in os-getgroups.patch.

This means that using

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Feb 23 18:42:28 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 23 Feb 2010 17:42:28 +0000
Subject: [issue6452] urllib2.Request() will not work with long authorization
	headers
In-Reply-To: <1247171212.16.0.153578290973.issue6452@psf.upfronthosting.co.za>
Message-ID: <1266946948.92.0.039014588275.issue6452@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

There is a OLD Known issue that base64.encodestring will insert in a line-break in the authorization header. See Issue1574068
I fear, you might have done something like this.

base64string = base64.encodestring('%s:%s' %(username,passwd))[:-1]
request.add_header("Authorization","Basic %s" % base64string)
urllib2.urlopen(request)

You might have encountered this problem of Request not working with long authorization headers.
Instead, if you do

base64string = base64.b64encode('%s:%s' %(username,passwd))[:-1]

and then add the string to your headers, it might work properly. It does so for me.

(alternatively you can set base64.MAXBINSIZE=1000000, but the first solution is much cleaner.

I am closing this bug as Invalid. If you feel, it is valid and you used base64.b64encode for encoding the Basic Authentication header. feel free to reopen the bug, with a snippet of code attached.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6452>
_______________________________________

From report at bugs.python.org  Tue Feb 23 18:47:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 23 Feb 2010 17:47:51 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266947271.01.0.793227674479.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Tue, Feb 23, 2010 at 12:16 PM, Ronald Oussoren <report at bugs.python.org> wrote:
..
> How did you detect that the modern getgroups implementation doesn't
> query the kernel? That would be very odd.

I wish I could say that I mastered dtrace under OSX, but I am not there yet. :-)  There are two facts that convinced me that this is the case

1. Since setgroups is the same regardless of _DARWIN_C_SOURCE but getgroups returns different values after setgroups in programs compiled with an without _DARWIN_C_SOURCE, the problem must be in getgroups.

2. Setting breakpoint at getpwuid in gdb I see that it is not called when _DARWIN_C_SOURCE is not set, but when it is

(gdb) where
#0  0x00007fff86d2c487 in getpwuid ()
#1  0x00007fff86da229b in getgroups$DARWIN_EXTSN ()
#2  0x0000000100000ddd in printgroups ()
#3  0x0000000100000e6e in main ()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

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: [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 19:08:47 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 23 Feb 2010 18:08:47 +0000
Subject: [issue7994] object.__format__ should reject format strings
In-Reply-To: <1266875939.21.0.792202593026.issue7994@psf.upfronthosting.co.za>
Message-ID: <1266948527.9.0.233710999675.issue7994@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This version of the patch adds support for classic classes and adds tests. Documentation still needs to be written.

Again, this diff is against trunk.

If anyone wants to review this, in particular the tests that exercise PendingDeprecationWarning, that would be great.

----------
keywords:  -easy
Added file: http://bugs.python.org/file16344/issue7994-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7994>
_______________________________________

From report at bugs.python.org  Tue Feb 23 19:55:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 23 Feb 2010 18:55:26 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266951326.03.0.172030195225.issue7900@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

David,

Can you unset "normal" priority from this issue.  Regardless of whether it is a crash or not a crash, this is a regression for which there is no user work-around.  It looks like "normal" priority makes the issue disappear from the top of "Show Open" search and this is inconvenient while the issue is being worked on.

On Tue, Feb 23, 2010 at 12:32 PM, Ronald Oussoren <report at bugs.python.org> wrote:
..
>        setgid(3);
>        setuid(502);
>        execl("/usr/bin/id", "/usr/bin/id", NULL);
..
> On OSX it prints the group information that's associated with the 502 > account in the user database, and only prints the expected values when > I call setuid(600), which is a UID that isn't in use on my system.
>

This looks like a bug (surprise!) in OSX' /usr/bin/id.  With a freshly compiled coreutils-8.4, your program behaves as you expect when using /usr/local/bin/id.
  

> This is both with and without setting _DARWIN_C_SOURCE and even when
> compiling with deployment target 10.4 and using the 10.4 SDK.

This is to be expected because your program only calls setgroups which is unaffected by _DARWIN_C_SOURCE settings.  Note that it will also fail regardless of compilation mode if you change 16 to 17.

> I'm therefore in favor of keeping _DARWIN_C_SOURCE and adding the
> workaround for a larger number of groups as implemented in
> os-getgroups.patch.

I don't understand the "therefore" part.  As you say, _DARWIN_C_SOURCE setting has no effect on your program, so what is the advantage of keeping it is posixmodule.c?

As I explained, with _DARWIN_C_SOURCE set,

"""
[OSX getgroups] is not getgroups at all and instead is effectively a call to getgrouplist(getpwuid(..)->pw_name, ..).  In other words, it reads the system database instead of the per-process list.
"""

Why do you think this is what users expect to get when calling posix.getgroups()?


> This means that using

It looks like the rest of your message was lost ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Feb 23 20:24:53 2010
From: report at bugs.python.org (Gael)
Date: Tue, 23 Feb 2010 19:24:53 +0000
Subject: [issue1669349] make install fails if no previous Python installation
In-Reply-To: <1266936931.93.0.328792423529.issue1669349@psf.upfronthosting.co.za>
Message-ID: <4B842B81.9070702@makina-corpus.com>


Gael <gael.pegliasco at makina-corpus.com> added the comment:

Amaury Forgeot d'Arc a ?crit :
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> Interesting. What is the content of sys.path when you start ./python from the build tree?
>   

I will tell you tomorrow, I have no access to the computer at this hour.

Ga?l,
> ----------
> nosy: +amaury.forgeotdarc
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1669349>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1669349>
_______________________________________

From report at bugs.python.org  Tue Feb 23 20:46:10 2010
From: report at bugs.python.org (Thomas Heller)
Date: Tue, 23 Feb 2010 19:46:10 +0000
Subject: [issue7959] ctypes memory leak
In-Reply-To: <1266527619.9.0.810714625756.issue7959@psf.upfronthosting.co.za>
Message-ID: <1266954370.33.0.255661298225.issue7959@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

CThunkObject is not registered correctly with the cycle GC.  The attached patch, against trunk, fixes the issue.

----------
keywords: +patch
Added file: http://bugs.python.org/file16345/issue7957.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7959>
_______________________________________

From report at bugs.python.org  Tue Feb 23 21:41:29 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Tue, 23 Feb 2010 20:41:29 +0000
Subject: [issue4617] SyntaxError when free variable name is also an exception
	target
In-Reply-To: <ca471dc21002230638s7b58400j3d30ff578c7fa478@mail.gmail.com>
Message-ID: <e8bf7a531002231241p7f4cbe4bj10328e40f49b9f75@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

The patch looks pretty good.

I'd factor out the common error-checking code (common between
LOAD_DEREF and DELETE_DEREF) into a helper function.

It would also be good to add some test cases.

Jeremy

On Tue, Feb 23, 2010 at 9:38 AM, Guido van Rossum
<report at bugs.python.org> wrote:
>
> Guido van Rossum <guido at python.org> added the comment:
>
> I don't think so. It's very marginal.
>
> --Guido (on Android)
>
> On Feb 23, 2010 8:52 AM, "Amaury Forgeot d&apos;Arc" <report at bugs.python.org>
> wrote:
>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> The above patch adds a new opcode (DELETE_DEREF), does the Moratorium apply
> here?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python...
>
> ----------
> Added file: http://bugs.python.org/file16341/unnamed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4617>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4617>
_______________________________________

From report at bugs.python.org  Tue Feb 23 21:59:29 2010
From: report at bugs.python.org (Wim)
Date: Tue, 23 Feb 2010 20:59:29 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1266958769.55.0.531912702024.issue6560@psf.upfronthosting.co.za>


Wim <wiml at hhhh.org> added the comment:

I just ran across yet another implementation of sendmsg support for python sockets, whose feature set seems to complement Kalman Gergely's implementation:
  http://www.pps.jussieu.fr/~ylg/PyXAPI by Yves Legrandgerard


(Out of curiosity, people have been submitting requests for, and patches with implementations of, this feature for five or more years now and they're never accepted. Is there some opposition to sendmsg support in Python? It's a missing feature that bites me pretty regularly.)

----------
nosy: +wiml

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Tue Feb 23 22:10:29 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 23 Feb 2010 21:10:29 +0000
Subject: [issue1537721] csv module: add header row to DictWriter
Message-ID: <1266959429.01.0.291969197633.issue1537721@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Fixed in SVN, r78384.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1537721>
_______________________________________

From report at bugs.python.org  Tue Feb 23 22:12:39 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 23 Feb 2010 21:12:39 +0000
Subject: [issue1537721] csv module: add header row to DictWriter
Message-ID: <1266959559.44.0.0404954974748.issue1537721@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
assignee:  -> djc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1537721>
_______________________________________

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: [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  Tue Feb 23 22:33:45 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 23 Feb 2010 21:33:45 +0000
Subject: [issue8000] Bad deprecated label in documentation
In-Reply-To: <1266929990.82.0.373530830286.issue8000@psf.upfronthosting.co.za>
Message-ID: <1266960825.17.0.255942802732.issue8000@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r78385, thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8000>
_______________________________________

From report at bugs.python.org  Tue Feb 23 22:35:45 2010
From: report at bugs.python.org (Jack Diederich)
Date: Tue, 23 Feb 2010 21:35:45 +0000
Subject: [issue4331] Can't use _functools.partial() created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1266960945.97.0.774737068529.issue4331@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

We talked about it at sprints and the semantics are ambiguous and there are alternatives.

Ambiguous:
  def show_funcs(*args): print(args)
  class A():
    run = partial(1)
  ob = A()
  ob.run(2,3)
Should this print (self, 1, 2, 3) or (1, self, 2, 3)?  And what about
  partial(ob.run, 2)(3)

Alternatives: partial is a convenience function not an optimization (it doesn't offer a speedup.  So you can write a lambda or named function that has the exact semantics you want without suffering a speed penalty.

So unless there are a lot of good use cases with obvious behavior, we should refuse the temptation to guess and leave partial as-is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4331>
_______________________________________

From report at bugs.python.org  Tue Feb 23 22:37:16 2010
From: report at bugs.python.org (Jack Diederich)
Date: Tue, 23 Feb 2010 21:37:16 +0000
Subject: [issue4331] Can't use _functools.partial() created function as method
In-Reply-To: <1226817180.09.0.841012218041.issue4331@psf.upfronthosting.co.za>
Message-ID: <1266961036.2.0.145581929637.issue4331@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

correction:
  run = partial(1)
should have been
  run = partial(show_funcs, 1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4331>
_______________________________________

From report at bugs.python.org  Tue Feb 23 23:08:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Feb 2010 22:08:58 +0000
Subject: [issue8004] add small server to serve docs
In-Reply-To: <1266960126.19.0.905943018148.issue8004@psf.upfronthosting.co.za>
Message-ID: <1266962938.73.0.687861667314.issue8004@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

How does this make it easier to review the built documentation?  Most web browsers are happy to read off disk, and that seems easier than firing up a server.

(I would actually have a use case for this, since the machine I build the docs on isn't the machine my web browser runs on; but even there it seems easier to just run firefox remotely (or, in firefox's weird parlance, 'firefox --no-remote').)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8004>
_______________________________________

From report at bugs.python.org  Tue Feb 23 23:20:09 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 23 Feb 2010 22:20:09 +0000
Subject: [issue8004] add small server to serve docs
In-Reply-To: <1266960126.19.0.905943018148.issue8004@psf.upfronthosting.co.za>
Message-ID: <1266963609.7.0.721254126488.issue8004@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

I do almost all of my development on servers, so while I guess I could mount the remote file system and do that, that's not very easy to do (since I access my servers from multiple boxes, some of which run Windows, etc). I guess if not many people do that there's not much point, but I figured the script is small and straightforward enough that it might be nice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8004>
_______________________________________

From report at bugs.python.org  Tue Feb 23 23:23:59 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 23 Feb 2010 22:23:59 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266963839.63.0.885188519798.issue7900@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've filed issue #7681618 in Apple's bugtracker with the attached file "getsetgroups-bug.tar" as a way to reproduce the issue.

I want to wait a little to see how Apple responds (although I don't expect a quick response).

----------
Added file: http://bugs.python.org/file16347/getsetgroups-bug.tar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Feb 23 23:37:50 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 23 Feb 2010 22:37:50 +0000
Subject: [issue7984] missing dependencies using cProfile
In-Reply-To: <1266850506.92.0.292713556169.issue7984@psf.upfronthosting.co.za>
Message-ID: <1266964670.4.0.0706751471825.issue7984@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

That's a package decision by Ubuntu, not Python, and thus not a bug on our end. Thanks for the report anyway.

----------
nosy: +brett.cannon
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7984>
_______________________________________

From report at bugs.python.org  Tue Feb 23 23:42:28 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 23 Feb 2010 22:42:28 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1266964948.21.0.831561781647.issue7900@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

quoting compat(5) on OSX 10.6.2:

<quote>
     Defining _POSIX_C_SOURCE or _DARWIN_C_SOURCE causes library and kernel calls to conform to the SUSv3
     standards even if doing so would alter the behavior of functions used in 10.3.  Defining
     _POSIX_C_SOURCE also removes functions, types, and other interfaces that are not part of SUSv3 from the
     normal C namespace, unless _DARWIN_C_SOURCE is also defined (i.e., _DARWIN_C_SOURCE is _POSIX_C_SOURCE
     with non-POSIX extensions).  In any of these cases, the _DARWIN_FEATURE_UNIX_CONFORMANCE feature macro
     will be defined to the SUS conformance level (it is undefined otherwise).

     Starting in Mac OS X 10.5, if none of the macros _NONSTD_SOURCE, _POSIX_C_SOURCE or _DARWIN_C_SOURCE
     are defined, and the environment variable MACOSX_DEPLOYMENT_TARGET is either undefined or set to 10.5
     or greater (or equivalently, the gcc(1) option -mmacosx-version-min is either not specified or set to
     10.5 or greater), then UNIX conformance will be on by default, and non-POSIX extensions will also be
     available (this is the equivalent of defining _DARWIN_C_SOURCE).  For version values less that 10.5,
     UNIX conformance will be off (the equivalent of defining _NONSTD_SOURCE).
</quote>

If I read this correctly, this means that for deployment target 10.5 or later you must define _POSIX_C_SOURCE to get the correct version of getgroups, but that also hides all non-posix symbols in system headers. 

I haven't tested yet what the behavior is when neither _POSIX_C_SOURCE nor _DARWIN_C_SOURCE are defined (on OSX 10.4, 10.5 and 10.6).

BTW. It is possible to work around this by symbol renaming similarly to what Apple does in their headers to get the two variants of getgroups in the first place. But let's not go there unless there really is no other way.

As to your question "Why do you think this is what users expect to get when calling posix.getgroups()?": I'd expect that os.getgroups works just like it does in C code, and agrees with id(1). But then I'd also expect that os.setgroups affects the result of os.getgroups... Lame platform bugs are no fun :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Feb 23 23:51:39 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Tue, 23 Feb 2010 22:51:39 +0000
Subject: [issue4199] add shorthand global and nonlocal statements
In-Reply-To: <1266961045.83.0.043654954684.issue4199@psf.upfronthosting.co.za>
Message-ID: <e8bf7a531002231451x1b7c908fx95c57be98cd97fcc@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

Is deferred blocker a higher priority?

Jeremy

On Tue, Feb 23, 2010 at 4:37 PM, Georg Brandl <report at bugs.python.org> wrote:
>
> Georg Brandl <georg at python.org> added the comment:
>
> "High" is not high enough :)
>
> ----------
> priority: high -> deferred blocker
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4199>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4199>
_______________________________________

From report at bugs.python.org  Wed Feb 24 00:08:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Feb 2010 23:08:18 +0000
Subject: [issue8004] add small server to serve docs
In-Reply-To: <1266960126.19.0.905943018148.issue8004@psf.upfronthosting.co.za>
Message-ID: <1266966498.51.0.13426867972.issue8004@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, windows.  And if it was there, I'd probably use it.  Let's see what Georg things.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8004>
_______________________________________

From report at bugs.python.org  Wed Feb 24 00:13:47 2010
From: report at bugs.python.org (Jack Diederich)
Date: Tue, 23 Feb 2010 23:13:47 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1266966827.95.0.389112500144.issue6560@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

I've been digging into the patch.  Is there a reason sendmsg() wants an iterable of buffers instead of just accepting a str? The list-of-buffers more closely matches the underlying syscall but I'm not sure what the python benefit is, especially when recvmsg() only returns a single value (it only creates 1 iovec under the covers).  Python doesn't have "readv" like methods so making sendmsg/recvmsg work like recv/send (straight strings) seems like the way to go.

Also, the "y*" format character for packing/unpacking tuples is no longer supported - I'm assuming it used to mean buffers.

Does anyone have a good reference for using recvmsg/sendmsg?  I read the man pages and googled around but couldn't find anything.  I have no experience with using the calls in-the-wild.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Wed Feb 24 00:18:12 2010
From: report at bugs.python.org (Jack Diederich)
Date: Tue, 23 Feb 2010 23:18:12 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1266967092.78.0.35076972047.issue6560@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

Additional data point: the perl version takes a single scalar (instead of a list of scalars) for use with sendmsg()

http://search.cpan.org/~MJP/Socket-MsgHdr-0.01/MsgHdr.pm

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Wed Feb 24 00:23:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Feb 2010 23:23:39 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1266967419.43.0.705100564057.issue7649@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited: r78392 (r78394).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Wed Feb 24 00:24:17 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 23 Feb 2010 23:24:17 +0000
Subject: [issue8004] add small program to serve docs
In-Reply-To: <1266960126.19.0.905943018148.issue8004@psf.upfronthosting.co.za>
Message-ID: <1266967457.69.0.293262776322.issue8004@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Sure, I'm happy to fix up the little things. The point is that this works and solves (IMO) a real problem, so I wonder if we can get this in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8004>
_______________________________________

From report at bugs.python.org  Wed Feb 24 00:34:01 2010
From: report at bugs.python.org (Jack Diederich)
Date: Tue, 23 Feb 2010 23:34:01 +0000
Subject: [issue6560] socket sendmsg(), recvmsg() methods
In-Reply-To: <1248424219.19.0.278000580973.issue6560@psf.upfronthosting.co.za>
Message-ID: <1266968041.54.0.347825671811.issue6560@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

one of the other sprinters just pointed out that Modules/_multiprocessing.c (py3k branch) uses sendmsg/recvmsg internally to pass file descriptors back and forth.  The code is very short and readable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6560>
_______________________________________

From report at bugs.python.org  Wed Feb 24 00:41:10 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Tue, 23 Feb 2010 23:41:10 +0000
Subject: [issue4199] add shorthand global and nonlocal statements
In-Reply-To: <1228588118.18.0.731519728687.issue4199@psf.upfronthosting.co.za>
Message-ID: <e8bf7a531002231541p2e4cb55cl45f9ed3ea564c846@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

On Sat, Dec 6, 2008 at 1:28 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> I think I may have been merging add_ast_fields when I wrote the patch.
>
> Here's a new patch that handles "global x, = (5,)". To do it, I added a
> new flag* to the Global and Nonlocal AST objects that indicates whether
> the value needs to be unpacked or not.

You shouldn't need to do this.  The unpack is implied if the number of
identifiers is greater than 1.

Jeremy

> * The flag is an int. The bool AST type was removed in py3k.
>
> Added file: http://bugs.python.org/file12254/global_nonlocal_shorthand2.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4199>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4199>
_______________________________________

From jeremy at alum.mit.edu  Wed Feb 24 00:41:00 2010
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Tue, 23 Feb 2010 18:41:00 -0500
Subject: [issue4199] add shorthand global and nonlocal statements
In-Reply-To: <1228588118.18.0.731519728687.issue4199@psf.upfronthosting.co.za>
References: <1224887535.03.0.272495603252.issue4199@psf.upfronthosting.co.za>
	<1228588118.18.0.731519728687.issue4199@psf.upfronthosting.co.za>
Message-ID: <e8bf7a531002231541p2e4cb55cl45f9ed3ea564c846@mail.gmail.com>

On Sat, Dec 6, 2008 at 1:28 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> I think I may have been merging add_ast_fields when I wrote the patch.
>
> Here's a new patch that handles "global x, = (5,)". To do it, I added a
> new flag* to the Global and Nonlocal AST objects that indicates whether
> the value needs to be unpacked or not.

You shouldn't need to do this.  The unpack is implied if the number of
identifiers is greater than 1.

Jeremy



> * The flag is an int. The bool AST type was removed in py3k.
>
> Added file: http://bugs.python.org/file12254/global_nonlocal_shorthand2.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4199>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>

From jeremy at alum.mit.edu  Wed Feb 24 00:50:04 2010
From: jeremy at alum.mit.edu (Jeremy Hylton)
Date: Tue, 23 Feb 2010 18:50:04 -0500
Subject: [issue4199] add shorthand global and nonlocal statements
In-Reply-To: <e8bf7a531002231541p2e4cb55cl45f9ed3ea564c846@mail.gmail.com>
References: <1224887535.03.0.272495603252.issue4199@psf.upfronthosting.co.za>
	<1228588118.18.0.731519728687.issue4199@psf.upfronthosting.co.za>
	<e8bf7a531002231541p2e4cb55cl45f9ed3ea564c846@mail.gmail.com>
Message-ID: <e8bf7a531002231550t218d1dcco299acc0704cc4b1e@mail.gmail.com>

I also notice that the Grammar in the PEP is more complicated:
nonlocal_stmt ::=
    "nonlocal" identifier ("," identifier)*
               ["=" (target_list "=")+ expression_list]
  | "nonlocal" identifier augop expression_list

The Grammar in the patch is:
+global_stmt: 'global' NAME (',' NAME)* [','] ['=' testlist]
+nonlocal_stmt: 'nonlocal' NAME (',' NAME)* [','] ['=' testlist]

It appears that the PEP is trying to support:

nonlocal x = y = z = 1
nonlocal a, b = c, d = 1

If we're going to support the PEP as written, I think we need to
modify Global() and Nonlocal() to look exactly like Assign(), but add
an extra check to verify that all of the expressions in the targets
are Name, List, or Tuple.  You'd probably want to check this at the
time you are generating the AST, so that you're not stuck with some
extra state in the compiler traversal about whether you are generating
code for a Global() or an Assign().

This approach makes the compiler code very simple.  We use exactly the
same code for Global(), Nonlocal(), and Assign().  It does have the
downside that you need to enforce this unwritten constraint of the AST
in ast.c and in the ast module.

It also means that the AST will change in a non-backwards compatible
way.  I don't see how to do that given that we're also changing the
language spec.  (Do you want to include the spec change in your
patch?)

Jeremy

On Tue, Feb 23, 2010 at 6:41 PM, Jeremy Hylton <jeremy at alum.mit.edu> wrote:
> On Sat, Dec 6, 2008 at 1:28 PM, Benjamin Peterson
> <report at bugs.python.org> wrote:
>>
>> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>>
>> I think I may have been merging add_ast_fields when I wrote the patch.
>>
>> Here's a new patch that handles "global x, = (5,)". To do it, I added a
>> new flag* to the Global and Nonlocal AST objects that indicates whether
>> the value needs to be unpacked or not.
>
> You shouldn't need to do this. ?The unpack is implied if the number of
> identifiers is greater than 1.
>
> Jeremy
>
>
>
>> * The flag is an int. The bool AST type was removed in py3k.
>>
>> Added file: http://bugs.python.org/file12254/global_nonlocal_shorthand2.patch
>>
>> _______________________________________
>> Python tracker <report at bugs.python.org>
>> <http://bugs.python.org/issue4199>
>> _______________________________________
>> _______________________________________________
>> Python-bugs-list mailing list
>> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>>
>>
>

From report at bugs.python.org  Wed Feb 24 00:50:09 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Tue, 23 Feb 2010 23:50:09 +0000
Subject: [issue4199] add shorthand global and nonlocal statements
In-Reply-To: <e8bf7a531002231541p2e4cb55cl45f9ed3ea564c846@mail.gmail.com>
Message-ID: <e8bf7a531002231550t218d1dcco299acc0704cc4b1e@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

I also notice that the Grammar in the PEP is more complicated:
nonlocal_stmt ::=
    "nonlocal" identifier ("," identifier)*
               ["=" (target_list "=")+ expression_list]
  | "nonlocal" identifier augop expression_list

The Grammar in the patch is:
+global_stmt: 'global' NAME (',' NAME)* [','] ['=' testlist]
+nonlocal_stmt: 'nonlocal' NAME (',' NAME)* [','] ['=' testlist]

It appears that the PEP is trying to support:

nonlocal x = y = z = 1
nonlocal a, b = c, d = 1

If we're going to support the PEP as written, I think we need to
modify Global() and Nonlocal() to look exactly like Assign(), but add
an extra check to verify that all of the expressions in the targets
are Name, List, or Tuple.  You'd probably want to check this at the
time you are generating the AST, so that you're not stuck with some
extra state in the compiler traversal about whether you are generating
code for a Global() or an Assign().

This approach makes the compiler code very simple.  We use exactly the
same code for Global(), Nonlocal(), and Assign().  It does have the
downside that you need to enforce this unwritten constraint of the AST
in ast.c and in the ast module.

It also means that the AST will change in a non-backwards compatible
way.  I don't see how to do that given that we're also changing the
language spec.  (Do you want to include the spec change in your
patch?)

Jeremy

On Tue, Feb 23, 2010 at 6:41 PM, Jeremy Hylton <jeremy at alum.mit.edu> wrote:
> On Sat, Dec 6, 2008 at 1:28 PM, Benjamin Peterson
> <report at bugs.python.org> wrote:
>>
>> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>>
>> I think I may have been merging add_ast_fields when I wrote the patch.
>>
>> Here's a new patch that handles "global x, = (5,)". To do it, I added a
>> new flag* to the Global and Nonlocal AST objects that indicates whether
>> the value needs to be unpacked or not.
>
> You shouldn't need to do this. ?The unpack is implied if the number of
> identifiers is greater than 1.
>
> Jeremy
>
>
>
>> * The flag is an int. The bool AST type was removed in py3k.
>>
>> Added file: http://bugs.python.org/file12254/global_nonlocal_shorthand2.patch
>>
>> _______________________________________
>> Python tracker <report at bugs.python.org>
>> <http://bugs.python.org/issue4199>
>> _______________________________________
>> _______________________________________________
>> Python-bugs-list mailing list
>> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>>
>>
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4199>
_______________________________________

From report at bugs.python.org  Wed Feb 24 01:39:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Feb 2010 00:39:09 +0000
Subject: [issue8004] add small program to serve docs
In-Reply-To: <1266960126.19.0.905943018148.issue8004@psf.upfronthosting.co.za>
Message-ID: <1266971949.16.0.0617155970085.issue8004@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Georg: could we also add a targets in the Docs Makefile and make.bat to fire up the script?

----------
resolution:  -> accepted
versions: +Python 3.2

_______________________________________
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: [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 02:30:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Feb 2010 01:30:15 +0000
Subject: [issue8007] conhost.exe crashes when pasting 230 characters into
	python
In-Reply-To: <1266974597.6.0.639203486875.issue8007@psf.upfronthosting.co.za>
Message-ID: <1266975015.97.0.175315539915.issue8007@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority:  -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8007>
_______________________________________

From report at bugs.python.org  Wed Feb 24 02:35:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Feb 2010 01:35:28 +0000
Subject: [issue8008] Allow Arbitrary OpenID providers in this bug tracker
In-Reply-To: <1266975080.64.0.184053861131.issue8008@psf.upfronthosting.co.za>
Message-ID: <1266975328.61.0.239437544269.issue8008@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Looking at the interface I assumed that any openid provider was supported.  Did you try an alternate one and it didn't work?  I'm using an id hosted on my own server (albeit delegating to myopenid).

This bug actually belongs in the metatracker, by the way.  (Which, unfortunately, doesn't support openid, but one thing at a time :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8008>
_______________________________________

From report at bugs.python.org  Wed Feb 24 02:42:39 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 24 Feb 2010 01:42:39 +0000
Subject: [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: <1266975759.19.0.144136354928.issue7855@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Now that Dino has commit privileges and I just gave him the coordinator role, he can do the commit himself. =) Went ahead and assigned this issue to him.

And Dino, it would be helpful if you changed your username on the tracker to match your username on python-dev under "Your Details".

----------
assignee: theller -> DinoV
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7855>
_______________________________________

From report at bugs.python.org  Wed Feb 24 02:48:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Feb 2010 01:48:34 +0000
Subject: [issue6292] Fix tests to work with -OO
In-Reply-To: <1245173156.41.0.295143421803.issue6292@psf.upfronthosting.co.za>
Message-ID: <1266976114.02.0.762566954445.issue6292@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to py3k in r78400.  Had to add the make_request_and_skipIf decorator to test_xmplrc as well.

----------
priority:  -> normal
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6292>
_______________________________________

From report at bugs.python.org  Wed Feb 24 03:02:49 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Feb 2010 02:02:49 +0000
Subject: [issue8008] Allow Arbitrary OpenID providers in this bug tracker
In-Reply-To: <1266975080.64.0.184053861131.issue8008@psf.upfronthosting.co.za>
Message-ID: <1266976969.5.0.86421922067.issue8008@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, 'we' and 'they' are pretty much the same team.  If you want to enhance the openid support that Martin added to the tracker, you can submit a patch against the code in the repository.

----------
priority:  -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8008>
_______________________________________

From report at bugs.python.org  Wed Feb 24 03:13:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Feb 2010 02:13:34 +0000
Subject: [issue6292] Fix tests to work with -OO
In-Reply-To: <1245173156.41.0.295143421803.issue6292@psf.upfronthosting.co.za>
Message-ID: <1266977614.99.0.945046648055.issue6292@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Benjamin pointed out that the primary copy of lib2to3 is not trunk, so I backed out the change to that package.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6292>
_______________________________________

From report at bugs.python.org  Wed Feb 24 03:24:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 24 Feb 2010 02:24:56 +0000
Subject: [issue7736] os.listdir hangs since opendir() and closedir() do
	not	release GIL
In-Reply-To: <1263857051.12.0.865802433911.issue7736@psf.upfronthosting.co.za>
Message-ID: <1266978296.19.0.88415967057.issue7736@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Another "+1" on the patch if it is needed.  Posix module consistently releases the GIL while making system calls and this is a good idea independent of this particular issue.

Looking at the patch made me wonder whether existing

                Py_BEGIN_ALLOW_THREADS
                ep = readdir(dirp);
                Py_END_ALLOW_THREADS

is safe.  Apparently it is safe as was explained in

http://mail.python.org/pipermail/python-dev/2006-April/063808.html

because "The pointer returned by readdir() points to data which may be overwritten by another call to readdir() on the same directory stream. This data is not overwritten by another call to readdir() on a different directory stream."

It may be appropriate to add a comment near the readdir() explaining why it is safe in this context.  Clearly I am not the only one who found this non-obvious.

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7736>
_______________________________________

From report at bugs.python.org  Wed Feb 24 03:38:30 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Feb 2010 02:38:30 +0000
Subject: [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: <1266979110.9.0.958259890605.issue7975@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to trunk in r78412 and 2.6 in r78413.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7975>
_______________________________________

From report at bugs.python.org  Wed Feb 24 04:39:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 24 Feb 2010 03:39:43 +0000
Subject: [issue8007] conhost.exe crashes when pasting 230 characters into
	python
In-Reply-To: <1266974597.6.0.639203486875.issue8007@psf.upfronthosting.co.za>
Message-ID: <1266982783.35.0.818275299837.issue8007@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'm not able to reproduce this any of the python.org installers, or the current trunk. I am running 64-bit Windows 7, though, whereas you are running 32-bit. I don't imagine there should be a difference, but I'll try to obtain a 32-bit box and see if I can catch this.

It would appear based on what you say that you have a fairly fresh installation. Have you done any customization to the theme or anything relating to the command window? conhost.exe apparently hosts the command window to fully support themes and drag-and-drop in a secure method, although maybe it's not so secure in your case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8007>
_______________________________________

From report at bugs.python.org  Wed Feb 24 05:02:04 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 24 Feb 2010 04:02:04 +0000
Subject: [issue7733] asyncore docs reference is unclear
In-Reply-To: <1263817956.14.0.104959185051.issue7733@psf.upfronthosting.co.za>
Message-ID: <1266984124.47.0.68782790809.issue7733@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Fixed in r78415.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7733>
_______________________________________

From report at bugs.python.org  Wed Feb 24 05:11:26 2010
From: report at bugs.python.org (Leo Shklovskii)
Date: Wed, 24 Feb 2010 04:11:26 +0000
Subject: [issue8007] conhost.exe crashes when pasting 230 characters into
	python
In-Reply-To: <1266974597.6.0.639203486875.issue8007@psf.upfronthosting.co.za>
Message-ID: <1266984686.97.0.778989143584.issue8007@psf.upfronthosting.co.za>


Leo Shklovskii <leos at thermopylae.net> added the comment:

The only serious tweaking I've done has been to disable cleartype and completely remove Segoe UI. Adobe Photoshop didn't react nicely to that; it is possible that there's something in conhost that's hardcoded to Segoe as well.

I'm not seeing this behavior on my desktop (everything pastes in cleanly) so I'm starting to dig in and figure out what the diffs are in my two setups. 

Is there a debug build of python for windows available or some other way to trace this crash?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8007>
_______________________________________

From report at bugs.python.org  Wed Feb 24 05:41:30 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 24 Feb 2010 04:41:30 +0000
Subject: [issue8007] conhost.exe crashes when pasting 230 characters into
	python
In-Reply-To: <1266974597.6.0.639203486875.issue8007@psf.upfronthosting.co.za>
Message-ID: <1266986490.9.0.193757500321.issue8007@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I did both of those things and I'm still not able to reproduce it. Do you have any specific language settings enabled? 

One thing I meant to ask in my last message was if you had a copy of what you tried to paste into the window. I've pasted a 500 character string of "a" repeated, and 500 of "?" in case this was a Unicode issue. Neither caused a problem.

As for a debug build, we don't provide one anywhere. If you are interested in creating a debug build, http://www.python.org/dev/faq/ has instructions for downloading the source so you could make your own.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8007>
_______________________________________

From report at bugs.python.org  Wed Feb 24 06:03:51 2010
From: report at bugs.python.org (Leo Shklovskii)
Date: Wed, 24 Feb 2010 05:03:51 +0000
Subject: [issue8007] conhost.exe crashes when pasting 230 characters into
	python
In-Reply-To: <1266974597.6.0.639203486875.issue8007@psf.upfronthosting.co.za>
Message-ID: <1266987831.99.0.335565992995.issue8007@psf.upfronthosting.co.za>


Leo Shklovskii <leos at thermopylae.net> added the comment:

I've downloaded the source and created a debug build. I can't reproduce the issue on the debug build (although a bunch of binary dependencies failed since I don't have sources for them).

The string I'm pasting in is:

['01776', '02210', '02468', '02482', '02719', '03782', '03842', '04849', '05641', '05673', '06001', '06460', '06722', '06804', '06907', '07076', '07405', '07718', '08081', '10018', '10523', '10708', '10916', '11385', '14475', '14532']

So no fancy unicode or anything else.

I'm running US English. I'm going to pull down a fresh install of python and try to re-install modules until I can repro this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8007>
_______________________________________

From report at bugs.python.org  Wed Feb 24 06:27:39 2010
From: report at bugs.python.org (Meador Inge)
Date: Wed, 24 Feb 2010 05:27:39 +0000
Subject: [issue7902] relative import broken
In-Reply-To: <1265828963.53.0.5315107426.issue7902@psf.upfronthosting.co.za>
Message-ID: <1266989259.23.0.209426460271.issue7902@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> So doing the import manually through __import__('os', globals(), 
> locals(), ['walk'], 1) does not work. 

I get the same behavior for this reproduction case regardless of whether I use:
   import .os import walk
or:
   __import__('os', globals(), locals(), ['walk'], 1)
The bug is reproducible in the trunk.

I think the problem has to do with 'import_module_level' incorrectly doing an absolute lookup for 'os' when the relative lookup in 'foo' fails.  I have attached a patch with the relevant fix and test case.

----------
keywords: +patch
nosy: +minge
Added file: http://bugs.python.org/file16350/issue-7902.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7902>
_______________________________________

From report at bugs.python.org  Wed Feb 24 06:29:16 2010
From: report at bugs.python.org (Leo Shklovskii)
Date: Wed, 24 Feb 2010 05:29:16 +0000
Subject: [issue8007] conhost.exe crashes when pasting 230 characters into
	python
In-Reply-To: <1266974597.6.0.639203486875.issue8007@psf.upfronthosting.co.za>
Message-ID: <1266989356.9.0.6125657595.issue8007@psf.upfronthosting.co.za>


Leo Shklovskii <leos at thermopylae.net> added the comment:

Ok, I've traced this down to the pyreadline package. Specifically 1.5 - http://pypi.python.org/pypi/pyreadline/1.5 - I really appreciate your help Brian and I'm sorry to have wasted your time. I'm filing a bug with the pyreadline developer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8007>
_______________________________________

From report at bugs.python.org  Wed Feb 24 07:30:20 2010
From: report at bugs.python.org (Meador Inge)
Date: Wed, 24 Feb 2010 06:30:20 +0000
Subject: [issue7958] test_platform failure on OS X 10.6
In-Reply-To: <1266506997.43.0.181933833727.issue7958@psf.upfronthosting.co.za>
Message-ID: <1266993020.26.0.898258026274.issue7958@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I am seeing the same problem with 32-bit on OS X 10.5:

euclid:trunk minge$ ./python.exe Lib/test/regrtest.py -uall test_platform
test_platform
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/minge/Work/Languages/python/trunk/Lib/platform.py", line 1017, in architecture
    import struct
  File "/Users/minge/Work/Languages/python/trunk/Lib/struct.py", line 1, in <module>
    from _struct import *
ImportError: No module named _struct
test test_platform failed -- Traceback (most recent call last):
  File "/Users/minge/Work/Languages/python/trunk/Lib/test/test_platform.py", line 24, in test_architecture_via_symlink
    self.assertEqual(get(real), get(link))
AssertionError: Tuples differ: ("('32bit', '')\n", None) != ('', None)

First differing element 0:
('32bit', '')



- ("('32bit', '')\n", None)
+ ('', None)

1 test failed:
    test_platform


The proposed patch seems reasonable.  I verified that it fixed the problem for 10.5.

----------
nosy: +minge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7958>
_______________________________________

From report at bugs.python.org  Wed Feb 24 08:09:17 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 24 Feb 2010 07:09:17 +0000
Subject: [issue7958] test_platform failure on OS X 10.6
In-Reply-To: <1266506997.43.0.181933833727.issue7958@psf.upfronthosting.co.za>
Message-ID: <1266995357.5.0.0998390745807.issue7958@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'd expect more failures, the failure is caused by the way the sysconfig module calculates the root of the installation, and whether or not it is running in the source tree.

Tarek: could you please review sysconfig.patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7958>
_______________________________________

From report at bugs.python.org  Wed Feb 24 09:15:42 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 24 Feb 2010 08:15:42 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1266999342.42.0.873236815287.issue7649@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

> --- python/trunk/Objects/unicodeobject.c	(original)
> > +++ python/trunk/Objects/unicodeobject.c	Wed Feb 24 00:16:07 2010
> > @@ -8170,6 +8170,7 @@
> >             size_t buflen,
> >             PyObject *v)
> >  {
> > +    PyObject *s;
> >      /* presume that the buffer is at least 2 characters long */
> >      if (PyUnicode_Check(v)) {
> >          if (PyUnicode_GET_SIZE(v) != 1)
> > @@ -8180,7 +8181,14 @@
> >      else if (PyString_Check(v)) {
> >          if (PyString_GET_SIZE(v) != 1)
> >              goto onError;
> > -        buf[0] = (Py_UNICODE)PyString_AS_STRING(v)[0];
> > +        /* #7649: if the char is a non-ascii (i.e. in range(0x80,0x100)) byte
> > +           string, "u'%c' % char" should fail with a UnicodeDecodeError */
> > +        s = PyUnicode_FromStringAndSize(PyString_AS_STRING(v), 1);
> > +        /* if the char is not decodable return -1 */
> > +        if (s == NULL)
> > +            return -1;
> > +        buf[0] = PyUnicode_AS_UNICODE(s)[0];
> > +        Py_DECREF(s);

That's a *very* inefficient way of doing this.

Could you please check for chars above 0x7f first and then use
PyUnicode_Decode() instead of the PyUnicode_FromStringAndSize()
API (this API should not have been backported from the Python 3.x
in Python 2.6, but it's too late to change that now) !

Thanks.

----------
nosy: +lemburg
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Wed Feb 24 10:02:21 2010
From: report at bugs.python.org (=?utf-8?q?M=C3=A1rcio_Faustino?=)
Date: Wed, 24 Feb 2010 09:02:21 +0000
Subject: [issue1441530] socket read() can cause MemoryError in Windows
Message-ID: <1267002141.91.0.77011318824.issue1441530@psf.upfronthosting.co.za>


M?rcio Faustino <m.faustino at gmail.com> added the comment:

I've been also receiving the same error while using "imaplib.IMAP4_SSL" to download large e-mails.

A simple change in the "read" and "readline" functions to use instead a "cStringIO.StringIO" buffer object works for me.

----------
nosy: +marcio

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1441530>
_______________________________________

From report at bugs.python.org  Wed Feb 24 10:03:11 2010
From: report at bugs.python.org (Francesco Del Degan)
Date: Wed, 24 Feb 2010 09:03:11 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1267002191.21.0.175762359909.issue6280@psf.upfronthosting.co.za>


Francesco Del Degan <f.deldegan at ngi.it> added the comment:

Those are the new updated patches with ifdef wrapped timegm function, docs, and a conversion test.

----------
Added file: http://bugs.python.org/file16351/timemodule-gmtime-2-trunk.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Wed Feb 24 10:20:22 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 24 Feb 2010 09:20:22 +0000
Subject: [issue4199] add shorthand global and nonlocal statements
In-Reply-To: <1224887535.03.0.272495603252.issue4199@psf.upfronthosting.co.za>
Message-ID: <1267003222.86.0.168467727851.issue4199@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> I also notice that the Grammar in the PEP is more complicated:
> nonlocal_stmt ::=
>     "nonlocal" identifier ("," identifier)*
>                ["=" (target_list "=")+ expression_list]
>   | "nonlocal" identifier augop expression_list
> 
> The Grammar in the patch is:
> +global_stmt: 'global' NAME (',' NAME)* [','] ['=' testlist]
> +nonlocal_stmt: 'nonlocal' NAME (',' NAME)* [','] ['=' testlist]
> 
> It appears that the PEP is trying to support:
> 
> nonlocal x = y = z = 1
> nonlocal a, b = c, d = 1

It also tries to support augmented assignment; however I'm not sure what the semantics of that should be.

Further, there is an ambiguity if too much freedom is allowed: what about

   global x = 1, y

Is it declaring a global "x" and assigning a tuple, or declaring a global "x" and a global "y"?

> If we're going to support the PEP as written, I think we need to
> modify Global() and Nonlocal() to look exactly like Assign(), but add
> an extra check to verify that all of the expressions in the targets
> are Name, List, or Tuple.  You'd probably want to check this at the
> time you are generating the AST, so that you're not stuck with some
> extra state in the compiler traversal about whether you are generating
> code for a Global() or an Assign().

I would not support List or Tuple as targets.  Same basic problem as 
above, and I don't see a use case.

I see two possibilities for the actual syntax:

1) global *either* supports multiple identifiers, *or* one identifier 
and an assignment.

2) global always supports multiple identifiers, each with an optional 
assignment; tuples need parentheses.

In both cases, I would keep it simple and not allow multiple targets or 
augmented assignment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4199>
_______________________________________

From report at bugs.python.org  Wed Feb 24 10:24:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 24 Feb 2010 09:24:48 +0000
Subject: [issue8004] add small program to serve docs
In-Reply-To: <1266960126.19.0.905943018148.issue8004@psf.upfronthosting.co.za>
Message-ID: <1267003488.28.0.377408931589.issue8004@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Indeed, I forgot the hard-coded path has been removed, and didn?t notice the makefile was in Doc. Perfect then, and thanks for pointing these things to my sleepy self :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8004>
_______________________________________

From report at bugs.python.org  Wed Feb 24 10:44:02 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 24 Feb 2010 09:44:02 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1267004642.18.0.456785037879.issue7649@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Could you please check for chars above 0x7f first and then use
> PyUnicode_Decode() instead of the PyUnicode_FromStringAndSize() API

I concur: PyUnicode_FromStringAndSize() decodes with utf-8 whereas the expected conversion char->unicode should use the default encoding (ascii).
But why is it necessary to check for chars above 0x7f?

> (this API should not have been backported from the Python 3.x
> in Python 2.6,
This function is still useful when the chars come from a C string literal in the source code (btw there should be something about the encoding used in C files). But it's not always correctly used even in 3.x, in posixmodule.c for example.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

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: [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 11:02:43 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 24 Feb 2010 10:02:43 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1267004642.18.0.456785037879.issue7649@psf.upfronthosting.co.za>
Message-ID: <4B84F940.40800@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
>> Could you please check for chars above 0x7f first and then use
>> PyUnicode_Decode() instead of the PyUnicode_FromStringAndSize() API
> 
> I concur: PyUnicode_FromStringAndSize() decodes with utf-8 whereas the expected conversion char->unicode should use the default encoding (ascii).
> But why is it necessary to check for chars above 0x7f?

The Python default encoding has to be ASCII compatible,
so it's better to use a short-cut for pure-ASCII characters
and avoid the complete round-trip via a temporary Unicode
object.

>> (this API should not have been backported from the Python 3.x
>> in Python 2.6,
> This function is still useful when the chars come from a C string literal in the source code (btw there should be something about the encoding used in C files). But it's not always correctly used even in 3.x, in posixmodule.c for example.

The function is a really just yet another interface to the
PyUnicode_DecodeUTF8() API and it's name is misleading in that:

Python 2.x uses the default encoding for converting strings without
known encoding to Unicode, the docs for the API say that
it decodes Latin-1 (!) and the interface makes it looks like
a drop-in replacement for PyString_FromStringAndSize() which
it isn't for Python 2.x.

For Python 3.x, the default encoding is fixed to UTF-8, so the
situation is different (though the docs are still wrong),
however I don't see the advantage of using a less explicit
name over the direct use of PyUnicode_DecodeUTF8().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Wed Feb 24 11:39:34 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 24 Feb 2010 10:39:34 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1267007974.74.0.393146059765.issue7649@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> > But why is it necessary to check for chars above 0x7f?
> The Python default encoding has to be ASCII compatible,
Yes, but it is not necessarily as strict.
for example, after I manage to set the default encoding to latin-1,
u"%s" % chr(0x80) works; I suppose %c should do the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Wed Feb 24 11:50:16 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 24 Feb 2010 10:50:16 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1267007974.74.0.393146059765.issue7649@psf.upfronthosting.co.za>
Message-ID: <4B850466.6070002@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
>>> But why is it necessary to check for chars above 0x7f?
>> The Python default encoding has to be ASCII compatible,
> Yes, but it is not necessarily as strict.
> for example, after I manage to set the default encoding to latin-1,
> u"%s" % chr(0x80) works; I suppose %c should do the same.

Right and it will.

I only meant the check as fast-path for characters <0x80. All
other characters would need to go through PyUnicode_Decode().

We can use such a fast-path, since the default encoding has to
be ASCII compatible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Wed Feb 24 11:59:34 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 24 Feb 2010 10:59:34 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1267009174.86.0.538566871818.issue7649@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I was trying to decode mainly to get a UnicodeDecodeError automatically.
If I check if the char is not in the ASCII range (i.e. >0x7F) I think I'd have to set the error message for the UnicodeDecodeError manually and possibly duplicate it (unless we use a different error message that says that %c accepts only ASCII chars).
Also I agree that if u'%s' % chr(0x80) works when the default encoding is not ASCII, then %c should work as well. Trying to decode it with the default encoding and possibly let the UnicodeDecodeError propagate seems a good solution to me (and performance shouldn't be a problem here, since apparently no one uses u'%c' with non-ASCII byte strings).
I will try to make another patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Wed Feb 24 12:03:13 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 24 Feb 2010 11:03:13 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1267009393.87.0.257726162619.issue7649@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Marc-Andr?'s remark was that if char<0x80 (the vast majority), it's not necessary to call any decode function: just copy the byte. Other cases (error, or non-default encoding) may use a slower path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Wed Feb 24 12:07:08 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 24 Feb 2010 11:07:08 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1267009628.5.0.0988861245153.issue7649@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Ok, adding a fast path shouldn't make the code more complicated, so I'll include it in the patch, thanks for the feedback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Wed Feb 24 12:17:52 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 24 Feb 2010 11:17:52 +0000
Subject: [issue5965] Format Specs: doc 's' and implicit conversions
In-Reply-To: <1241746292.05.0.923233033791.issue5965@psf.upfronthosting.co.za>
Message-ID: <1267010272.13.0.7486711873.issue5965@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I think the only remaining issue here is that 's' isn't documented. The exceptions are now more meaningful, and commas have been documented.

----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5965>
_______________________________________

From report at bugs.python.org  Wed Feb 24 12:21:41 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 24 Feb 2010 11:21:41 +0000
Subject: [issue7958] test_platform failure on OS X 10.6
In-Reply-To: <1266506997.43.0.181933833727.issue7958@psf.upfronthosting.co.za>
Message-ID: <1267010501.64.0.53446612457.issue7958@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Looking at the code, the whole approach to finding the project base appears to be very fragile.

I'd suggest to use a landmark file for finding the project base, say "Modules/main.c", and a function which searches all directories on the os.path.realpath(sys.executable) for this landmark file in order to determine the correct project directory (or none in case Python was not called from a Python build binary).

The special cases for PC builds could then be removed.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7958>
_______________________________________

From report at bugs.python.org  Wed Feb 24 14:02:03 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 24 Feb 2010 13:02:03 +0000
Subject: [issue5965] Format Specs: doc 's' and implicit conversions
In-Reply-To: <1241746292.05.0.923233033791.issue5965@psf.upfronthosting.co.za>
Message-ID: <1267016523.51.0.734220696329.issue5965@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Here's my proposed changes. Please review.

I put the string type 's' into its own table. That's probably overkill, but I think it gets lost if it's just mentioned in the text. Feel free to change that, though.

Also, I'm not wild about my wording for the int->float conversions. But I think it needs to go near the int presentation types, not at the end of the section. I'd actually prefer it at the top of the int table, but I couldn't find a way of working it in.

----------
keywords: +needs review, patch
priority:  -> normal
stage:  -> patch review
Added file: http://bugs.python.org/file16356/issue5965.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5965>
_______________________________________

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: [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 16:22:05 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Wed, 24 Feb 2010 15:22:05 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <1267021686.23.0.555916677379.issue7309@psf.upfronthosting.co.za>
Message-ID: <4B854416.9030109@livinglogic.de>


Walter D?rwald <walter at livinglogic.de> added the comment:

On 24.02.10 15:28, Eric Smith wrote:

> Eric Smith <eric at trueblade.com> added the comment:
> 
> Fixed:
> 
> trunk: r78418
> release26-maint: r78419
> 
> Still working on porting to py3k and release31-maint.

A much better solution would IMHO be to forbid setting the encoding,
object and reason attributes to objects of the wrong type in the first
place. Unfortunately this would require an extension to PyMemberDef for
the T_OBJECT and T_OBJECT_EX types.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7309>
_______________________________________

From report at bugs.python.org  Wed Feb 24 16:24:40 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 24 Feb 2010 15:24:40 +0000
Subject: [issue7309] crasher in str(Exception())
In-Reply-To: <4B854416.9030109@livinglogic.de>
Message-ID: <4B8544B3.2020109@trueblade.com>


Eric Smith <eric at trueblade.com> added the comment:

> A much better solution would IMHO be to forbid setting the encoding,
> object and reason attributes to objects of the wrong type in the first
> place. Unfortunately this would require an extension to PyMemberDef for
> the T_OBJECT and T_OBJECT_EX types.

Agreed that's a better approach. But I wanted to get the fix in for 2.6 
and 3.1.

You can open another issue if you'd like. I'm going to close this one as 
soon as I get the crash fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7309>
_______________________________________

From report at bugs.python.org  Wed Feb 24 16:56:02 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 24 Feb 2010 15:56:02 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1266974606.92.0.377026806088.issue4111@psf.upfronthosting.co.za>
Message-ID: <19333.17122.521846.880504@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Jesus> can I ask if this (very useful) feature is on time for Python 2.7?

You can ask, but I suspect you'd be disappointed in the answer.  Do you have
time to look at the issue?  The biggest sticking point in my mind is coming
up with a uniform set of probes which would be supported by both Sun and
Apple.

Skip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Wed Feb 24 17:24:55 2010
From: report at bugs.python.org (Jeremy Hylton)
Date: Wed, 24 Feb 2010 16:24:55 +0000
Subject: [issue4199] add shorthand global and nonlocal statements
In-Reply-To: <1267003222.86.0.168467727851.issue4199@psf.upfronthosting.co.za>
Message-ID: <e8bf7a531002240824i7718b3e7m1973125577064022@mail.gmail.com>


Jeremy Hylton <jeremy at alum.mit.edu> added the comment:

I guess there's some question about whether the syntax in the PEP was
considered carefully when it was approved.  If so, I'm not sure that
we want to re-open the discussion.  On the other hand, it's been a
long time since the PEP was approved and we do have a moratorium on
language changes, so it doesn't hurt to slow things down.

I'd argue that the intent of the PEP is pretty clear.  You can take
any assignment statement where the LHS doesn't have subscripts, put a
nonlocal or global in front of it, and it means that all those
assignments are to global/nonlocal variables.

Jeremy

On Wed, Feb 24, 2010 at 4:20 AM, Georg Brandl <report at bugs.python.org> wrote:
>
> Georg Brandl <georg at python.org> added the comment:
>
>> I also notice that the Grammar in the PEP is more complicated:
>> nonlocal_stmt ::=
>> ? ? "nonlocal" identifier ("," identifier)*
>> ? ? ? ? ? ? ? ?["=" (target_list "=")+ expression_list]
>> ? | "nonlocal" identifier augop expression_list
>>
>> The Grammar in the patch is:
>> +global_stmt: 'global' NAME (',' NAME)* [','] ['=' testlist]
>> +nonlocal_stmt: 'nonlocal' NAME (',' NAME)* [','] ['=' testlist]
>>
>> It appears that the PEP is trying to support:
>>
>> nonlocal x = y = z = 1
>> nonlocal a, b = c, d = 1
>
> It also tries to support augmented assignment; however I'm not sure what the semantics of that should be.
>
> Further, there is an ambiguity if too much freedom is allowed: what about
>
> ? global x = 1, y
>
> Is it declaring a global "x" and assigning a tuple, or declaring a global "x" and a global "y"?
>
>> If we're going to support the PEP as written, I think we need to
>> modify Global() and Nonlocal() to look exactly like Assign(), but add
>> an extra check to verify that all of the expressions in the targets
>> are Name, List, or Tuple. ?You'd probably want to check this at the
>> time you are generating the AST, so that you're not stuck with some
>> extra state in the compiler traversal about whether you are generating
>> code for a Global() or an Assign().
>
> I would not support List or Tuple as targets. ?Same basic problem as
> above, and I don't see a use case.
>
> I see two possibilities for the actual syntax:
>
> 1) global *either* supports multiple identifiers, *or* one identifier
> and an assignment.
>
> 2) global always supports multiple identifiers, each with an optional
> assignment; tuples need parentheses.
>
> In both cases, I would keep it simple and not allow multiple targets or
> augmented assignment.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue4199>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4199>
_______________________________________

From report at bugs.python.org  Wed Feb 24 18:17:15 2010
From: report at bugs.python.org (Wilfredo Sanchez)
Date: Wed, 24 Feb 2010 17:17:15 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1267031835.35.0.12045753632.issue8013@psf.upfronthosting.co.za>


Wilfredo Sanchez <wsanchez at wsanchez.net> added the comment:

I get this on Python 2.6, not 2.5.

And it seems to be limited to 64-bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8013>
_______________________________________

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: [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:21:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 24 Feb 2010 17:21:12 +0000
Subject: [issue6280] calendar.timegm() belongs in time module,
	next to time.gmtime()
In-Reply-To: <1244911683.12.0.112588761912.issue6280@psf.upfronthosting.co.za>
Message-ID: <1267032072.23.0.715042991439.issue6280@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Looks good. 

A documentation typo:

 gmtime() -- convert seconds since Epoch to UTC tuple\n\
+timegm() - Convert a UTC tuple to seconds since the Epoch.\n\

Note the use of -- in the existing items.

I understand that the choice of float for return value is dictated by consistency with mktime, but I question the wisdom of returning float instead of int from mktime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Wed Feb 24 18:45:01 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 24 Feb 2010 17:45:01 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1267033501.34.0.255220137437.issue7900@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I still think that the sysconf version should be the correct one. If OSX fails to work correctly under that version, and causes Python to raise an exception - then that's a platform bug, and should only accept minimal work arounds.

So I propose to close this as "won't fix". Or, the original issue could be resolved by accepting EINVAL on OSX as a correct result of getgroups in the test suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Wed Feb 24 18:50:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 24 Feb 2010 17:50:59 +0000
Subject: [issue8013] time.asctime segfaults when given a time in the far future
In-Reply-To: <1267031714.43.0.416052646257.issue8013@psf.upfronthosting.co.za>
Message-ID: <1267033859.81.0.632419435791.issue8013@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Looks like a case of missing null check.  Patch attached.

----------
keywords: +patch
nosy: +Alexander.Belopolsky
Added file: http://bugs.python.org/file16359/issue8013.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8013>
_______________________________________

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: [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  Wed Feb 24 19:02:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 24 Feb 2010 18:02:52 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1267033501.34.0.255220137437.issue7900@psf.upfronthosting.co.za>
Message-ID: <d38f5331002241002y7280fd70o90970eede81e0d2c@mail.gmail.com>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

On Wed, Feb 24, 2010 at 12:45 PM, Martin v. L?wis
<report at bugs.python.org> wrote:
..
> I still think that the sysconf version should be the correct one. If OSX fails to work correctly under
> that version, and causes Python to raise an exception - then that's a platform bug, and should only > accept minimal work arounds.
>

It is more than an exception.  In python 2.6+, os.getgroups() returns
wrong results.  It always reads system database instead of returning
the values that are set with os.setgroups().

> So I propose to close this as "won't fix". Or, the original issue could be resolved by accepting
> EINVAL on OSX as a correct result of getgroups in the test suite.
>

Supporting more than 16 groups is less important (and impossible
without a platform fix) than to have working get/setgroups for
reasonable number of groups.  This is how python behaved before
r63955.

At the very least unit tests that I submitted could be accepted
possibly with a skip on OSX if fixing the bug is not an option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Wed Feb 24 19:03:07 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 24 Feb 2010 18:03:07 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1267034587.23.0.372382539097.issue7649@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'm working on a similar issue for int.__format__('c'). What's not clear to me is why this doesn't work the same as chr(i).  That is, shouldn't chr(i) == ('%c' % i) hold for i in range(256)? And if that's so, why not just copy chr's implementation:
	if (x < 0 || x >= 256) {
		PyErr_SetString(PyExc_ValueError,
				"chr() arg not in range(256)");
		return NULL;
	}
	s[0] = (char)x;
	return PyString_FromStringAndSize(s, 1);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Wed Feb 24 19:11:14 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 24 Feb 2010 18:11:14 +0000
Subject: [issue5965] Format Specs: doc 's' and implicit conversions
In-Reply-To: <1241746292.05.0.923233033791.issue5965@psf.upfronthosting.co.za>
Message-ID: <1267035074.72.0.226171476279.issue5965@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

That looks good. I tweaked it a little and fixed a few other problems with the patch. New patch attached.

----------
Added file: http://bugs.python.org/file16360/issue5965-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5965>
_______________________________________

From report at bugs.python.org  Wed Feb 24 19:17:58 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 24 Feb 2010 18:17:58 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1267035478.64.0.257123726316.issue7649@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Of course. Sorry about that.

But then why not copy unichr()? It calls PyUnicode_FromOrdinal.

I guess my real question is:

Should "'%c' % i" be identical to "chr(i)" and should "u'%c' % i" be identical to "unichr(i)"?

And by "identical" I mean return the same results and throw the same errors (with a possible difference in the error text).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Wed Feb 24 19:26:01 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 24 Feb 2010 18:26:01 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1267035961.19.0.098791628617.issue7649@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

At least from point of view, the difference between ints and chars is:
* "u'%c' % 0xB5" means "create a Unicode char with codepoint 0xB5", i.e. the Unicode char ? U+00B5 MICRO SIGN;
* "u'%c' % '\xB5'" means "create a Unicode char converting the byte '\xB5' to Unicode", i.e. an ? U+0415 CYRILLIC CAPITAL LETTER IE if the byte string is encoded in iso-8859-5 or ? U+0E15 THAI CHARACTER TO TAO if it's encoded in iso-8859-11, and so on for every different encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Wed Feb 24 19:47:16 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 24 Feb 2010 18:47:16 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1267037236.21.0.609156673557.issue7649@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Just to clarify:
"u'%c' % some_int" should behave like unichr(some_int);
"u'%c' % some_chr" should behave like "u'%s' % some_chr".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Wed Feb 24 21:25:02 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 24 Feb 2010 20:25:02 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1267043102.31.0.389594421089.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20100224.zip is a new version of the regex module.

It includes support for matching based on Unicode scripts as well as on Unicode blocks and properties.

----------
Added file: http://bugs.python.org/file16362/issue2636-20100224.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Feb 24 22:10:41 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 24 Feb 2010 21:10:41 +0000
Subject: [issue8014] Setting a T_INT attribute raises internal error
In-Reply-To: <1267031901.2.0.324094054626.issue8014@psf.upfronthosting.co.za>
Message-ID: <1267045841.95.0.21231667558.issue8014@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

It seems that T_INT uses PyLong_AsLong to get a integer, and 2.x uses PyInt_AsLong. PyInt_AsLong tries to convert the number to an integer, but PyLong_AsLong just throws up if the type is not correct. Mark, thoughts?

----------
nosy: +benjamin.peterson, mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8014>
_______________________________________

From report at bugs.python.org  Wed Feb 24 22:40:16 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 24 Feb 2010 21:40:16 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1267037236.21.0.609156673557.issue7649@psf.upfronthosting.co.za>
Message-ID: <4B859CBB.90405@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> Just to clarify:
> "u'%c' % some_int" should behave like unichr(some_int);
> "u'%c' % some_chr" should behave like "u'%s' % some_chr".

That's correct.

I guess that in practice "u'%c' % some_chr" is not all that common.
Otherwise, the fact that it doesn't raise an error if some_chr
is not compatible to the default encoding would have been noticed
earlier on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Wed Feb 24 22:46:43 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 24 Feb 2010 21:46:43 +0000
Subject: [issue8014] Setting a T_INT attribute raises internal error
In-Reply-To: <1267031901.2.0.324094054626.issue8014@psf.upfronthosting.co.za>
Message-ID: <1267048003.35.0.341898340678.issue8014@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Might it be T_PYSSIZET rather than T_INT?  In which case it's PyLong_AsSsize_t that's at fault:  it should raise TypeError for non-integers.  What's slightly less clear is whether PyLong_AsSsize_t should also try to call int to convert to int, as PyLong_AsLong does;  I'd say not---the PyLong_AsLong behaviour isn't particularly desirable in my view, and is mostly there for historical reasons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8014>
_______________________________________

From report at bugs.python.org  Wed Feb 24 22:57:56 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 24 Feb 2010 21:57:56 +0000
Subject: [issue8014] Setting a T_INT attribute raises internal error
In-Reply-To: <1267031901.2.0.324094054626.issue8014@psf.upfronthosting.co.za>
Message-ID: <1267048676.27.0.813909013479.issue8014@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch that raises TypeError if either PyLongAs_Size_t or PyLong_As_Ssize_t gets called with a valid non-integer PyObject *.

I'm not sure where the most appropriate place for a test is.

----------
assignee:  -> mark.dickinson
keywords: +patch
priority:  -> normal
stage:  -> test needed
Added file: http://bugs.python.org/file16363/issue8014.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8014>
_______________________________________

From report at bugs.python.org  Wed Feb 24 23:19:38 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Wed, 24 Feb 2010 22:19:38 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1267049978.79.0.0849615133356.issue3871@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

updated patch to trunk:
- apply cleanly
- support builddir <> sourcedir
- regression tests pass if run from any drive (windows hosts)

----------
Added file: http://bugs.python.org/file16364/python-trunk-20100225-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Thu Feb 25 00:14:06 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Wed, 24 Feb 2010 23:14:06 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1267053246.36.0.288002594506.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Thanks, its indeed a very nice addition to the library...
Just a marginal remark; it seems, that in script-names also some non BMP characters are covered, however, in the unicode ranges thee only BMP.
http://www.unicode.org/Public/UNIDATA/Blocks.txt

Am I missing something more complex, as why 
10000.. - ..10FFFF; ranges weren't included in _BLOCKS ?
Maybe building these ranges is expensive, in contrast to rare uses of these properties?

(Not that I am able to reliably test it on my "narrow" python build on windows, but currently, obviously, e.g. \p{InGothic} gives "undefined property name" whereas \p{Gothic} is accepted.)

vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Feb 25 00:28:41 2010
From: report at bugs.python.org (Vincent Borghi)
Date: Wed, 24 Feb 2010 23:28:41 +0000
Subject: [issue6722] collections.namedtuple: confusing example
In-Reply-To: <1250591925.23.0.269848636465.issue6722@psf.upfronthosting.co.za>
Message-ID: <1267054121.76.0.640513795777.issue6722@psf.upfronthosting.co.za>


Vincent Borghi <vincent.borghi.2 at gmail.com> added the comment:

In fact, thanks to the person (Alexey Shamrin) who created 
this issue (issue found while googling for "namedtuple"), 
I have understood the namedtuple example in the 
documentation.
I think like him the verbose=True example that cames
first is very confusing. 

(BTW I must say that the Python reference documentation is usually excellent, so my expectations are high!)

----------
nosy: +Vincent.Borghi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6722>
_______________________________________

From report at bugs.python.org  Thu Feb 25 01:05:20 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 25 Feb 2010 00:05:20 +0000
Subject: [issue8014] Setting a T_INT attribute raises internal error
In-Reply-To: <1267048676.27.0.813909013479.issue8014@psf.upfronthosting.co.za>
Message-ID: <1afaf6161002241605r5938d604n32ea97042d68dccf@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/2/24 Mark Dickinson <report at bugs.python.org>:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> Here's a patch that raises TypeError if either PyLongAs_Size_t or PyLong_As_Ssize_t gets called with a valid non-integer PyObject *.
>
> I'm not sure where the most appropriate place for a test is.

There's test_structmembers.py I think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8014>
_______________________________________

From report at bugs.python.org  Thu Feb 25 01:08:25 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 25 Feb 2010 00:08:25 +0000
Subject: [issue8011] traceback tb_lineno example needs correction for Python3
In-Reply-To: <1267020758.71.0.873581563668.issue8011@psf.upfronthosting.co.za>
Message-ID: <1267056505.68.0.236459307391.issue8011@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think this can be changed on 2.x as well, since the traceback.tb_lineno function "has no use in versions past 2.3" (so maybe it should be deprecated too, at least in the doc). Also the except should catch an IndexError.

----------
assignee: georg.brandl -> ezio.melotti
nosy: +ezio.melotti
priority:  -> normal
stage:  -> needs patch
versions: +Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8011>
_______________________________________

From report at bugs.python.org  Thu Feb 25 03:29:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 25 Feb 2010 02:29:37 +0000
Subject: [issue6247] should we include argparse
In-Reply-To: <1244529628.56.0.560843311586.issue6247@psf.upfronthosting.co.za>
Message-ID: <1267064977.27.0.312356920194.issue6247@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

PEP 389 has been accepted.

----------
components: +Library (Lib) -Extension Modules
priority:  -> normal
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6247>
_______________________________________

From report at bugs.python.org  Thu Feb 25 05:06:33 2010
From: report at bugs.python.org (Meador Inge)
Date: Thu, 25 Feb 2010 04:06:33 +0000
Subject: [issue7232] Support of 'with' statement fo TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1267070793.52.0.305264152426.issue7232@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Built on Brian's patch by adding the following items:

   * Added a unit test case to cover exceptional conditions.
   * Added doc strings on __enter__ and __exit__ (more consistent
     with the surrounding code).
   * Spelling error in doc update: s/manaager/manager/.
   * Link doc update to context manager type documentation (just in
     case the tarfile user is unfamiliar with context manager types).

----------
nosy: +minge
Added file: http://bugs.python.org/file16367/issue7232.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________

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: [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 15:21:01 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 25 Feb 2010 14:21:01 +0000
Subject: [issue5965] Format Specs: doc 's' and implicit conversions
In-Reply-To: <1241746292.05.0.923233033791.issue5965@psf.upfronthosting.co.za>
Message-ID: <1267107661.12.0.896438385696.issue5965@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Checked in.

trunk: r78440
release26-maint: r78441
py3k: r78442
release31-maint: r78443

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5965>
_______________________________________

From report at bugs.python.org  Thu Feb 25 15:46:21 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 25 Feb 2010 14:46:21 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1267109181.02.0.684765597255.issue7649@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The latest patch (issue7649v4.diff) checks if the char is ASCII or non-ASCII and then, if the char is ASCII, it converts it directly to Unicode, otherwise it tries to decode it using the default encoding, raising a UnicodeDecodeError if the decoding fails.

I tested it setting iso-8859-1 and utf-8 as default encoding and the behavior was consistent with "%s", however the tests assume that the default encoding is always ASCII, so they failed (both the tests included in the patch and others in test_unicode). I'm not sure if in this case they should be changed/skipped or not.

(Also http://docs.python.org/c-api/unicode.html#built-in-codecs says that "Setting encoding to NULL causes the default encoding to be used which is ASCII.", but this is not always true. If you think it should be fixed I'll do it in a separate commit.)

----------
stage: committed/rejected -> patch review
Added file: http://bugs.python.org/file16369/issue7649v4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Thu Feb 25 16:00:00 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 25 Feb 2010 15:00:00 +0000
Subject: [issue7928] String formatting: grammar wrongly limits [index] to
	integer
In-Reply-To: <1266146946.63.0.7361643831.issue7928@psf.upfronthosting.co.za>
Message-ID: <1267110000.6.0.826539652774.issue7928@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Checked in.

trunk: r78444
release26-maint: r78445
py3k: r78446
release31-maint: r78447

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7928>
_______________________________________

From report at bugs.python.org  Thu Feb 25 17:43:17 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 25 Feb 2010 16:43:17 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1267109181.02.0.684765597255.issue7649@psf.upfronthosting.co.za>
Message-ID: <4B86A8A2.40202@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> The latest patch (issue7649v4.diff) checks if the char is ASCII or non-ASCII and then, if the char is ASCII, it converts it directly to Unicode, otherwise it tries to decode it using the default encoding, raising a UnicodeDecodeError if the decoding fails.

Thanks. The patch looks good now... but doesn't apply cleanly anymore,
since your first version has already made it into trunk and the 2.6 branch.

> I tested it setting iso-8859-1 and utf-8 as default encoding and the behavior was consistent with "%s", however the tests assume that the default encoding is always ASCII, so they failed (both the tests included in the patch and others in test_unicode). I'm not sure if in this case they should be changed/skipped or not.

I think that's fine. While we do still allow setting the default
to something other than ASCII in 2.x, we don't support such tricks,
so there's no need to test for them.

> (Also http://docs.python.org/c-api/unicode.html#built-in-codecs says that "Setting encoding to NULL causes the default encoding to be used which is ASCII.", but this is not always true. If you think it should be fixed I'll do it in a separate commit.)

The last part of that sentence should be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Thu Feb 25 18:06:40 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 25 Feb 2010 17:06:40 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1262826480.78.0.125782142552.issue7649@psf.upfronthosting.co.za>
Message-ID: <1267117600.52.0.726155652991.issue7649@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The patch should apply cleanly on the latest revision of trunk (if you look at the diff it removes the code of the first version).

About the doc, I think it would be better to say that usually it's ASCII (or UTF-8 on Py3 -- Py3 doc should be fixed too), but it might be something different if it's changed using sys.setdefaultencoding().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

From report at bugs.python.org  Thu Feb 25 18:13:30 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 25 Feb 2010 17:13:30 +0000
Subject: [issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'
In-Reply-To: <1267117600.52.0.726155652991.issue7649@psf.upfronthosting.co.za>
Message-ID: <4B86AFB7.4040804@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ezio Melotti wrote:
> 
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
> 
> The patch should apply cleanly on the latest revision of trunk (if you look at the diff it removes the code of the first version).

Ah, sorry, my fault.

> About the doc, I think it would be better to say that usually it's ASCII (or UTF-8 on Py3 -- Py3 doc should be fixed too), but it might be something different if it's changed using sys.setdefaultencoding().

I guess it's better to open a separate ticket for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7649>
_______________________________________

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: [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 19:49:16 2010
From: report at bugs.python.org (Nick)
Date: Thu, 25 Feb 2010 18:49:16 +0000
Subject: [issue8019] struct.unpack() expects wrong number of bytes
In-Reply-To: <1267122150.44.0.78777888297.issue8019@psf.upfronthosting.co.za>
Message-ID: <1267123756.63.0.0353535212016.issue8019@psf.upfronthosting.co.za>


Nick <niki at codingrobot.com> added the comment:

tested on macosx 10.6.2 64-bit and debian amd64 with both python2.6 and python3.1

the output is always the same:

b'\x01\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00'
20
(1, 1, 2, 1, 1)
(1, 1, 2, 16777216, 16777216)
(1, 1, 2, 16777216, 16777216)
------------------
b'\x01\x00\x00\x00\x01\x00\x00\x00\x02\x01\x00\x00\x00\x01\x00\x00\x00'
17
(1, 1, 2, 1, 1)
(1, 1, 2, 1, 1)

----------
Added file: http://bugs.python.org/file16370/struct_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8019>
_______________________________________

From report at bugs.python.org  Thu Feb 25 20:30:29 2010
From: report at bugs.python.org (Gael)
Date: Thu, 25 Feb 2010 19:30:29 +0000
Subject: [issue1669349] make install fails if no previous Python installation
Message-ID: <1267126229.39.0.634017120518.issue1669349@psf.upfronthosting.co.za>


Gael <gael.pegliasco at makina-corpus.com> added the comment:

Here it is.


Python 2.4.5 (#1, Feb 24 2010, 08:26:11)
[GCC 3.4.6] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print sys.path
[
'', 
'/tmp/Python-2.4/lib/python24.zip', 
'/install_path/Plone-3.2.1r4-UnifiedInstaller/packages/Python-2.4.5/Lib', 
'/install_path/Plone-3.2.1r4-UnifiedInstaller/packages/Python-2.4.5/Lib/plat-sunos5', 
'/install_path/Plone-3.2.1r4-UnifiedInstaller/packages/Python-2.4.5/Lib/lib-tk', 
'/install_path/Plone-3.2.1r4-UnifiedInstaller/packages/Python-2.4.5/Modules', 
'/install_path/Plone-3.2.1r4-UnifiedInstaller/packages/Python-2.4.5/build/lib.solaris-2.10-sun4u-2.4']


PS: Sorry for the message above, haven't seen I was responding to the bug system. Feel free to drop it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1669349>
_______________________________________

From report at bugs.python.org  Thu Feb 25 21:21:51 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Feb 2010 20:21:51 +0000
Subject: [issue8019] struct.unpack() expects wrong number of bytes
In-Reply-To: <1267122150.44.0.78777888297.issue8019@psf.upfronthosting.co.za>
Message-ID: <1267129311.85.0.670272848121.issue8019@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's not about byte ordering. '@' and '=' also change the alignment!

The documentation says it well:
- '@' (or no marker) uses the 'native' alignment, which (on every platform I know) aligns 4-bytes ints to multiple of 4 bytes.
- '=' uses the 'standard' alignment which is: "no alignment is required for any type"

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8019>
_______________________________________

From report at bugs.python.org  Thu Feb 25 21:46:33 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 25 Feb 2010 20:46:33 +0000
Subject: [issue7863] platform module doesn't detect Windows 7
In-Reply-To: <1265412745.93.0.400074024271.issue7863@psf.upfronthosting.co.za>
Message-ID: <1267130793.21.0.906519791067.issue7863@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

This patch should cover everything, and it works with 2.6 as well. In order to figure out workstation vs. server, it uses the ProductName from the registry when it can't the info from getwindowsversion. If it finds a server name, it's a server, otherwise fallback to be a workstation.

This was able to correctly differentiate Vista and Server 2008. I don't have access to Server 2008 R2, but I can't imagine it missing a registry key that exists on every computer I looked at (XP, 2003, Vista, 2008, 7).

----------
Added file: http://bugs.python.org/file16371/issue7863.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7863>
_______________________________________

From report at bugs.python.org  Thu Feb 25 22:20:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 25 Feb 2010 21:20:37 +0000
Subject: [issue7150] datetime operations spanning MINYEAR give bad results
In-Reply-To: <1255686329.97.0.65785065346.issue7150@psf.upfronthosting.co.za>
Message-ID: <1267132837.89.0.656450070644.issue7150@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Given

        assert(*m > 0);
        assert(*d > 0);

at the end of normalize_y_m_d(), it looks like at lest 1 <=*month and 1 <=*day are redundant.

A closer look also reveals 

        assert(1 <= *m && *m <= 12);

in the middle of normalize_y_m_d().  This seems to leave only *day <=31 possibly relevant.

I suspect that out of bounds day surviving normalize_y_m_d() is a logical error in that function that needs to be fixed and an assert() added at the end.  The proposed patch appears to cure the symptom rather than the actual flaw.

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7150>
_______________________________________

From report at bugs.python.org  Thu Feb 25 22:24:54 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 25 Feb 2010 21:24:54 +0000
Subject: [issue7150] datetime operations spanning MINYEAR give bad results
In-Reply-To: <1255686329.97.0.65785065346.issue7150@psf.upfronthosting.co.za>
Message-ID: <1267133094.67.0.180055648123.issue7150@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

Aha!  My reliance on asserts() was misguided.  With the debug build:

>>> t0-d2
Assertion failed: (ordinal >= 1), function ord_to_ymd, file /Users/sasha/Work/python-svn/trunk/Modules/datetimemodule.c, line 269.
Abort trap

Should we reclassify this bug as a crash?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7150>
_______________________________________

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: [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 22:57:29 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Feb 2010 21:57:29 +0000
Subject: [issue7150] datetime operations spanning MINYEAR give bad results
In-Reply-To: <1255686329.97.0.65785065346.issue7150@psf.upfronthosting.co.za>
Message-ID: <1267135049.6.0.570847828502.issue7150@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

No, because normally distributions do not use debug builds.
but that's the reason why tests are needed: they must pass with asserts enabled.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7150>
_______________________________________

From report at bugs.python.org  Thu Feb 25 23:03:13 2010
From: report at bugs.python.org (Matt Bandy)
Date: Thu, 25 Feb 2010 22:03:13 +0000
Subject: [issue8020] Crash in Py_ADDRESS_IN_RANGE macro
In-Reply-To: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>
Message-ID: <1267135393.16.0.665042301556.issue8020@psf.upfronthosting.co.za>


Matt Bandy <matt.bandy at thq.com> added the comment:

You can't add a block without changing the way the macro is used -- it's usually used like:

if (Py_ADDRESS_IN_RANGE(p, pool))

This won't work with your proposed change since you can't put a do {} loop into the test expression of the if statement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8020>
_______________________________________

From report at bugs.python.org  Thu Feb 25 23:06:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Feb 2010 22:06:02 +0000
Subject: [issue8020] Crash in Py_ADDRESS_IN_RANGE macro
In-Reply-To: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>
Message-ID: <1267135562.39.0.0970162219858.issue8020@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Obviously it also involves changing the code where the macro is invoked. It would be quite non-controversial though.

I've a got a more interesting question: how does the memory allocator end up being invoked from two threads at once? Usually memory allocations should be serialized by the GIL (the Global Interpreter Lock).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8020>
_______________________________________

From report at bugs.python.org  Thu Feb 25 23:10:19 2010
From: report at bugs.python.org (Tim Peters)
Date: Thu, 25 Feb 2010 22:10:19 +0000
Subject: [issue8020] Crash in Py_ADDRESS_IN_RANGE macro
In-Reply-To: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>
Message-ID: <1267135819.53.0.700174786725.issue8020@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Note that nothing in obmalloc is _intended_ to be thread-safe.  Almost all Python API functions make the caller responsible for serializing calls (which is usually accomplished "by magic" via the GIL).  This includes calls to all facilities supplied by obmalloc.

----------
nosy: +tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8020>
_______________________________________

From report at bugs.python.org  Thu Feb 25 23:17:03 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Feb 2010 22:17:03 +0000
Subject: [issue8020] Crash in Py_ADDRESS_IN_RANGE macro
In-Reply-To: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>
Message-ID: <1267136223.18.0.234312057988.issue8020@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

No, the description above says it: only the first thread calls Py_ADDRESS_IN_RANGE. The other thread happens to modify the memory at the beginning of the page, just at the address (POOL)->arenaindex.

Could we use an "inline" function instead of a macro? I suppose the compiler would optimize it and generate code as fast as a macro.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8020>
_______________________________________

From report at bugs.python.org  Thu Feb 25 23:24:48 2010
From: report at bugs.python.org (Matt Bandy)
Date: Thu, 25 Feb 2010 22:24:48 +0000
Subject: [issue8020] Crash in Py_ADDRESS_IN_RANGE macro
In-Reply-To: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>
Message-ID: <1267136688.61.0.193120167326.issue8020@psf.upfronthosting.co.za>


Matt Bandy <matt.bandy at thq.com> added the comment:

Amaury is correct -- in the case I observed, the other thread had nothing to do with Python and was not calling Python functions that would have required obtaining the GIL at any time (again, I'm using an embedded Python interpreter in a larger app, not the standalone interpreter).  The other thread is just unlucky to have allocated non-Python related memory in the same page where a Python object was allocated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8020>
_______________________________________

From report at bugs.python.org  Thu Feb 25 23:25:18 2010
From: report at bugs.python.org (Tim Peters)
Date: Thu, 25 Feb 2010 22:25:18 +0000
Subject: [issue8020] Crash in Py_ADDRESS_IN_RANGE macro
In-Reply-To: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>
Message-ID: <1267136718.08.0.751533908567.issue8020@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Amaury, I have no real idea what your "No, the description above says it: ..." is a response to, but if it's to my point that obmalloc is not intended to be thread-safe, it's not addressing that point.  Any case in which another thread can affect a thread currently running in obmalloc is forbidden:  forbidden, not allowed, begging for undefined behavior, etc etc.

> Could we use an "inline" function instead of a macro?

If every C compiler on every platform Python runs on supports such a thing with exactly the same spelling, sure ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8020>
_______________________________________

From report at bugs.python.org  Thu Feb 25 23:27:33 2010
From: report at bugs.python.org (Asheesh Laroia)
Date: Thu, 25 Feb 2010 22:27:33 +0000
Subject: [issue6538] MatchObject is not a hyperlink in the 're' module
	documentation
In-Reply-To: <1248215363.5.0.63292386695.issue6538@psf.upfronthosting.co.za>
Message-ID: <1267136853.7.0.767820768359.issue6538@psf.upfronthosting.co.za>


Asheesh Laroia <asheesh at asheesh.org> added the comment:

Hey all,

I think this is ready. Can someone review the patch?

----------
nosy: +Asheesh.Laroia

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6538>
_______________________________________

From report at bugs.python.org  Thu Feb 25 23:36:32 2010
From: report at bugs.python.org (Tim Peters)
Date: Thu, 25 Feb 2010 22:36:32 +0000
Subject: [issue8020] Crash in Py_ADDRESS_IN_RANGE macro
In-Reply-To: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>
Message-ID: <1267137392.58.0.228568527438.issue8020@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Just noting there are ways to trick the macro into reading a thing once.  For example, embed something like a

((x = arenas[(POOL)->arenaindex].address) || 1)

clause early on & refer to x later (where x is some file-scope new variable).

obmalloc is not intended to be thread-safe _period_, but I agree the current behavior in the case described is obnoxious enough that if it's easy to worm around it, fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8020>
_______________________________________

From report at bugs.python.org  Thu Feb 25 23:44:55 2010
From: report at bugs.python.org (Matt Bandy)
Date: Thu, 25 Feb 2010 22:44:55 +0000
Subject: [issue8020] Crash in Py_ADDRESS_IN_RANGE macro
In-Reply-To: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>
Message-ID: <1267137895.51.0.449292256558.issue8020@psf.upfronthosting.co.za>


Matt Bandy <matt.bandy at thq.com> added the comment:

It's a pretty major limitation on the embedding case if you can't allow other threads that aren't related to Python to run at any time that another thread may be in obmalloc, and one I haven't seen documented anywhere.  The only other fix that occurs to me would be to ensure that any memory Python allocates is not in the same page as memory not allocated by Python, but that seems like it would be much more complex than the current "just call malloc()" solution.  Your proposed change to the macro sounds more reasonable to me.

----------

_______________________________________
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: [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  Thu Feb 25 23:54:45 2010
From: report at bugs.python.org (David Schere)
Date: Thu, 25 Feb 2010 22:54:45 +0000
Subject: [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: <1267138485.62.0.931784568997.issue8021@psf.upfronthosting.co.za>


David Schere <dschere at arinc.com> added the comment:

sys.exit() does not behave the way a C programming thinks. It raises an exception. 

I'm probably not the first person to get this 'gotcha'

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8021>
_______________________________________

From report at bugs.python.org  Thu Feb 25 23:59:27 2010
From: report at bugs.python.org (Tim Peters)
Date: Thu, 25 Feb 2010 22:59:27 +0000
Subject: [issue8020] Crash in Py_ADDRESS_IN_RANGE macro
In-Reply-To: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>
Message-ID: <1267138767.73.0.796035792694.issue8020@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Right, I already agreed it would be fine to fix this if it's cheap ;-)

I didn't give any real thought to the macro solution, but that's fine by me too.  It would be best to embed the assignment in a _natural_ place, though; like, say:

#define Py_ADDRESS_IN_RANGE(P, POOL)			\
	((POOL)->arenaindex < maxarenas &&		\
	 (uptr)(P) - (x = arenas[(POOL)->arenaindex].address) < (uptr)ARENA_SIZE && \
	 x != 0)

where some better name than `x` is picked, and the trick is clearly documented at x's declaration point.  Nothing wrong with expediency here!  This is time-critical code and has always been skating on the edge.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8020>
_______________________________________

From report at bugs.python.org  Fri Feb 26 00:04:41 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Feb 2010 23:04:41 +0000
Subject: [issue6538] MatchObject is not a hyperlink in the 're' module
	documentation
In-Reply-To: <1248215363.5.0.63292386695.issue6538@psf.upfronthosting.co.za>
Message-ID: <1267139081.86.0.187860410171.issue6538@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It would be simpler to add a ".. class:: MatchObject" directive.
Also, RegexpObject should be handled as well.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6538>
_______________________________________

From report at bugs.python.org  Fri Feb 26 00:10:19 2010
From: report at bugs.python.org (Matt Bandy)
Date: Thu, 25 Feb 2010 23:10:19 +0000
Subject: [issue8020] Crash in Py_ADDRESS_IN_RANGE macro
In-Reply-To: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>
Message-ID: <1267139419.99.0.607868713059.issue8020@psf.upfronthosting.co.za>


Matt Bandy <matt.bandy at thq.com> added the comment:

That should probably be:

#define Py_ADDRESS_IN_RANGE(P, POOL)			\
	((x = (POOL)->arenaindex) < maxarenas &&		\
	 (uptr)(P) - arenas[x].address < (uptr)ARENA_SIZE && \
	 arenas[x].address != 0)

The address in the arena shouldn't change since it does belong to Python, so no one should be monkeying with it without the GIL.  The arenaindex is vulnerable since POOL can point to something not owned by Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8020>
_______________________________________

From report at bugs.python.org  Fri Feb 26 00:34:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 25 Feb 2010 23:34:01 +0000
Subject: [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: <1267140841.54.0.945744719104.issue8015@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I am attaching the patch that fixes the issue by ignoring empty and all space lines during commands' entry.  Note that as written the patch also makes pdb ignore shell escapes unless it is extended with do_shell method. I think this is the right behavior.

----------
components: +Library (Lib)
keywords: +patch
nosy: +Alexander.Belopolsky
type:  -> behavior
Added file: http://bugs.python.org/file16373/issue8015.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8015>
_______________________________________

From report at bugs.python.org  Fri Feb 26 00:35:15 2010
From: report at bugs.python.org (Tim Peters)
Date: Thu, 25 Feb 2010 23:35:15 +0000
Subject: [issue8020] Crash in Py_ADDRESS_IN_RANGE macro
In-Reply-To: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>
Message-ID: <1267140915.9.0.528471913748.issue8020@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

> `x` should be a local variable. ... assembler code will be smaller.

??? It should make no difference to an optimizing compiler. Lifetime analysis (even if it's feeble) should be able to determine that all uses are purely local, with no need to store the value away.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8020>
_______________________________________

From report at bugs.python.org  Fri Feb 26 00:49:49 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 25 Feb 2010 23:49:49 +0000
Subject: [issue1528154] New sequences for Unicode groups and block ranges
	needed
Message-ID: <1267141789.15.0.229833219859.issue1528154@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

\p{name} is supported for Unicode properties, scripts and blocks in my regex module (see issue #2636).

It also supports the POSIX set syntax, although I'm not sure that we really need to have 2 ways of doing it, eg \p{Alpha} and [[:Alpha:]].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1528154>
_______________________________________

From report at bugs.python.org  Fri Feb 26 01:44:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 26 Feb 2010 00:44:04 +0000
Subject: [issue7999] setregid does not work with -1 as argument
In-Reply-To: <1266919086.08.0.79034896457.issue7999@psf.upfronthosting.co.za>
Message-ID: <1267145044.47.0.11287580431.issue7999@psf.upfronthosting.co.za>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

I reproduced this bug on OSX 10.6:

>>> os.setregid(-1,-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: group id too big

Since -1 has special meaning as an argument to POSIX setregid(rgid, egid),

"""
If rgid is -1, the real group ID shall not be changed; if egid is -1, the effective group ID shall not be changed.
"""

I think passing -1 to os. setregid() should be supported.

Meanwhile the following work-around works for me on OSX, but may not work on other platforms:

>>> os.setregid(2**32-1,2**32-1)

----------
nosy: +Alexander.Belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7999>
_______________________________________

From report at bugs.python.org  Fri Feb 26 01:57:18 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 26 Feb 2010 00:57:18 +0000
Subject: [issue5475] urllib2.getproxies not documented
In-Reply-To: <1236766495.94.0.773728136477.issue5475@psf.upfronthosting.co.za>
Message-ID: <1267145838.66.0.376359508559.issue5475@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

urllib.getproxies() might be helpful to be documented too. I have added documentaion to this helper function in the r78457 (trunk), r78458, r78459, r78460.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5475>
_______________________________________

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: [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 03:23:40 2010
From: report at bugs.python.org (Asheesh Laroia)
Date: Fri, 26 Feb 2010 02:23:40 +0000
Subject: [issue6538] MatchObject is not a hyperlink in the 're' module
	documentation
In-Reply-To: <1248215363.5.0.63292386695.issue6538@psf.upfronthosting.co.za>
Message-ID: <1267151020.72.0.168772031517.issue6538@psf.upfronthosting.co.za>


Asheesh Laroia <asheesh at asheesh.org> added the comment:

Ryan -- would you take a further look at this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6538>
_______________________________________

From report at bugs.python.org  Fri Feb 26 03:46:08 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 26 Feb 2010 02:46:08 +0000
Subject: [issue8022] Leak when creating certain classes that subclass ABCs
In-Reply-To: <1267150674.85.0.640094833766.issue8022@psf.upfronthosting.co.za>
Message-ID: <1267152368.37.0.477220761861.issue8022@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> ABC caches should use weak refs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8022>
_______________________________________

From report at bugs.python.org  Fri Feb 26 04:20:18 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 26 Feb 2010 03:20:18 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1267154418.61.0.841375807033.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20100226.zip is a new version of the regex module.

It now supports the branch reset (?|...|...), enabling the different branches of an alternation to reuse group numbers.

----------
Added file: http://bugs.python.org/file16375/issue2636-20100226.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Feb 26 05:03:20 2010
From: report at bugs.python.org (Meador Inge)
Date: Fri, 26 Feb 2010 04:03:20 +0000
Subject: [issue7994] object.__format__ should reject format strings
In-Reply-To: <1266875939.21.0.792202593026.issue7994@psf.upfronthosting.co.za>
Message-ID: <1267157000.27.0.281385521679.issue7994@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

The patch looks reasonable.  I built on it with the following changes:

   1. Added some extra test cases to cover Unicode format strings, 
      since the code was changed to handle these as well.
   2. Changed test_builtin.py by 
      s/m[0].message.message/str(w[0].message)/, since 
      BaseException.message was deprecated in 2.6.

I also have the following general comments:

   1. PEP 3101 explicitly defines the string conversion for 
      object.__format__.  What is the rationale behind this?  Should
      we find out before making this change?
   2. I don't think the comments in 'abstract.c' and 'typeobject.c'
      explaining that the warning will eventually become an error are
      needed.  I think it would be better to open separate issues for
      these migration steps as they can be tracked easier and will be 
      more visible.
   3. test_unicode, test_str have cases that trigger the added 
      warning.  Should they be altered now or when (if) this becomes 
      an error?

----------
nosy: +minge
Added file: http://bugs.python.org/file16376/issue7994-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7994>
_______________________________________

From report at bugs.python.org  Fri Feb 26 06:09:24 2010
From: report at bugs.python.org (Pablo Mouzo)
Date: Fri, 26 Feb 2010 05:09:24 +0000
Subject: [issue7911] unittest.TestCase.longMessage should default to True in
	Python 3.2
In-Reply-To: <1265915317.63.0.548370408241.issue7911@psf.upfronthosting.co.za>
Message-ID: <1267160964.09.0.274265622566.issue7911@psf.upfronthosting.co.za>


Pablo Mouzo <pablomouzo at gmail.com> added the comment:

The patch changes the default to True, and updates the tests and the docs to reflect this.

----------
keywords: +patch
nosy: +pablomouzo
Added file: http://bugs.python.org/file16377/issue7834.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7911>
_______________________________________

From report at bugs.python.org  Fri Feb 26 09:10:49 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 26 Feb 2010 08:10:49 +0000
Subject: [issue7994] object.__format__ should reject format strings
In-Reply-To: <1266875939.21.0.792202593026.issue7994@psf.upfronthosting.co.za>
Message-ID: <1267171849.94.0.311410790511.issue7994@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I haven't looked at the patch, but:

Thanks for the the additional tests. Missing unicode was definitely a mistake.

str(w[0].message) is an improvement.

The PEP is out of date in many respects. I think it's best to note that in the PEP and continue to keep the documentation up-to-date.

This issue already applies to 3.3, but my plan is to remove that and create a new issue when I close this one. But I'd still like to leave the comments in place.

I'm aware of the existing tests which trigger the warning. I think they should probably be removed, although I haven't really spent much time thinking about it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7994>
_______________________________________

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: [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 10:18:22 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 26 Feb 2010 09:18:22 +0000
Subject: [issue8023] bug in s.append(x)
In-Reply-To: <1267174532.93.0.564850423841.issue8023@psf.upfronthosting.co.za>
Message-ID: <1267175902.75.0.0951876681083.issue8023@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is a bug in your code, rather than in Python.

A simpler example, for the purposes of explanation:

>>> root, total = [0], []
>>> total.append(root)
>>> total  # good so far
[[0]]
>>> root[0] = 1   # modify root
>>> total  # note that total changes here!
[[1]]
>>> total.append(root)
>>> total
[[1], [1]]

In effect, total contains two references to the same list.  Modify that list, and you'll see those changes reflected in `total` as well.

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8023>
_______________________________________

From report at bugs.python.org  Fri Feb 26 11:18:18 2010
From: report at bugs.python.org (Zsolt Cserna)
Date: Fri, 26 Feb 2010 10:18:18 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1267179498.79.0.408326323067.issue7242@psf.upfronthosting.co.za>


Zsolt Cserna <zsolt.cserna at morganstanley.com> added the comment:

There's a bundled unittest in test_httpservers which actually fails if this patch is not applied.

See the unittest attached. Unfortunatelly RuntimError is raised in the child process after fork() so I cannot re-raise it to the parent, instead I send a message from the child to the parent via a pipe if the child is ok.

----------
Added file: http://bugs.python.org/file16378/thread_unittest.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

From report at bugs.python.org  Fri Feb 26 11:20:21 2010
From: report at bugs.python.org (Zsolt Cserna)
Date: Fri, 26 Feb 2010 10:20:21 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1267179621.36.0.303021763214.issue7242@psf.upfronthosting.co.za>


Zsolt Cserna <zsolt.cserna at morganstanley.com> added the comment:

I've run unittest with both patched and vanilla versions of python 2.6.4 and I confirm that it fails when it's run by vanilla on solaris 8, but passes on the patched version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

From report at bugs.python.org  Fri Feb 26 11:29:57 2010
From: report at bugs.python.org (ughacks)
Date: Fri, 26 Feb 2010 10:29:57 +0000
Subject: [issue8023] bug in s.append(x)
In-Reply-To: <1267174532.93.0.564850423841.issue8023@psf.upfronthosting.co.za>
Message-ID: <1267180197.91.0.92313448167.issue8023@psf.upfronthosting.co.za>


ughacks <ughacks at yahoo.com> added the comment:

Thank you for kind explanation.

So s.append(x) just copies the pointer, not the actual value. It is a little tricky to know that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8023>
_______________________________________

From report at bugs.python.org  Fri Feb 26 12:02:21 2010
From: report at bugs.python.org (instigate_team)
Date: Fri, 26 Feb 2010 11:02:21 +0000
Subject: [issue7573] Python build issue on Ubuntu 9.10
In-Reply-To: <1261653981.05.0.861950270955.issue7573@psf.upfronthosting.co.za>
Message-ID: <1267182141.76.0.406462284693.issue7573@psf.upfronthosting.co.za>


instigate_team <narine_martirosyan at instigatedesign.com> added the comment:

This is a solution in case if an application contains only several files, where I can control the includes consequence. But if application has many files, directories, in this case the hierarchy of the files includes can not be traced.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7573>
_______________________________________

From report at bugs.python.org  Fri Feb 26 12:13:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 26 Feb 2010 11:13:37 +0000
Subject: [issue8023] bug in s.append(x)
In-Reply-To: <1267174532.93.0.564850423841.issue8023@psf.upfronthosting.co.za>
Message-ID: <1267182817.75.0.994788905241.issue8023@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> So s.append(x) just copies the pointer, not the actual value.

Yes, that's a reasonable way to think about it (though the term 'reference' seems to more popular than 'pointer' in this context).  It matches the implementation, too: internally, a list is represented as a resizable array of pointers to objects.  (For CPython, anyway;  alternative implementations of Python might differ.)

Implicit object copies are rare in Python.

comp.lang.python is a good place to ask questions about Python's object model.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8023>
_______________________________________

From report at bugs.python.org  Fri Feb 26 15:26:18 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 26 Feb 2010 14:26:18 +0000
Subject: [issue7573] Python build issue on Ubuntu 9.10
In-Reply-To: <1261653981.05.0.861950270955.issue7573@psf.upfronthosting.co.za>
Message-ID: <1267194378.92.0.299530736249.issue7573@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

That solution will work if you have 1 file or 1000 files. The note on the documentation is very clear on what has to happen.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7573>
_______________________________________

From report at bugs.python.org  Fri Feb 26 15:36:18 2010
From: report at bugs.python.org (Alex Willmer)
Date: Fri, 26 Feb 2010 14:36:18 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1267154418.61.0.841375807033.issue2636@psf.upfronthosting.co.za>
Message-ID: <425e93af1002260636g6a6b6b70i31613059fcb9881a@mail.gmail.com>


Alex Willmer <alex at moreati.org.uk> added the comment:

On 26 February 2010 03:20, Matthew Barnett <report at bugs.python.org> wrote:
> Added file: http://bugs.python.org/file16375/issue2636-20100226.zip

This is now uploaded to PyPI http://pypi.python.org/pypi/regex/0.1.20100226
-- 
Alex Willmer <alex at moreati.org.uk>
http://moreati.org.uk/blog

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Feb 26 15:43:49 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 26 Feb 2010 14:43:49 +0000
Subject: [issue8024] upgrade to Unicode 5.2?
In-Reply-To: <1267194529.12.0.298670446045.issue8024@psf.upfronthosting.co.za>
Message-ID: <1267195429.26.0.344760395386.issue8024@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Excerpt of the release note:
http://www.unicode.org/versions/Unicode5.2.0/

The Unicode Standard, Version 5.2, adds 6,648 characters and significantly improves the documentation of conformance requirements for the specification of normalization forms, canonical ordering, and the status of types of properties. Version 5.2 brings improved clarity of presentation in many Unicode Standard Annexes.

Seven new contemporary scripts have been added in Version 5.2: Bamum, Javanese, Lisu, Meetei Mayek, Samaritan, Tai Tham, and Tai Viet. New character additions to existing scripts now provide greater support for Abkhaz, Canadian Aboriginal Syllabics, Coptic, Devanagari, Khamti Shan, Malayalam, and Myanmar. Of particular note are Devanagari additions in support of Vedic Sanskrit. Encoding Vedic is significant because Sanskrit is one of the principal languages for the religious heritage of India, and because Vedic represents the earliest attested phase of the language.

The seven contemporary scripts and newly encoded individual characters expand support of language and orthographic communities in Africa, India, China, Central Asia, Southeast Asia, and the Middle East.

Other character additions include important modern use symbols and historic characters. With Unicode Version 5.2, scholars will now have access to the Gardiner set of Egyptian Hieroglyphs as well as other important historic scripts: Imperial Aramaic, Avestan, Kaithi, Old South Arabian, and Old Turkic. Several key symbol sets were added or expanded: the ARIB set of Japanese broadcasting symbols, additional number forms used in India, and currency symbols. 


Current version is 5.1 in Python 2.6

----------
dependencies: +Add an argument to test_support.open_urlresource to invalidate the cache

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8024>
_______________________________________

From report at bugs.python.org  Fri Feb 26 16:13:59 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 26 Feb 2010 15:13:59 +0000
Subject: [issue7573] Position independent include of Python.h
In-Reply-To: <1261653981.05.0.861950270955.issue7573@psf.upfronthosting.co.za>
Message-ID: <1267197239.37.0.600188118712.issue7573@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

instigate_team, you said earlier that you have no warnings if you change
the include sequence according to the documentation. Unless you provide
a concrete example where the position dependent include of Python.h
makes building _impossible_ (as opposed to being a minor nuisance), I'd
say that this is a feature request.

----------
title: Python build issue on Ubuntu 9.10 -> Position independent include of Python.h
type: compile error -> feature request
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7573>
_______________________________________

From report at bugs.python.org  Fri Feb 26 16:59:31 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 26 Feb 2010 15:59:31 +0000
Subject: [issue8024] upgrade to Unicode 5.2?
In-Reply-To: <1267194529.12.0.298670446045.issue8024@psf.upfronthosting.co.za>
Message-ID: <1267199971.67.0.878368607833.issue8024@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Have you checked how big the structural changes are between 5.2 and 5.1.

If we only have to rerun the makeunicodedata.py script, then I'd be +1 on going with 5.2.

Otherwise, I think it's better to wait another release before upgrading to the then latest Unicode version.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8024>
_______________________________________

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: [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  Fri Feb 26 17:14:02 2010
From: report at bugs.python.org (Matt Bandy)
Date: Fri, 26 Feb 2010 16:14:02 +0000
Subject: [issue8020] Crash in Py_ADDRESS_IN_RANGE macro
In-Reply-To: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>
Message-ID: <1267200842.25.0.392806170949.issue8020@psf.upfronthosting.co.za>


Matt Bandy <matt.bandy at thq.com> added the comment:

I tried this out in VC++ 2008 with the new temporary as both a global variable and a local.  At least for VC++, Amaury is correct -- the compiler is generating the store to the global even though it is never read, so making it a local instead does save an instruction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8020>
_______________________________________

From report at bugs.python.org  Fri Feb 26 17:19:28 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 26 Feb 2010 16:19:28 +0000
Subject: [issue8025] TypeError: string argument expected, got 'str'
In-Reply-To: <1267200716.31.0.22497398995.issue8025@psf.upfronthosting.co.za>
Message-ID: <1267201168.07.0.0181743700614.issue8025@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The problem is in Modules/_io/stringio.c, in stringio_write. The error message still uses the py3k wording where 'string' means unicode string. The error should say "unicode argument expected, got 'str'".
There might be similar mistakes around.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8025>
_______________________________________

From report at bugs.python.org  Fri Feb 26 17:23:36 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 26 Feb 2010 16:23:36 +0000
Subject: [issue8025] TypeError: string argument expected, got 'str'
In-Reply-To: <1267200716.31.0.22497398995.issue8025@psf.upfronthosting.co.za>
Message-ID: <1267201416.65.0.328619129281.issue8025@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

The error is slightly different with _pyio:

>>> import _pyio as io; fake = io.StringIO(); fake.write('boo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "./py2trunk/Lib/_pyio.py", line 1559, in write
    s.__class__.__name__)
TypeError: can't write str to text stream

Is it better?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8025>
_______________________________________

From report at bugs.python.org  Fri Feb 26 17:26:22 2010
From: report at bugs.python.org (Tim Peters)
Date: Fri, 26 Feb 2010 16:26:22 +0000
Subject: [issue8020] Crash in Py_ADDRESS_IN_RANGE macro
In-Reply-To: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>
Message-ID: <1267201582.16.0.525473205481.issue8020@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Whatever works best.  Unsure what you mean by "global", though, because it's not a C concept.  File-scope variables in C can have internal or external linkage; to get internal linkage, so that lifetime analysis is effective without needing (roughly speaking) cross-file analysis, you have to use the "static" declaration modifier.  Without "static", linkage is external, and then in the absence of (roughly speaking) cross-file analysis the compiler must assume the value can be read by code in other files.

So, did you use "static", or not?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8020>
_______________________________________

From report at bugs.python.org  Fri Feb 26 17:34:01 2010
From: report at bugs.python.org (Matt Bandy)
Date: Fri, 26 Feb 2010 16:34:01 +0000
Subject: [issue8020] Crash in Py_ADDRESS_IN_RANGE macro
In-Reply-To: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>
Message-ID: <1267202041.38.0.42929222837.issue8020@psf.upfronthosting.co.za>


Matt Bandy <matt.bandy at thq.com> added the comment:

Sorry, I should have been more precise.  I did use static for the variable I declared at file scope.  Looking at the disassembly again also reminded me of something I should have mentioned in the original bug report: at least when using Visual C++ 2008, in the release build the compiler optimizes out the repeated reads even with the original code, so the generated assembly with the local variable patch is actually identical.  I encountered the bug using the debug build of the interpreter, where that optimization does not occur and the memory is actually read three times.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8020>
_______________________________________

From report at bugs.python.org  Fri Feb 26 17:36:31 2010
From: report at bugs.python.org (Tim Peters)
Date: Fri, 26 Feb 2010 16:36:31 +0000
Subject: [issue8020] Crash in Py_ADDRESS_IN_RANGE macro
In-Reply-To: <1267133662.17.0.467128574772.issue8020@psf.upfronthosting.co.za>
Message-ID: <1267202191.36.0.680141082358.issue8020@psf.upfronthosting.co.za>


Tim Peters <tim.peters at gmail.com> added the comment:

Cool!  Python has a long history of catering to feeble compilers too ;-), so using function locals is fine.  Speed matters more than obscurity here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8020>
_______________________________________

From report at bugs.python.org  Fri Feb 26 17:37:17 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Feb 2010 16:37:17 +0000
Subject: [issue8025] TypeError: string argument expected, got 'str'
In-Reply-To: <1267200716.31.0.22497398995.issue8025@psf.upfronthosting.co.za>
Message-ID: <1267202237.91.0.118329821065.issue8025@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> TypeError: can't write str to text stream
>
> Is it better?

There is the same ambiguity in http://docs.python.org/library/io.html
"text" is not defined. And "string" is often used incorrectly.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8025>
_______________________________________

From report at bugs.python.org  Fri Feb 26 21:22:24 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 26 Feb 2010 20:22:24 +0000
Subject: [issue7100] test_xmlrpc: global name 'stop_serving' is not defined
In-Reply-To: <1255207170.52.0.845543632042.issue7100@psf.upfronthosting.co.za>
Message-ID: <1267215744.17.0.37684469853.issue7100@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

The stop_serving() code was only added on the Py3k branch
in rev59424.  It was removed in rev60350,
which is a merge commit; the diff is http://svn.python.org/view/python/branches/py3k/Lib/test/test_xmlrpc.py?r1=60094&r2=60350.

I don't know if this is a merging error, or if the 2.x changes mean stop_serving() is no longer required. Christian Heimes was responsible for both originally adding stop_serving() and for the merge that removed it. Adding him to the nosy list.

----------
nosy: +akuchling, christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7100>
_______________________________________

From report at bugs.python.org  Fri Feb 26 21:27:35 2010
From: report at bugs.python.org (Greg Jednaszewski)
Date: Fri, 26 Feb 2010 20:27:35 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1267216055.13.0.620310385603.issue7242@psf.upfronthosting.co.za>


Greg Jednaszewski <jednaszewski at gmail.com> added the comment:

I spent some time working on and testing a unit test as well.  It's the same basic idea as Zsolt Cserna's, but with a slightly different approach.  See 7242_unittest.diff.  My unittest fails pre-patch and succeeds post-patch.

However, I still have reservations about the patch.  The existing test test_threading.ThreadJoinOnShutdown.test_3_join_in_forked_from_thread hangs with the patch in place.

Vanilla 2.6.2 - test passes
Vanilla 2.6.4 - test fails
Patched 2.6.4 - test hangs

Note: the code of the test_threading test is identical in all 3 cases.  I'd feel more confident about the patch if this test didn't hang with the patch in place.

----------
Added file: http://bugs.python.org/file16381/7242_unittest.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

From report at bugs.python.org  Fri Feb 26 21:29:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 26 Feb 2010 20:29:10 +0000
Subject: [issue7100] test_xmlrpc: global name 'stop_serving' is not defined
In-Reply-To: <1255207170.52.0.845543632042.issue7100@psf.upfronthosting.co.za>
Message-ID: <1267216150.7.0.462800930818.issue7100@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Having looked at this code for another reason, I suspect that the stop_serving change was an attempt to handle a possible hang in the test, and that the py2 code simply doesn't try to handle that possible hang.  Note that you can simulate the hang by having a test method never issue a request.  I couldn't figure out a way to get the server to stop serving, but I didn't try for too long before I gave up and used a different solution to the problem I was facing (skipping one of the tests...)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7100>
_______________________________________

From report at bugs.python.org  Fri Feb 26 21:41:48 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 26 Feb 2010 20:41:48 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1267216908.54.0.311408304236.issue4111@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

At Red Hat we've done some work on this feature.  I'm sorry for not updating this issue, I was swamped with tasks both pre-PyCon and during the event; I did show the following to various folks at PyCon; I attempted to find Skip at PyCon but was unsuccessful)

Unfortunately I have two further versions of this patch for you :(

High level summary
------------------
SystemTap is a similar tool for DTrace, but for Linux.

At Red Hat we've been looking at implementing this using SystemTap.  SystemTap makes some attempts to be at least somewhat compatible with DTrace, and we are able to get the DTrace support to build against SystemTap.

I measured the performance and found that some versions of the patch impose a significant performance penalty.

We have a version of the patch that works with SystemTap on Linux, and appears not to impose a performance penalty for the cases I think are important (see notes below)

I have also ported the patch to Python 3 (I pass the strings back to the probe support as UTF-8 encoded)

I hope that there's enough commonality between the SystemTap and DTrace patches to permit common parts to be committed to Python, perhaps eventually supporting both.  Having said that, I don't have any systems that can run DTrace.

I've chosen to build the upcoming Fedora 13's Python 2 and Python 3 rpms with this support enabled (I'm a Python guy, not a SystemTap guy, FWIW, but we have a strong in-house SystemTap team).  We've been tracking this downstream for Fedora, our detailed discussions are within this bug in our downstream tracker:
https://bugzilla.redhat.com/show_bug.cgi?id=545179
along with status:
  https://fedoraproject.org/wiki/Features/SystemtapStaticProbes#Python
and documentation:
  https://fedoraproject.org/wiki/Features/SystemtapStaticProbes#Python_2


Details
-------
SystemTap supplies a "dtrace" executable implemented in Python, which mimics the "dtrace" binary.
$ which dtrace
/usr/bin/dtrace
$ file $(which dtrace)
/usr/bin/dtrace: python script text executable
$ dtrace --help
Usage /usr/bin/dtrace [--help] [-h | -G] [-C [-I<Path>]] -s File.d [-o <File>]
Where -h builds a systemtap header file from the .d file
      -C when used with -h, also run cpp preprocessor
      -o specifies an explicit output file name,
         the default for -G is file.o and -h is file.h
      -I when running cpp pass through this -I include Path
      -s specifies the name of the .d input file
      -G builds a stub file.o from file.d,
         which is required by some packages that use dtrace.

I'm attaching a version of the patch against svn trunk.

This adds a "--with-dtrace" configuration option (I filed issue 7997 to better document how to do this).

Tested on a Fedora 12 box and works, with:
systemtap-1.1-2.fc12.i686
systemtap-sdt-devel-1.1-1.fc12.i686
systemtap-runtime-1.1-2.fc12.i686
kernel-PAE-2.6.31.12-174.2.3.fc12.i686
kernel-PAE-devel-2.6.31.12-174.2.3.fc12.i686
kernel-PAE-debuginfo-2.6.31.12-174.2.3.fc12.i686
kernel-headers-2.6.31.12-174.2.3.fc12.i686
kernel-debuginfo-common-i686-2.6.31.12-174.2.3.fc12.i686
kernel-firmware-2.6.31.12-174.2.3.fc12.noarch

Upon building --with-dtrace (but actually with systemtap), the linked binary containing ceval.o should contain a "probes" section (the following is a statically-linked build, hence the probes are in "./python"):

$ eu-readelf -S ./python | grep probes
[25] .probes              PROGBITS     081f9d28 1b0d28 000054  0 WA     0   0  8

$ eu-readelf -x .probes python

Hex dump of section [25] '.probes', 84 bytes at offset 0x1b0d28:
  0x00000000 66756e63 74696f6e 5f5f656e 74727900 function__entry.
  0x00000010 50524231 00000000 289d1f08 00000000 PRB1....(.......
  0x00000020 a50e0f08 00000000 66756e63 74696f6e ........function
  0x00000030 5f5f7265 7475726e 00000000 50524231 __return....PRB1
  0x00000040 509d1f08 00000000 1a0f0f08 00000000 P...............
  0x00000050 00000000                            ....

The above contains locations of "nop" instructions within the binary.  Systemtap generates kernel modules, and it uses this information to generate modules that monkeypatch the "nop" instruction at runtime to jump to code that gathers the pertinent information (filename, lineno etc) and returns that information to the kernel, and thus back to the user-space probe process.

Example of use
--------------
Here's an example of running regrtest whilst probing python to see function call and return during a run of the regression test suite (all in one shell command; obviously it would be saner to split the systemtap probe into a separate function):

[david at brick trunk-stap]$ stap -v -e'probe python.function.entry = process("./python").mark("function__entry")
{
    filename = user_string($arg1);
    funcname = user_string($arg2);
    lineno = $arg3;
}
probe python.function.return = process("./python").mark("function__return")
{
    filename = user_string($arg1);
    funcname = user_string($arg2);
    lineno = $arg3;
}
probe python.function.entry { printf("%s => %s in %s:%d\n", thread_indent(1), funcname, filename, lineno); }

probe python.function.return {printf("%s <= %s in %s:%d\n", thread_indent(-1), funcname, filename, lineno);}' \
-c "./python Lib/test/regrtest.py"

Output is as follow (note that I used -v to get verbose info on systemtap's passes):
Pass 1: parsed user script and 65 library script(s) using 20132virt/12268res/2052shr kb, in 220usr/10sys/242real ms.
Pass 2: analyzed script: 2 probe(s), 12 function(s), 2 embed(s), 2 global(s) using 24868virt/14788res/3392shr kb, in 20usr/10sys/37real ms.
Pass 3: using cached /home/david/.systemtap/cache/26/stap_2689ea1aadf52992794511e0d6996aca_5352.c
Pass 4: using cached /home/david/.systemtap/cache/26/stap_2689ea1aadf52992794511e0d6996aca_5352.ko
Pass 5: starting run.
     0 python(6769): => <module> in /home/david/coding/python-svn/trunk-stap/Lib/site.py:59
  1063 python(6769):  => <module> in /home/david/coding/python-svn/trunk-stap/Lib/os.py:22
  2510 python(6769):   => <module> in /home/david/coding/python-svn/trunk-stap/Lib/posixpath.py:11
  2756 python(6769):    => <module> in /home/david/coding/python-svn/trunk-stap/Lib/stat.py:4
  2792 python(6769):    <= <module> in /home/david/coding/python-svn/trunk-stap/Lib/stat.py:94
  3015 python(6769):    => <module> in /home/david/coding/python-svn/trunk-stap/Lib/genericpath.py:5
  3051 python(6769):    <= <module> in /home/david/coding/python-svn/trunk-stap/Lib/genericpath.py:85
  3713 python(6769):    => <module> in /home/david/coding/python-svn/trunk-stap/Lib/warnings.py:1
  3948 python(6769):     => <module> in /home/david/coding/python-svn/trunk-stap/Lib/linecache.py:6
  3984 python(6769):     <= <module> in /home/david/coding/python-svn/trunk-stap/Lib/linecache.py:68
(etc)

Performance
-----------
There are four cases here from a performance perspective:
(a) the source code without the patch
(b) the source code with the patch, configured --without-dtrace
(c) the source code with the patch, configured --with-dtrace, but without any "live" probes using the static marker
(d) the source code with the patch, configured --with-dtrace, with one or more "live" probes using the static marker

The performance goals I've been working towards are:
  - that (a) and (b) should have identical behavior, and
  - that (b) and (c) should have no significant performance differences i.e. having the markers compiled in shouldn't cost anything (as a packager of Python I want to be able to supply a common build, and the vast majority of my users won't be using the markers)
  - that it's acceptable for (d) to have a moderate performance cost compared to (c)

I used the unladen-swallow benchmark suite to examine performance.  

Our initial version of the patch (based on http://bugs.python.org/file12861/dtrace.diff ) showed a significant performance penalty for case (c) relative to case (b): 5-14% additional time being taken on most benchmarks, in rough (but, I believe, credible) tests.  Some notes on this can be seen at https://bugzilla.redhat.com/show_bug.cgi?id=545179#c12

I believe this regression is due to the generation and storing of f_calllineno at every frame entry.

We removed this and further benchmarking showed an insignificant performance difference between (b) and (c), though I wasn't as rigorous as I could have been with these benchmarks.  Some notes on this can be seen at https://bugzilla.redhat.com/show_bug.cgi?id=545179#c14

Case (d) probably has a significant penalty relative to (c), but I don't regard that as a blocker.  I haven't yet attempted to measure the performance impact of live probes.

Other issues
------------
If I'm reading things correctly, the marker is actually instrumenting frame entry and exit, not function entry and exit, so it probably needs renamimg.

There are many other possible static markers that could be implemented, but it's probably easiest to do this one first, then add more later (We brainstormed some ideas here: https://fedoraproject.org/wiki/Features/SystemtapStaticProbes#Python )

In my Fedora rpm packages I also supply a "tap set" (a kind of SystemTap module, for code reuse), that modularizes parts of the tracing above to minimize boilerplate when writing a .stp script that uses the markers.
This can be seen here: http://cvs.fedoraproject.org/viewvc/rpms/python/devel/libpython.stp?view=markup

I also include an example script, which can be seen here:
http://cvs.fedoraproject.org/viewvc/rpms/python/devel/systemtap-example.stp?view=markup


Hope this is helpful; sorry if this is muddying the waters further :(
Dave

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Fri Feb 26 21:51:33 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 26 Feb 2010 20:51:33 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1267217493.39.0.0858163422602.issue4111@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Attached is the patch I'm currently applying in Fedora 13 to Python 3.

The patch is actually against the 3.1.1 tarball, rather than SVN; sorry (swamped with post-pycon tasks here), as that's what I've been testing this work against.

The patch is somewhat different to the Python 2 case, in that the filename and module name are stored internally by Python as unicode.  The markers convert these to UTF8 for the case when the markers are in use by an active probe.  Unfortunately it's now possible for this to fail (e.g. low memory).

An example of using this for a non-Latin 1 script can be seen towards the end of:
https://fedoraproject.org/wiki/Features/SystemtapStaticProbes#Python_2

----------
Added file: http://bugs.python.org/file16383/python-3.1.1-systemtap.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Fri Feb 26 22:17:29 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 26 Feb 2010 21:17:29 +0000
Subject: [issue6631] urlparse.urlunsplit() can't handle relative files (for
	urllib*.open()
In-Reply-To: <1249306383.87.0.829314243328.issue6631@psf.upfronthosting.co.za>
Message-ID: <1267219049.36.0.754939050502.issue6631@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

The bug here seems to me that urllib.urlopen() should not allow a relative file path like the one specified. f='./rel/path/to/file.html
urllib2's behavior seems proper that it is raising an Exception.

According to the RFCs the local files are to be acceessed by:
file://localhost/path/to/file
file:///path/to/file

Both are absolute paths to the file where in the second one localhost is omitted.

Let me see if urllib's urlopen be made a little stricter.

----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6631>
_______________________________________

From report at bugs.python.org  Fri Feb 26 23:54:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Feb 2010 22:54:01 +0000
Subject: [issue7449] A number tests "crash" if python is compiled
	--without-threads
In-Reply-To: <1260120932.34.0.0390001299533.issue7449@psf.upfronthosting.co.za>
Message-ID: <1267224841.19.0.531646354322.issue7449@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Comments about nothreads.patch. There are unrelated changes:

Lib/test/test_xmlrpc.py:
-        p = xmlrpclib.ServerProxy(URL, transport=t)
+        p = xmlrpclib.ServerProxy('http:', transport=t)

Lib/test/test_macostools.py	(working copy)
-        try:
-            os.unlink(TESTFN2)
-        except:
-            pass

Or you should explain me why you changed that :-)

Why not using test_support.import_module('threading') in test_xmlrpc.py, test_file2k.py, etc.?

I don't like importing a module in a function: you should use test_support.import_module('threading') in test_io.py, test_logging.py, test_capi.py, etc.

skip_if_no() function name is a little bit too generic. I don't have any suggestion.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7449>
_______________________________________

From report at bugs.python.org  Sat Feb 27 05:11:11 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Sat, 27 Feb 2010 04:11:11 +0000
Subject: [issue7245] better Ctrl-C support in pdb (program can be resumed)
In-Reply-To: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
Message-ID: <1267243871.19.0.925645934825.issue7245@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

Another iteration of the patch. Now sigint_handler will generate 
KeyboardInterrupts when pdb is in the commandloop

I think this guarantees consistent "Ctrl-C interrupts the current pdb action" behavior and the program is still resumable.

The "commands" command required a bit of special handling to unroll the changes if KbdInt happens.

The patch was tested on Linux and Vista.

----------
Added file: http://bugs.python.org/file16384/sig.patch.v2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7245>
_______________________________________

From report at bugs.python.org  Sat Feb 27 10:25:02 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 27 Feb 2010 09:25:02 +0000
Subject: [issue6471] errno and strerror attributes incorrectly set on socket
	errors wrapped by urllib
In-Reply-To: <1247432074.99.0.825435411389.issue6471@psf.upfronthosting.co.za>
Message-ID: <1267262702.45.0.403524213706.issue6471@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Can this be fixed without breaking compatibility?
It also affects Python2.7 and maybe also Python 3.x (there the error is different and might be intentional).

Copy/pastable snippet to reproduce the error on 2.x:
from urllib import urlopen
try:
    urlopen('http://www.pythonfoobarbaz.org')
except Exception, err:
    print 'err:', err
    print 'repr(err):', repr(err)
    print 'err.errno:', err.errno
    print 'err.strerror:', err.strerror
    print 'err.strerror.errno:', err.strerror.errno
    print 'err.strerror.strerror:', err.strerror.strerror

Result on 2.7:
err: [Errno socket error] [Errno -2] Name or service not known
repr(err): IOError('socket error', gaierror(-2, 'Name or service not known'))
err.errno: socket error
err.strerror: [Errno -2] Name or service not known
err.strerror.errno: -2
err.strerror.strerror: Name or service not known


Copy/pastable snippet to reproduce the error on 3.x:
from urllib.request import urlopen
try:
    urlopen('http://www.pythonfoobarbaz.org')
except Exception as exc:
    err = exc
    print('err:', err)
    print('repr(err):', repr(err))
    print('err.errno:', err.errno)
    print('err.strerror:', err.strerror)
    print('err.reason:', err.reason)
    print('err.reason.errno:', err.reason.errno)
    print('err.reason.strerror:', err.reason.strerror)

Result on 3.2:
err: <urlopen error [Errno -2] Name or service not known>
repr(err): URLError(gaierror(-2, 'Name or service not known'),)
err.errno: None
err.strerror: None
err.reason: [Errno -2] Name or service not known
err.reason.errno: -2
err.reason.strerror: Name or service not known

----------
nosy: +orsenthil
stage:  -> needs patch
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6471>
_______________________________________

From report at bugs.python.org  Sat Feb 27 10:48:50 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 27 Feb 2010 09:48:50 +0000
Subject: [issue6519] Reorder 'with' statement for files in Python Tutorial
In-Reply-To: <1247966369.75.0.40232300258.issue6519@psf.upfronthosting.co.za>
Message-ID: <1267264130.84.0.480222455443.issue6519@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

All the examples there assume that "a file object called f has already been created". Using a 'with' there it's not a good idea because the users will have to keep the instructions indented under the 'with'.
However I agree that it would be better to move that example earlier. Maybe in 7.2 both the forms can be shown and discussed briefly.

----------
stage:  -> needs patch
versions:  -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6519>
_______________________________________

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: [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 17:23:10 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 27 Feb 2010 16:23:10 +0000
Subject: [issue7793] regrtest fails with "RuntimeError: maximum recursion
	depth exceeded" in some cases
In-Reply-To: <1264551337.94.0.106347277141.issue7793@psf.upfronthosting.co.za>
Message-ID: <1267287790.05.0.411084696768.issue7793@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed in r78497.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7793>
_______________________________________

From report at bugs.python.org  Sat Feb 27 17:33:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 27 Feb 2010 16:33:27 +0000
Subject: [issue4199] add shorthand global and nonlocal statements
In-Reply-To: <1224887535.03.0.272495603252.issue4199@psf.upfronthosting.co.za>
Message-ID: <1267288407.89.0.599773176971.issue4199@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I do think a brief discussion after the moratorium is over would be good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4199>
_______________________________________

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: [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 mal at egenix.com  Mon Feb 22 23:02:32 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Mon, 22 Feb 2010 23:02:32 +0100
Subject: [issue1097797] Encoding for Code Page 273 used by EBCDIC Germany
	Austria
In-Reply-To: <1266875028.26.0.0093755927568.issue1097797@psf.upfronthosting.co.za>
References: <1266875028.26.0.0093755927568.issue1097797@psf.upfronthosting.co.za>
Message-ID: <4B82FEF8.2050105@egenix.com>

A.M. Kuchling wrote:
> 
> A.M. Kuchling <lists at amk.ca> added the comment:
> 
> I tried figuring out to rebuild the codecs using the scripts in Tools/unicode/ but failed.  Is the use of that directory documented anywhere?

See the Makefile in that directory - that's what I use to build the
codecs.

If you just want to create a single codec, have a look at the
gencodec.py module doc-string.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Feb 22 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

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: [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 01:45:55 2010
From: report at bugs.python.org (Meador Inge)
Date: Sun, 28 Feb 2010 00:45:55 +0000
Subject: [issue7232] Support of 'with' statement fo TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1267317955.52.0.000300269584206.issue7232@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> What about changing the exception test to something like what I did in > issue7232.4.diff?

That is definitely more succinct, but Lars' solution provides more information about _why_ the test fails.  IMHO, the descriptiveness is
more important than succinctness.  Especially when debugging a failed
test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________

From report at bugs.python.org  Sun Feb 28 01:46:19 2010
From: report at bugs.python.org (Ryan Coyner)
Date: Sun, 28 Feb 2010 00:46:19 +0000
Subject: [issue7162] 2to3 does not convert __builtins__.file
In-Reply-To: <1255814979.41.0.0993610579435.issue7162@psf.upfronthosting.co.za>
Message-ID: <1267317979.45.0.259473561047.issue7162@psf.upfronthosting.co.za>


Ryan Coyner <rcoyner at gmail.com> added the comment:

Patch attached. Unit test and documentation included.

COMMITMSG:

Adds a new fixer to lib2to3 which replaces the deprecated builtin "file" with "open".

----------
keywords: +patch
nosy: +rcoyner
Added file: http://bugs.python.org/file16392/issue7162.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7162>
_______________________________________

From report at bugs.python.org  Sun Feb 28 02:21:08 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 28 Feb 2010 01:21:08 +0000
Subject: [issue7232] Support of 'with' statement fo TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1267320068.64.0.818897936076.issue7232@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Good point. How about version 5? It uses base Exception in the context manager, which will allow us to differentiate between no exception being raised, and the wrong one being raised. After the context manager, we check the type of the exception to make sure it's correct.

I changed the exception being raised to an IOError. It could be anything, but given that AssertionError is what gets raised by the assert functions, it seemed better to avoid that one specifically. This is fairly minor, though.

If you change the "raise IOError" to be a pass statement, or another type of exception, you can see that the same level of information is given to you as in patch version 3 by Lars.

----------
Added file: http://bugs.python.org/file16394/issue7232.5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________

From report at bugs.python.org  Sun Feb 28 06:27:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Feb 2010 05:27:52 +0000
Subject: [issue7232] Support of 'with' statement fo TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1267334872.83.0.107856536793.issue7232@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello

Minor note: I think magic methods shouldn?t have docstrings, because their name is enough doc (or at least enough to go read the doc). At most a one-line comment like ?context protocol? can be useful. (The exception is __init__, which doesn?t have a defined set of arguments.)

Cheers

----------
nosy: +merwok

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________

From report at bugs.python.org  Sun Feb 28 10:01:20 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 28 Feb 2010 09:01:20 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1267347680.21.0.908163106686.issue7242@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Using issue7242-gps01.diff on release26-maint and a freshly downloaded opensolaris 2009-06 VM test_thread, test_threading and test_subprocess all pass for me both before -and- after the patch.  Nor does the original thread_test.py cause the problem for me (meaning I'm unable to reproduce the problem in this VM in the first place so... someone else needs to)

Regardless, I altered patch_2 a bit in that diff to do what I though _PyImport_ReInitLock() should really do.  I also added the thread_unittest testcase to that diff.

% uname -a
SunOS opensolaris-vm 5.11 snv 111b i86pc i386 i86pc Solaris"

Can someone who could reproduce the problem in the first place please test that patch.

The logic change makes sense to me.  I don't know why test_threading.ThreadJoinOnShutdown.test_3_join_in_forked_from_thread would be changing behavior for you.

----------
components: +Extension Modules -Library (Lib)
priority: normal -> high
Added file: http://bugs.python.org/file16395/issue7242-gps01.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

From report at bugs.python.org  Sun Feb 28 10:02:17 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 28 Feb 2010 09:02:17 +0000
Subject: [issue7232] Support of 'with' statement fo TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1267347737.55.0.640353484625.issue7232@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Another version of the patch (issue7232.6.diff) that checks if the TarFile object is still open in the __enter__() method (plus a test for that). I removed the docstrings as Eric suggested. This is common practice in the standard library.

----------
Added file: http://bugs.python.org/file16396/issue7232.6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________

From report at bugs.python.org  Sun Feb 28 16:15:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 28 Feb 2010 15:15:04 +0000
Subject: [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: <1267370104.32.0.414507446951.issue8029@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8029>
_______________________________________

From report at bugs.python.org  Sun Feb 28 16:22:32 2010
From: report at bugs.python.org (Greg Jednaszewski)
Date: Sun, 28 Feb 2010 15:22:32 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1267370552.16.0.928269160017.issue7242@psf.upfronthosting.co.za>


Greg Jednaszewski <jednaszewski at gmail.com> added the comment:

The problem only seems to appear on Solaris 9 and earlier.  I'll try to test the updated patch tonight or tomorrow and let you know what I find.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

From report at bugs.python.org  Sun Feb 28 16:25:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 28 Feb 2010 15:25:57 +0000
Subject: [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: <1267370757.35.0.941387483931.issue7839@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Because the shell argument provides important functionality.  Or are you suggesting that passing a list implies shell=False and passing a string implies shell=True?  That is a possibility, but I think it would not be a good idea, because people will 'accidentally' get shell=True (which, you will note is *not* the default), which is less secure.  It is much better, IMO, to make people ask explicitly for the less-safe behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7839>
_______________________________________

From report at bugs.python.org  Sun Feb 28 17:12:50 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 28 Feb 2010 16:12:50 +0000
Subject: [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: <1267373570.82.0.480239826191.issue7839@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I think the better design is to have 2 distinct APIs: Popen_shell and Popen_exec. I'm not wild about the name Popen_exec, suggestions welcome. Neither of these would accept a shell parameter.

For starters these could be convenience APIs that just call Popen with the correct shell= value, and check the type of args. We could ultimately deprecate Popen itself.

I don't see a use case where you programmatically compute the value of shell: it's always known as a function of how you're building up args. And even if such a rare case exists, you could select between the two APIs to call.

Whether at this point we can make this change is another issue, of course. I'm just trying to get at the best design. But if it's done over a number of releases I think it's doable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7839>
_______________________________________

From report at bugs.python.org  Sun Feb 28 17:18:23 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 28 Feb 2010 16:18:23 +0000
Subject: [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: <1267373903.43.0.114550642991.issue7839@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

That seems reasonable. We already have subprocess.call, the thin wrapper around Popen. Maybe add this as subprocess.call_shell and call_exec?

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7839>
_______________________________________

From report at bugs.python.org  Sun Feb 28 17:30:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 28 Feb 2010 16:30:19 +0000
Subject: [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: <1267374619.41.0.710555940287.issue7839@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  I liked Eric's idea, and it would be easier to get in, but 'call' is actually an argument against it.  It would mean that in addition to PopenExec and PopenShell we'd need call_exec and call_shell, and check_call_exec and check_call_shell.  Proliferating interfaces to handle a boolean parameter doesn't seem minimalist.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7839>
_______________________________________

From report at bugs.python.org  Sun Feb 28 18:08:43 2010
From: report at bugs.python.org (Meador Inge)
Date: Sun, 28 Feb 2010 17:08:43 +0000
Subject: [issue7232] Support of 'with' statement fo TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1267376923.26.0.706010343163.issue7232@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> This is common practice in the standard library.

This doesn't necessarily mean it is a correct practice :-).  All 
kidding aside, I think the assumption that the standard documentation 
on '__enter__' and '__exit__' is sufficient is a bad one.  With respect 
to how the 'tarfile' versions of these methods behave, that 
documentation is not that helpful.

In particular, the special behavior of an 'IOError' potentially being 
thrown from '__enter__' and the fact that '__exit__' does not swallow 
the exception.  These special behaviors should be documented either in 
a docstring or the library documentation.  I think this is important, 
but I may be being a bit pedantic.

Also, the last change to 'test_context_manager_exception' has a bug. 
If the call to 'tarfile.open' throws an exception, then the call to
'self.assertRaises' will swallow it.  This will cause an undefined
variable reference to 'tar' in 'self.assertTrue(tar.closed, ...)'.  I 
attached another update that fixes this problem.

----------
Added file: http://bugs.python.org/file16398/issue7232.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________

From report at bugs.python.org  Sun Feb 28 18:50:18 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 28 Feb 2010 17:50:18 +0000
Subject: [issue7242] Forking in a thread raises RuntimeError
In-Reply-To: <1256900282.72.0.764098234436.issue7242@psf.upfronthosting.co.za>
Message-ID: <1267379418.58.0.0859454525386.issue7242@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

If you have a chance tonight that'd be awesome.  I'd love to get this in before 2.6.5rc1 (being cut tomorrow) but as its platform specific (and a pretty-old platform at that) its not worth holding up the release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7242>
_______________________________________

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: [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 19:41:25 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 28 Feb 2010 18:41:25 +0000
Subject: [issue7481] Failing to start a thread leaves "zombie" thread in
	"initial" state
In-Reply-To: <1260558940.42.0.95708502928.issue7481@psf.upfronthosting.co.za>
Message-ID: <1267382485.24.0.931565140085.issue7481@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fixed in trunk r78517 and release26-maint r78518.

still needs merging into py3k and release31-maint

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7481>
_______________________________________

From report at bugs.python.org  Sun Feb 28 20:02:39 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 28 Feb 2010 19:02:39 +0000
Subject: [issue7232] Support of 'with' statement fo TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1267383759.05.0.333941774395.issue7232@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

IMO it is okay for __enter__() and __exit__() not to have docstrings.
I cannot see what's so special about the behaviour of __enter__() and __exit__().

__enter__() raises IOError only if the TarFile object has been already closed. This is exactly the behaviour I would expect, because it is the same every other TarFile method does when the object has been closed. IOW, using a closed TarFile as a context manager is the programmer's mistake, and I don't feel the need to document that case.

The fact that __exit__() only closes the TarFile object and does not swallow exceptions is what everyone expects from a "file object". It is the only logical thing to do, no need to document that either.

The test_context_manager_exception() test is fine. If the call to tarfile.open() really raises an exception then something is so terribly wrong and probably all of the testsuite's 200 tests will fail anyway. We can safely assume here that this will work, no need to double-check.

However, I have changed the docs again to be a bit more specific.

----------
Added file: http://bugs.python.org/file16400/issue7232.8.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________

From report at bugs.python.org  Sun Feb 28 20:22:05 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 28 Feb 2010 19:22:05 +0000
Subject: [issue7481] Failing to start a thread leaves "zombie" thread in
	"initial" state
In-Reply-To: <1260558940.42.0.95708502928.issue7481@psf.upfronthosting.co.za>
Message-ID: <1267384925.0.0.016711772583.issue7481@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

r78519 r78520 for py3k and 3.1.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7481>
_______________________________________

From report at bugs.python.org  Sun Feb 28 21:07:26 2010
From: report at bugs.python.org (Hong Chen)
Date: Sun, 28 Feb 2010 20:07:26 +0000
Subject: [issue5802] The security descriptors of python binaries in Windows
	are not strict enough
In-Reply-To: <1265642584.58.0.729329564395.issue5802@psf.upfronthosting.co.za>
Message-ID: <3ec02ba21002281207r593b69e5pe5e829bb884dbe18@mail.gmail.com>


Hong Chen <cn.hongchen at gmail.com> added the comment:

Sorry for the delay, it's been a busy month.

I just tried python 3.1  If installed under c:\program files, the
access control list would be correct, only system & administrator
accounts get the modify privilege.

The default installation is to c:\python31, in which the access
control list has the issue that unprivileged users can modify it.

I guess a possible remedy to this is that after installation, the
setup program can just remove "authenticated users" from the access
control list, or at least remove the "modify" privilege from the
corresponding entry.

Thanks,
Hong

On Mon, Feb 8, 2010 at 7:23 AM, Brian Curtin <report at bugs.python.org> wrote:
>
> Brian Curtin <curtin at acm.org> added the comment:
>
> Is the situation any different if you install Python to "C:\Program Files"? This seems to be at least part of the reason IronPython installs to "C:\Program Files", which was discussed on the IronPython list [1] a few months ago.
>
>
> [1] http://lists.ironpython.com/pipermail/users-ironpython.com/2009-October/011345.html
>
> ----------
> nosy: +brian.curtin
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5802>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5802>
_______________________________________

From report at bugs.python.org  Sun Feb 28 21:23:31 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 28 Feb 2010 20:23:31 +0000
Subject: [issue7245] better Ctrl-C support in pdb (program can be resumed)
	(issue216067)
In-Reply-To: <1257017877.16.0.972733875092.issue7245@psf.upfronthosting.co.za>
Message-ID: <001636c5c297cf24040480aebe93@google.com>


Gregory P. Smith <greg at krypto.org> added the comment:

Reviewers: gregory.p.smith, Benjamin, ilya.sandler,

Message:
Also, can you take a look at how the pdb unittests work and see if you
can come up with a way to unittest the KeyboardInterrupt behavior?

Particular for the 4 scenarios you outlined in your prior comments in
the bug (those all make sense to me).

http://codereview.appspot.com/216067/diff/2001/2002
File Lib/pdb.py (right):

http://codereview.appspot.com/216067/diff/2001/2002#newcode63
Lib/pdb.py:63: def sigint_handler(self, signum, frame):
Please move this below the __init__ definition.  It makes classes odd to
read when __init__ isn't the first method defined when people are
looking for the constructor to see how to use it.

http://codereview.appspot.com/216067/diff/2001/2002#newcode64
Lib/pdb.py:64: if self.allow_kbdint:
Initialize self.allow_kdbint in __init__ so that a SIGINT coming in
before _cmdloop has run doesn't cause an AttributeError.

http://codereview.appspot.com/216067/diff/2001/2002#newcode215
Lib/pdb.py:215: # keyboard interrupts allow for an easy way to interrupt
"to cancel the current command"

http://codereview.appspot.com/216067/diff/2001/2002#newcode356
Lib/pdb.py:356: #it appears that that when pdb is reading input from a
pipe
Space after the # please.

Also, could you add a comment in here describing what the effect of this
code is?

It looks like you catch KeyboardInterrupt here and remove the particular
interrupted command from the list of commands to run at the current
breakpoint but I may be misreading things as I haven't spent much time
in pdb.py.

Please review this at http://codereview.appspot.com/216067/show

Affected files:
   M     Lib/pdb.py

Index: Lib/pdb.py
===================================================================
--- Lib/pdb.py	(revision 78520)
+++ Lib/pdb.py	(working copy)
@@ -13,8 +13,10 @@
  import re
  import pprint
  import traceback
+import signal

+
  class Restart(Exception):
      """Causes a debugger to be restarted for the debugged python  
program."""
      pass
@@ -58,6 +60,13 @@

  class Pdb(bdb.Bdb, cmd.Cmd):

+    def sigint_handler(self, signum, frame):
+        if self.allow_kbdint:
+            raise KeyboardInterrupt()
+        print >>self.stdout, "\nProgram interrupted. (Use 'cont' to  
resume)."
+        self.set_step()
+        self.set_trace(frame)
+
      def __init__(self, completekey='tab', stdin=None, stdout=None,  
skip=None):
          bdb.Bdb.__init__(self, skip=skip)
          cmd.Cmd.__init__(self, completekey, stdin, stdout)
@@ -72,6 +81,7 @@
              import readline
          except ImportError:
              pass
+        signal.signal(signal.SIGINT, self.sigint_handler)

          # Read $HOME/.pdbrc and ./.pdbrc
          self.rcLines = []
@@ -176,7 +186,7 @@
              if not self.commands_silent[currentbp]:
                  self.print_stack_entry(self.stack[self.curindex])
              if self.commands_doprompt[currentbp]:
-                self.cmdloop()
+                self._cmdloop()
              self.forget()
              return
          return 1
@@ -199,11 +209,22 @@
          self.interaction(frame, exc_traceback)

      # General interaction function
+    def _cmdloop(self):
+        while 1:
+            try:
+                # keyboard interrupts allow for an easy way to interrupt
+                # cancel current command
+                self.allow_kbdint = True
+                self.cmdloop()
+                self.allow_kbdint = False
+                break
+            except KeyboardInterrupt:
+                print >>self.stdout, '--KeyboardInterrupt--'

      def interaction(self, frame, traceback):
          self.setup(frame, traceback)
          self.print_stack_entry(self.stack[self.curindex])
-        self.cmdloop()
+        self._cmdloop()
          self.forget()

      def displayhook(self, obj):
@@ -329,9 +350,18 @@
          prompt_back = self.prompt
          self.prompt = '(com) '
          self.commands_defining = True
-        self.cmdloop()
-        self.commands_defining = False
-        self.prompt = prompt_back
+        try:
+            self.cmdloop()
+        except (KeyboardInterrupt, IOError):
+            #it appears that that when pdb is reading input from a pipe
+            # we may get IOErrors, rather than KeyboardInterrupt
+            self.commands.pop(bnum)   # remove this cmd list
+            self.commands_doprompt.pop(bnum)
+            self.commands_silent.pop(bnum)
+            raise KeyboardInterrupt()
+        finally:
+            self.commands_defining = False
+            self.prompt = prompt_back

      def do_break(self, arg, temporary = 0):
          # break [ ([filename:]lineno | function) [, "condition"] ]

----------
title: better Ctrl-C support in pdb (program can be resumed) -> better Ctrl-C support in pdb (program can be resumed) (issue216067)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7245>
_______________________________________

From report at bugs.python.org  Sun Feb 28 22:05:27 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 28 Feb 2010 21:05:27 +0000
Subject: [issue7232] Support of 'with' statement fo TarFile class
In-Reply-To: <1256801380.63.0.851981428593.issue7232@psf.upfronthosting.co.za>
Message-ID: <1267391127.7.0.971907729375.issue7232@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I found an issue that needs to be addressed: if there is an error while the TarFile object is opened for writing, we cannot simply call TarFile.close() in the __exit__() method. close() would try to finalize the archive, i.e. write two zero end-of-archive blocks and a number of padding blocks.

I changed __exit__() to call close() only if everything went fine. If there was an exception only the most basic cleanup is done.

I added more tests and adapted the docs.

----------
Added file: http://bugs.python.org/file16401/issue7232.9.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7232>
_______________________________________

From report at bugs.python.org  Sun Feb 28 23:04:41 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 28 Feb 2010 22:04:41 +0000
Subject: [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: <1267394681.79.0.928084321635.issue7832@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fwiw - The documentation was updated in trunk, py3k and release31-maint to mention this behavior of assertSameElements.

Assigning to Michael for a decision on whether or not to add to the API.

python-unittest-backport has since been supplanted by Michael's http://pypi.python.org/pypi/unittest2/.

----------
assignee: gregory.p.smith -> michael.foord
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7832>
_______________________________________

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: [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>