From report at bugs.python.org  Wed Aug  1 00:08:23 2012
From: report at bugs.python.org (Taihyun Hwang)
Date: Tue, 31 Jul 2012 22:08:23 +0000
Subject: [New-bugs-announce] [issue15517] Minor trimming for ASDL parser
Message-ID: <1343772503.75.0.788965811369.issue15517@psf.upfronthosting.co.za>


New submission from Taihyun Hwang:

Attached patch enables ASDL parser to construct fields in the right order.

It resolves the issue below in Parser/asdl.py
# XXX can't I just construct things in the right order?

We can safely use left-recursive grammar since Parser/spark.py implements Earley parser.


The patch doesn't affect Python-ast.[ch] as expected.

$ make Include/Python-ast.h Python/Python-ast.c
$ diff -s ~/test/Python-ast.h Include/Python-ast.h
Files /home/xenosoz/test/Python-ast.h and Include/Python-ast.h are identical
$ diff -s ~/test/Python-ast.c Python/Python-ast.c
Files /home/xenosoz/test/Python-ast.c and Python/Python-ast.c are identical


Time consumption before/after the patch:
-- before patch --
time make Include/Python-ast.h
real    0m0.578s \ user    0m0.500s \ sys     0m0.060s

time make Python/Python-ast.c
real    0m0.687s \ user    0m0.620s \ sys     0m0.050s

-- after patch --
$ time make Include/Python-ast.h
real    0m0.588s \ user    0m0.510s \ sys     0m0.060s

$ time make Python/Python-ast.c
real    0m0.677s \ user    0m0.630s \ sys     0m0.030s


It touches:
Misc/ACKS
Parser/asdl.py

----------
components: Interpreter Core
files: asdl1.patch
keywords: patch
messages: 167056
nosy: taihyun.hwang
priority: normal
severity: normal
status: open
title: Minor trimming for ASDL parser
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file26631/asdl1.patch

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

From report at bugs.python.org  Wed Aug  1 04:02:13 2012
From: report at bugs.python.org (Chris Calloway)
Date: Wed, 01 Aug 2012 02:02:13 +0000
Subject: [New-bugs-announce] [issue15518] Provide test coverage for
	filecmp.dircmp.report methods.
Message-ID: <1343786533.33.0.657671203467.issue15518@psf.upfronthosting.co.za>


New submission from Chris Calloway:

The filecmp module has no tests for the following methods of the dircmp class:

report()
report_partial_closure()
report_full_closure()

The attached patch provides those tests. This issue was suggested in issue 15454. Future plans for these tests are provided in that issue.

----------
components: Tests
files: test_filecmp-1.patch
keywords: patch
messages: 167070
nosy: cbc
priority: normal
severity: normal
status: open
title: Provide test coverage for filecmp.dircmp.report methods.
versions: Python 3.3
Added file: http://bugs.python.org/file26635/test_filecmp-1.patch

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

From report at bugs.python.org  Wed Aug  1 04:29:28 2012
From: report at bugs.python.org (Eric Snow)
Date: Wed, 01 Aug 2012 02:29:28 +0000
Subject: [New-bugs-announce] [issue15519] finish exposing
	WindowsRegistryImporter in importlib
Message-ID: <1343788168.67.0.343499108562.issue15519@psf.upfronthosting.co.za>


New submission from Eric Snow:

1. add to importlib.machinery
2. register on importlib.abc.Finder

patch in a moment.

----------
components: Interpreter Core
keywords: needs review
messages: 167074
nosy: brett.cannon, eric.snow, loewis
priority: normal
severity: normal
stage: patch review
status: open
title: finish exposing WindowsRegistryImporter in importlib
versions: Python 3.3

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

From report at bugs.python.org  Wed Aug  1 09:45:57 2012
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 01 Aug 2012 07:45:57 +0000
Subject: [New-bugs-announce] [issue15520] Document datetime.timestamp() in
	3.3 What's New
Message-ID: <1343807157.88.0.373148573533.issue15520@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman:

It seems nice if datetime.timestamp() would be mentioned in the What's New. Does that seem acceptable? I'm happy to whip up a patch.

----------
assignee: docs at python
components: Documentation
messages: 167096
nosy: djc, docs at python
priority: normal
severity: normal
status: open
title: Document datetime.timestamp() in 3.3 What's New
versions: Python 3.3

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

From report at bugs.python.org  Wed Aug  1 11:07:48 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 01 Aug 2012 09:07:48 +0000
Subject: [New-bugs-announce] [issue15521] Dev Guide should say how to run
	tests in 2.7
Message-ID: <1343812068.2.0.0173567393654.issue15521@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The Dev Guide should say the preferred way (or even a way) to run tests using the Python 2.7 build:

http://docs.python.org/devguide/runtests.html

This will help submitters who want to check that their patch works with 2.7.

In Python 2.7, this did not work (for obvious reasons):

$ ./python.exe -m test
.../python.exe: No module named test.__main__; 'test' is a package and cannot be directly executed

But this did:

$ ./python.exe -m test.regrtest

Is the latter the preferred way?

----------
assignee: docs at python
components: Devguide, Documentation
keywords: easy
messages: 167099
nosy: cjerdonek, docs at python, ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: Dev Guide should say how to run tests in 2.7

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

From report at bugs.python.org  Wed Aug  1 11:33:52 2012
From: report at bugs.python.org (abael)
Date: Wed, 01 Aug 2012 09:33:52 +0000
Subject: [New-bugs-announce] [issue15522] impove 27 percent performance on
	stringpbject.c( by	prefetch and loop optimization)
Message-ID: <1343813632.92.0.115452555082.issue15522@psf.upfronthosting.co.za>


New submission from abael:

Python-2.7.3/Objects/stringobject.c( SHA256SUM ad7795c75e2a25247e4dea4cc5327c225c4da03b7c7d57226c817ba6d12a316c)
static PyObject *string_join(PyStringObject *self, PyObject *orig);

OLD IMPLEMENT LOGIC(Pseudo code):
        char *sep = PyString_AS_STRING(self);
        const Py_ssize_t seplen = PyString_GET_SIZE(self);

        seq = PySequence_Fast(orig, "");
        seqlen = PySequence_Size(seq);

        if (seqlen == 0)
            return PyString_FromString("");
        else if (seqlen == 1)return the exactly first one item;
        else{
            for (i = 0; i < seqlen; i++) {
                const size_t old_sz = sz;
                item = PySequence_Fast_GET_ITEM(seq, i);
                if (!PyString_Check(item)){
                   if ( Py_USING_UNICODE and PyUnicode_Check(item))
                        return PyUnicode_Join((PyObject *)self, seq);
                   else  PyErr_Format(...);
                }
                sz += PyString_GET_SIZE(item);

                if (i != 0)
                    sz += seplen;
            }
        }

        /* Allocate result space. */
        res = PyString_FromStringAndSize((char*)NULL, sz);

        /* Catenate everything. */
        p = PyString_AS_STRING(res);
        for (i = 0; i < seqlen; ++i) {
            size_t n;
            item = PySequence_Fast_GET_ITEM(seq, i);
            n = PyString_GET_SIZE(item);
            Py_MEMCPY(p, PyString_AS_STRING(item), n);
            p += n;
            if (i < seqlen - 1) {
                Py_MEMCPY(p, sep, seplen);
                p += seplen;
            }
        }




Abael's IMPLEMENT LOGIC:
        char *sep = PyString_AS_STRING(self);
        const Py_ssize_t seplen = PyString_GET_SIZE(self);

        seq = PySequence_Fast(orig, "");
        seqlen = PySequence_Size(seq);

        if (seqlen == 0)
            return PyString_FromString("");
        if (seqlen == 1)
            return the exactly first one item;

        if (seqlen <0)return NULL

         /**** PREFETCH start, get the first item size, since here we can assume seqleng >= 2 ****/
        register size_t sz=0;
        register size_t old_sz=0;
        PyObject *res = NULL;

        item = PySequence_Fast_GET_ITEM(seq, 0);
        if (!PyString_Check(item)){
           if ( Py_USING_UNICODE and PyUnicode_Check(item))
                return PyUnicode_Join((PyObject *)self, seq);
           else  PyErr_Format(...);
        }

        sz += PyString_GET_SIZE(item);
        if (sz < old_sz || sz > PY_SSIZE_T_MAX) PyErr_SetString(PyExc_OverflowError,"join() result is too long for a Python string");
         /**** PREFETCH end, get the first item size, since here we can assume seqleng >= 2 ****/

        register Py_ssize_t i;
        for (i=1; i < seqlen; i++) { /**** then here we can loop start from 1 ****/
            const size_t old_sz = sz;
            item = PySequence_Fast_GET_ITEM(seq, i);
            if (!PyString_Check(item)){
               if ( Py_USING_UNICODE and PyUnicode_Check(item))
                    return PyUnicode_Join((PyObject *)self, seq);
               else  PyErr_Format(...);
            }
            sz += PyString_GET_SIZE(item);
            sz += seplen; /**** now we don't need to test (i != 0) every loop ****/
        }

        /* Allocate result space. */
        res = PyString_FromStringAndSize((char*)NULL, sz);

        /* Catenate everything. */
        /**** PREFETCH start, memcpy the first item first, since here we can assume seqleng >= 2 ****/
        register char *p = PyString_AS_STRING(res);
        item = PySequence_Fast_GET_ITEM(seq, 0);
        sz = PyString_GET_SIZE(item);
        Py_MEMCPY(p, PyString_AS_STRING(item),sz);
        p += sz;
        /**** PREFETCH end, memcpy the first item first, since here we can assume seqleng >= 2 ****/

        for (i=1; i<seqlen; ++i){ /**** here we also loop start from 1 ****/
            item = PySequence_Fast_GET_ITEM(seq, i);
            sz = PyString_GET_SIZE(item);
            Py_MEMCPY(p, sep, seplen); /**** avoid test (i < seqlen - 1) each loop in old implement ****/ 
            p += seplen;
            Py_MEMCPY(p, PyString_AS_STRING(item),sz);
            p += sz;
        }
        return res;

----------
components: Library (Lib)
messages: 167107
nosy: abael
priority: normal
severity: normal
status: open
title: impove 27 percent performance on stringpbject.c( by prefetch and loop optimization)
type: performance
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug  1 12:07:48 2012
From: report at bugs.python.org (Jarvis)
Date: Wed, 01 Aug 2012 10:07:48 +0000
Subject: [New-bugs-announce] [issue15523] Block on close TCP socket in
	SocketServer.py
Message-ID: <1343815668.28.0.0910478510187.issue15523@psf.upfronthosting.co.za>


New submission from Jarvis:

In the Python 2.4, it closes the socket only by calling request.close() method. There is a risk by using this method to close socket. If the socket handle count does not reach zero because another process still has a handle to the socket then the connection is not closed and the socket is not deallocated. So in Python 2.7 it updates it by calling request.shutdown() first, which can close the underlying connection and send a FIN/EOF to the peer regardless of how many processes have handles to the socket. After that, it calls request.close() to deallocate the socket. You can see this updates below that is from the file of C:\Python27\Lib\SocketServer.py.

    def shutdown_request(self, request):
        """Called to shutdown and close an individual request."""
        try:
            #explicitly shutdown.  socket.close() merely releases
            #the socket and waits for GC to perform the actual close.
            request.shutdown(socket.SHUT_WR)
        except socket.error:
            pass #some platforms may raise ENOTCONN here
        self.close_request(request)

However,it will block at self.close_request(request) after request.shutdown(socket.SHUT_WR) if there are remaining data on reading side of socket.

Here, it calls request.shutdown() with SHUT_WR flag, which means it only shuts down the writing side of the socket. The reading side of the socket isn't shut down at same time. So when calling close_request to deallocate the socket, it will always be waiting to read response until response data is available. It seems like an issue in SokcetServer.py library.

In terms of that, I replaced the SHUT_WR flag with SHUT_RDWR (shut down both reading and writing sides of the socket) for request.shutdown method. Then this issue was resolved, the SSL connection was closed immediately.

----------
messages: 167110
nosy: jarvisliang
priority: normal
severity: normal
status: open
title: Block on close TCP socket in SocketServer.py
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug  1 14:05:31 2012
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Wed, 01 Aug 2012 12:05:31 +0000
Subject: [New-bugs-announce] [issue15524] Dict items() ordering varies
	across interpreter	invocations
Message-ID: <1343822731.32.0.0425809167964.issue15524@psf.upfronthosting.co.za>


New submission from Dmitry Dvoinikov:

The following line prints different things each time you run it:

python3 -c "print(', '.join({ '1': '2', '3': '4' }.keys()))"

The output is either "1, 3" or "3, 1". Is such indeterministic behavior intentional ?

Using Python 3.3.0b1 (default, Aug  1 2012, 06:09:44)

----------
components: Interpreter Core
messages: 167116
nosy: ddvoinikov
priority: normal
severity: normal
status: open
title: Dict items() ordering varies across interpreter invocations
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Aug  1 15:17:40 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 01 Aug 2012 13:17:40 +0000
Subject: [New-bugs-announce] [issue15525] test_multiprocessing failure on
	Windows XP
Message-ID: <1343827060.29.0.756371915694.issue15525@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

test_multiprocessing failed on one of the XP buildbots with a permission error:

http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/7223/steps/test/logs/stdio

The immediate rerun also failed, but the one at the end of the test run succeeded.

----------
components: Library (Lib)
keywords: buildbot
messages: 167125
nosy: georg.brandl, ncoghlan, sbt
priority: release blocker
severity: normal
stage: needs patch
status: open
title: test_multiprocessing failure on Windows XP
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Aug  1 15:30:04 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 01 Aug 2012 13:30:04 +0000
Subject: [New-bugs-announce] [issue15526] regrtest crash on Windows 7 AMD64
Message-ID: <1343827804.07.0.425515249327.issue15526@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

regrtest bailed out completely on one of the Windows 7 builders due to a problem with accessing the temporary working directory:

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/410/steps/test/logs/stdio

It's seems a touch suspicious that test_fork1 just so happened to be the test executed right before test_startfile blew up.

Not marking as a blocker yet, since my initial assumption is that it's a race condition with a particular sequence of tests rather than a problem in Python itself. I'll change my mind if it happens again on the rebuild I just forced.

----------
components: Tests
keywords: buildbot
messages: 167126
nosy: georg.brandl, ncoghlan
priority: normal
severity: normal
status: open
title: regrtest crash on Windows 7 AMD64
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Wed Aug  1 17:05:57 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 01 Aug 2012 15:05:57 +0000
Subject: [New-bugs-announce] [issue15527] Double parents in functions
	references
Message-ID: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

:c:func:`PyMem_Malloc(n)` on Doc/c-api/memory.rst:109 rendered in HTML as <tt class="xref c c-func docutils literal"><span class="pre">PyMem_Malloc(1)()</span></tt> (note double parents). There are many other examples on this and other pages. The issue is actual for all modern versions of Python.

----------
assignee: docs at python
components: Documentation
messages: 167137
nosy: docs at python, storchaka
priority: normal
severity: normal
status: open
title: Double parents in functions references
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Aug  1 18:18:47 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 01 Aug 2012 16:18:47 +0000
Subject: [New-bugs-announce] [issue15528] Better support for finalization
	with weakrefs
Message-ID: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za>


New submission from Richard Oudkerk:

A patch with docs and tests for the idea I suggested on python-ideas:

    http://comments.gmane.org/gmane.comp.python.ideas/15863

To repeat what I wrote there, the current issues with weakref callbacks include:

1. They are rather low level, and working out how to use them
   correctly requires a bit of head scratching.  One must find
   somewhere to store the weakref till after the referent is dead, and
   without accidentally keeping the referent alive.  Then one must
   ensure that the callback frees the weakref (without leaving any
   remnant ref-cycles).

   When it is an option, using a __del__ method is far less hassle.

2. Callbacks invoked during interpreter shutdown are troublesome.  For
   instance they can throw exceptions because module globals have been
   replaced by None.

3. Sometimes you want the callback to be called at program exit even
   if the referent is still alive.

4. Exceptions thrown in callbacks do not produce a traceback.  This
   can make debugging rather awkward.  (Maybe this is because printing
   tracebacks is problematic during interpreter shutdown?)

(Note that problems 2-4 also apply to using __del__ methods.)

Trivial usage of the class looks like

    >>> class Kenny: pass
    ...
    >>> kenny = Kenny()
    >>> finalize(kenny, print, "you killed kenny!")
    <finalize.finalize object at 0xffed4f2c>
    >>> del kenny
    you killed kenny!

----------
files: finalize.patch
keywords: patch
messages: 167142
nosy: sbt
priority: normal
severity: normal
stage: patch review
status: open
title: Better support for finalization with weakrefs
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26649/finalize.patch

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

From report at bugs.python.org  Wed Aug  1 18:40:31 2012
From: report at bugs.python.org (Tom Tromey)
Date: Wed, 01 Aug 2012 16:40:31 +0000
Subject: [New-bugs-announce] [issue15529] PyIter_Check evaluates to 0 for
	Python list object
Message-ID: <1343839231.18.0.262983756093.issue15529@psf.upfronthosting.co.za>


New submission from Tom Tromey:

I was debugging this bug reported against gdb:

http://sourceware.org/bugzilla/show_bug.cgi?id=14386

It turns out that what went wrong in this code was that
PyIter_Check evaluates to 0 when its argument is a
Python list.

This happens because the PyIter_Check macro looks at the
tp_iternext field; but this field is 0 in PyList_Type.

I am not sure of the correct fix; but PyIter_Check is not
faithfully reflecting what PyObject_GetIter does.
Maybe it isn't intended to; but anyway it seems that
checking tp_iter would maybe be a better approximation.

Even if PyIter_Check remains as-is, I think it would be nice
if the documentation were more specific about what it
actually does.

FWIW I'm modifying gdb not to use this function.

----------
components: None
messages: 167143
nosy: tromey
priority: normal
severity: normal
status: open
title: PyIter_Check evaluates to 0 for Python list object
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug  1 20:19:55 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Aug 2012 18:19:55 +0000
Subject: [New-bugs-announce] [issue15530] Enhance Py_MIN and Py_MAX
Message-ID: <1343845195.3.0.786704958428.issue15530@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch enhances Py_MIN and Py_MAX to check that types of both arguments are compatible at compile time. Checks are only done if the compiler is GCC.

The patch uses also Py_MIN and Py_MAX in more places. (The commit may be done in two parts.)

----------
components: Interpreter Core
files: py_min_max.patch
keywords: patch
messages: 167161
nosy: haypo
priority: normal
severity: normal
status: open
title: Enhance Py_MIN and Py_MAX
versions: Python 3.3
Added file: http://bugs.python.org/file26651/py_min_max.patch

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

From report at bugs.python.org  Wed Aug  1 21:00:03 2012
From: report at bugs.python.org (Dave Abrahams)
Date: Wed, 01 Aug 2012 19:00:03 +0000
Subject: [New-bugs-announce] [issue15531] os.path symlink docs missing
Message-ID: <1343847603.27.0.526292718618.issue15531@psf.upfronthosting.co.za>


New submission from Dave Abrahams:

the docs for os.path don't mention the following facts which I think are important (in fact I assumed the facts would be the reverse):

os.path.realpath(l) works when l is a broken symbolic link, returning the path to the (missing) target

os.path.readlink(l) causes an error when l is a broken symbolic link.

----------
assignee: docs at python
components: Documentation
messages: 167163
nosy: dabrahams, docs at python
priority: normal
severity: normal
status: open
title: os.path symlink docs missing
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug  1 23:56:38 2012
From: report at bugs.python.org (Andy Lutomirski)
Date: Wed, 01 Aug 2012 21:56:38 +0000
Subject: [New-bugs-announce] [issue15532] "for line in file" is *still*
	broken in Python 2.7
Message-ID: <1343858198.39.0.554130035278.issue15532@psf.upfronthosting.co.za>


New submission from Andy Lutomirski:

This program:

import subprocess, sys
p = subprocess.Popen(['bash', '-c', 'while true; do echo x; sleep 1; done'], bufsize=0, stdout=subprocess.PIPE)

for line in p.stdout:
    sys.stdout.buffer.write(line)
    sys.stdout.flush()

sits around and does nothing on Python 2.7.3.  It works (i.e. prints 'x' once per second) on Python 3.

This was http://bugs.python.org/issue3907 and is supposedly fixed, but it's not.

----------
components: IO
messages: 167170
nosy: Andy.Lutomirski
priority: normal
severity: normal
status: open
title: "for line in file" is *still* broken in Python 2.7
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug  2 07:44:32 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 02 Aug 2012 05:44:32 +0000
Subject: [New-bugs-announce] [issue15533] subprocess.Popen(cwd) documentation
Message-ID: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The sentence describing Popen()'s cwd argument in the subprocess documentation seems reversed to me:

http://docs.python.org/dev/library/subprocess.html#subprocess.Popen

It says, "If cwd is not None, the child?s current directory will be changed to cwd before it is executed. Note that this directory is not considered when searching the executable, so you can?t specify the program?s path relative to cwd."

However, when cwd is not None, it seems like you *must* specify the program's path relative to cwd.  For example, when running a script containing the following using `./python.exe` from a source checkout--

    p = Popen(['./python.exe', '-V'], stdout=PIPE, stderr=PIPE, cwd='temp')
    
you get an: "OSError: [Errno 2] No such file or directory."

In contrast, when you *do* specify the program's path relative to cwd, it works--

    p = Popen(['../python.exe', '-V'], stdout=PIPE, stderr=PIPE, cwd='temp')

Issue 6374 seems to have made the same point in its second bullet, but the issue was closed without addressing that part of it.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 167194
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: subprocess.Popen(cwd) documentation
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Aug  2 11:06:37 2012
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Thu, 02 Aug 2012 09:06:37 +0000
Subject: [New-bugs-announce] [issue15534] xmlrpc escaping breaks on unicode
	\u043c
Message-ID: <1343898397.75.0.0676657128653.issue15534@psf.upfronthosting.co.za>


New submission from Dmitry Dvoinikov:

For the following script
------------------------------------
import xmlrpc.client; from xmlrpc.client import escape
text = "...\u043c......<"
print(escape(text))
------------------------------------
Python 3.3.0b1 produces
...?..&lt;...<
whereas Python 3.2
...?......&lt;

----------
components: Library (Lib)
messages: 167199
nosy: ddvoinikov
priority: normal
severity: normal
status: open
title: xmlrpc escaping breaks on unicode \u043c
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Aug  2 15:44:46 2012
From: report at bugs.python.org (Thomas Miedema)
Date: Thu, 02 Aug 2012 13:44:46 +0000
Subject: [New-bugs-announce] [issue15535] Fix pickling of named tuples in
	2.7.3
Message-ID: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za>


New submission from Thomas Miedema:

Pickling a namedtuple Point(x=10, y=20, z=30) in Python 2.7.2 with protocol level 0 would result in something like the following output:

  ccopy_reg
  _reconstructor
  p0
  (c__main__
  Point
  p1
  c__builtin__
  tuple
  p2
  (I10
  I20
  I30
  tp3
  tp4
  Rp5
  .

In Python 2.7.3, the same namedtuple dumps to:

  ccopy_reg
  _reconstructor
  p0
  (c__main__
  Point
  p1
  c__builtin__
  tuple
  p2
  (I10
  I20
  I30
  tp3
  tp4
  Rp5
  ccollections
  OrderedDict
  p6
  ((lp7
  (lp8
  S'x'
  p9
  aI10
  aa(lp10
  S'y'
  p11
  aI20
  aa(lp12
  S'z'
  p13
  aI30
  aatp14
  Rp15
  b.

Note the OrderedDictionary at the end. All data, the field names and the values, are duplicated, which can result in very large pickled files when using nested namedtuples.

Loading both dumps with CPython 2.7.3 works. This is why this bug was not noticed any earlier. Loading the second dump with CPython or pypy 2.7.2 does not work however. CPython 2.7.3 broke forward compatibility.

Attached is a patch with a fix. The patch makes pickled namedtuples forward compatibile with 2.7.2. This patch does not break backward compability with 2.7.3, since the extra OrderedDict data contained the same information as the tuple. 

Introduced:
http://hg.python.org/cpython/diff/26d5f022eb1a/Lib/collections.py

Also relevant:
http://bugs.python.org/issue3065

----------
components: Library (Lib)
files: namedtuple_pickle_fix.patch
keywords: patch
messages: 167215
nosy: rhettinger, thomie
priority: normal
severity: normal
status: open
title: Fix pickling of named tuples in 2.7.3
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26662/namedtuple_pickle_fix.patch

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

From report at bugs.python.org  Thu Aug  2 16:41:19 2012
From: report at bugs.python.org (Dave Abrahams)
Date: Thu, 02 Aug 2012 14:41:19 +0000
Subject: [New-bugs-announce] [issue15536] re.split doesn't respect MULTILINE
Message-ID: <1343918479.14.0.936812287244.issue15536@psf.upfronthosting.co.za>


New submission from Dave Abrahams:

This session demonstrates. See especially the very last expression evaluated

>>> s='''this is the end
s='''this is the end
... your only friend
your only friend
... the end'''
the end'''
>>> re.split('^', s, re.MULTILINE)
re.split('^', s, re.MULTILINE)
['this is the end\nyour only friend\nthe end']
>>> re.split('t', s, re.MULTILINE)
re.split('t', s, re.MULTILINE)
['', 'his is ', 'he end\nyour only friend\n', 'he end']
>>> re.split('\n', s, re.MULTILINE)
re.split('\n', s, re.MULTILINE)
['this is the end', 'your only friend', 'the end']
>>> re.split('(?<=\n)', s, re.MULTILINE)
re.split('(?<=\n)', s, re.MULTILINE)
['this is the end\nyour only friend\nthe end']
>>> re.split('^y', s, re.MULTILINE)
re.split('^y', s, re.MULTILINE)
['this is the end\nyour only friend\nthe end']
>>> re.split('$', s, re.MULTILINE)
re.split('$', s, re.MULTILINE)
['this is the end\nyour only friend\nthe end']
>>> re.split('$\n', s, re.MULTILINE)
re.split('$\n', s, re.MULTILINE)
['this is the end\nyour only friend\nthe end']
>>> re.split('\n', s, re.MULTILINE)
re.split('\n', s, re.MULTILINE)
['this is the end', 'your only friend', 'the end']
>>> re.split('^t', s, re.MULTILINE)
re.split('^t', s, re.MULTILINE)
['', 'his is the end\nyour only friend\nthe end']
>>> re.split('^t', s)
re.split('^t', s)
['', 'his is the end\nyour only friend\nthe end']
>>>

----------
components: Regular Expressions
messages: 167224
nosy: dabrahams, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.split doesn't respect MULTILINE
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug  2 16:58:57 2012
From: report at bugs.python.org (Dave Abrahams)
Date: Thu, 02 Aug 2012 14:58:57 +0000
Subject: [New-bugs-announce] [issue15537] MULTILINE confuses re.split
Message-ID: <1343919537.43.0.272512350755.issue15537@psf.upfronthosting.co.za>


New submission from Dave Abrahams:

compare the output of

$ python -c "open('/tmp/tst','w').write(100*'x\n');import re;print len(re.split('\n(?=x)', open('/tmp/tst').read()))"
100

with

$ python -c "open('/tmp/tst','w').write(100*'x\n');import re;print len(re.split('\n(?=x)', open('/tmp/tst').read(), re.MULTILINE))"
9

----------
components: Regular Expressions
messages: 167228
nosy: dabrahams, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: MULTILINE confuses re.split
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug  2 17:25:13 2012
From: report at bugs.python.org (Philipp Hagemeister)
Date: Thu, 02 Aug 2012 15:25:13 +0000
Subject: [New-bugs-announce] [issue15538] Avoid nonstandard s6_addr8
Message-ID: <1343921113.22.0.952708095298.issue15538@psf.upfronthosting.co.za>


New submission from Philipp Hagemeister:

The s6_addr8 field of in6_addr structs is nonstandard, and therefore not supported on all platforms (android in my example). cpython's socket module should use the standard s6_addr field instead.

----------
components: IO
hgrepos: 144
messages: 167233
nosy: phihag
priority: normal
severity: normal
status: open
title: Avoid nonstandard s6_addr8
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Aug  2 18:24:36 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Aug 2012 16:24:36 +0000
Subject: [New-bugs-announce] [issue15539] Fixing Tools/scripts/pindent.py
Message-ID: <1343924676.33.0.76595941249.issue15539@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which fixes some bugs in Tools/scripts/pindent.py and modernizes it with regard to the new Python features abilities that have made since 1994.

1. Now pindent works with "with".
2. Now pindent does not produce improper indentation (tabs by default for space-indented file). It uses for the end-marks indentation the same sequence of whitespaces that for start operator indentation.
3. Now pindent works with escaped newline "\\\n" at start of line and after "class" and "def".
4. Now pindent does not produce indentation for empty line.
5. Fixed one type in help message.
6. Using io.StringIO.
7. Using booleans, augmented assignments, list.pop(), with operators, etc.

----------
components: Demos and Tools
files: pindent.patch
keywords: patch
messages: 167239
nosy: storchaka
priority: normal
severity: normal
status: open
title: Fixing Tools/scripts/pindent.py
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26665/pindent.patch

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

From report at bugs.python.org  Thu Aug  2 23:10:46 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 02 Aug 2012 21:10:46 +0000
Subject: [New-bugs-announce] [issue15540] Python 3.3 and numpy
Message-ID: <1343941846.47.0.970447396436.issue15540@psf.upfronthosting.co.za>


New submission from Dave Malcolm:

I've been trying to get numpy working with Python 3.3, and to so I had to make some changes to CPython - hence I'm posting this to the Python bug tracker.

numpy pokes at the insides of PyUnicodeObject in a few places and is thus affected by the PEP 393 changes in Python 3.3

I'm attaching my latest work-in-progress patch for numpy, which mostly works (it has 3 remaining errors).

AIUI, the "numpy.str_" type subclasses PyUnicodeObject but with its own custom allocator, which takes a size (this is called in PyArray_Scalar when type_num == NPY_UNICODE).  unicode_new_subtype calls tp_alloc but passes in 0 for the size, so we can't use that.  So I had to reimplement parts of unicode creation in-place within numpy's PyArray_Scalar, copying macros from out of cpython's unicodeobject.c

The other wart is that, AIUI, numpy supports byte-swapping the values within an array, and when this is done for a unicode array, it byte-swaps the 4-byte UCS4 values.  At that point, it's unlikely that the resulting 4-byte values are below 0x10ffff, leading to various failures from inside CPython's unicode handling.

So I hacked those test from out of CPython :)   I'm attaching the diff I've got against cpython (clearly just a hack at this stage).

I may of course be misunderstanding the insides of numpy.

With these changes, the numpy test suite runs, with just these remaining errors:

======================================================================
ERROR: Ticket #16
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/numpy/core/tests/test_regression.py", line 41, in test_pickle_transposed
    b = pickle.load(f)
EOFError

======================================================================
ERROR: test_power_zero (test_umath.TestPower)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/numpy/core/tests/test_umath.py", line 139, in test_power_zero
    assert_complex_equal(np.power(zero, 0+1j), cnan)
RuntimeWarning: invalid value encountered in power

======================================================================
ERROR: Failure: ValueError (can't handle version 187 of numpy.ndarray pickle)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/nose-1.1.2-py3.3.egg/nose/failure.py", line 37, in runTest
    raise self.exc_class(self.exc_val).with_traceback(self.tb)
  File "/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/nose-1.1.2-py3.3.egg/nose/loader.py", line 232, in generate
    for test in g():
  File "/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/numpy/lib/tests/test_format.py", line 429, in test_roundtrip
    arr2 = roundtrip(arr)
  File "/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/numpy/lib/tests/test_format.py", line 420, in roundtrip
    arr2 = format.read_array(f2)
  File "/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/numpy/lib/format.py", line 449, in read_array
    array = pickle.load(fp)
ValueError: can't handle version 187 of numpy.ndarray pickle

----------------------------------------------------------------------
Ran 4776 tests in 68.189s

FAILED (KNOWNFAIL=6, SKIP=1, errors=3)

----------
components: Interpreter Core
files: get-numpy-working-with-python-3.3.patch
keywords: patch
messages: 167256
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: Python 3.3 and numpy
versions: Python 3.3
Added file: http://bugs.python.org/file26668/get-numpy-working-with-python-3.3.patch

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

From report at bugs.python.org  Thu Aug  2 23:52:13 2012
From: report at bugs.python.org (Ned Batchelder)
Date: Thu, 02 Aug 2012 21:52:13 +0000
Subject: [New-bugs-announce] [issue15541] logging.exception doesn't accept
	'extra'
Message-ID: <1343944333.27.0.175563876294.issue15541@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

The logging.exception method differs from .debug(), .info(), .warning(), .error() and .critical() in that it does not accept an `extra` keyword argument.  There seems to be no reason for this.

The docs are misleading about this. They say, "The arguments are interpreted as for debug()."

Changing exception() to this would take care of it::

    def exception(self, msg, *args, **kwargs):
        """
        Convenience method for logging an ERROR with exception information.
        """
        kwargs['exc_info'] = 1
        self.error(msg, *args, **kwargs)

----------
components: Library (Lib)
messages: 167260
nosy: nedbat
priority: normal
severity: normal
status: open
title: logging.exception doesn't accept 'extra'
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Aug  3 00:23:43 2012
From: report at bugs.python.org (Aaron Staley)
Date: Thu, 02 Aug 2012 22:23:43 +0000
Subject: [New-bugs-announce] [issue15542] Documentation incorrectly suggests
	__init__ called after	direct __new__ call
Message-ID: <1343946223.73.0.562621858875.issue15542@psf.upfronthosting.co.za>


New submission from Aaron Staley:

The documentation for __new__ at http://docs.python.org/reference/datamodel.html#object.__new__ is:
"""
object.__new__(cls[, ...])
Called to create a new instance of class cls. __new__() is a static method (special-cased so you need not declare it as such) that takes the class of which an instance was requested as its first argument. The remaining arguments are those passed to the object constructor expression (the call to the class). The return value of __new__() should be the new object instance (usually an instance of cls).

Typical implementations create a new instance of the class by invoking the superclass?s __new__() method using super(currentclass, cls).__new__(cls[, ...]) with appropriate arguments and then modifying the newly-created instance as necessary before returning it.

If __new__() returns an instance of cls, then the new instance?s __init__() method will be invoked like __init__(self[, ...]), where self is the new instance and the remaining arguments are the same as were passed to __new__().

If __new__() does not return an instance of cls, then the new instance?s __init__() method will not be invoked.

__new__() is intended mainly to allow subclasses of immutable types (like int, str, or tuple) to customize instance creation. It is also commonly overridden in custom metaclasses in order to customize class creation.
"""


The problem is in this line: "If __new__() returns an instance of cls, then the new instance?s __init__() method will be invoked like __init__(self[, ...]), where self is the new instance and the remaining arguments are the same as were passed to __new__()."

This is only true in the context of a constructor. In particular, directly calling cls.__new__(cls) will NOT call __init__.

If I define a class:
  
class C(object):
  def __new__(*args, **kwargs):
    print 'new', args, kwargs
    return object.__new__(*args,**kwargs)
  def __init__(self):
    print 'init'

C() will result in __new__ and __init__ being both executed, but C.__new__(C) will only create the instance of C; it will not call __init__!

The original documentation described in http://bugs.python.org/issue1123716 was more correct:

"__new__ must return an object... If you return an
existing object, the constructor call will still call
its __init__ method unless the object is an instance of
a different class..."

That is __init__ is only being called in the context of an external constructor call.  

Proposed phrasing:
"If __new__() is invoked during object construction (cls()) and it returns an instance of cls, then the new instance?s __init__() method will be invoked like __init__(self[, ...]), where self is the new instance and the remaining arguments are the same as were passed to the object constructor."

----------
assignee: docs at python
components: Documentation
messages: 167267
nosy: Aaron.Staley, docs at python
priority: normal
severity: normal
status: open
title: Documentation incorrectly suggests __init__ called after direct  __new__ call
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug  3 02:20:34 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 03 Aug 2012 00:20:34 +0000
Subject: [New-bugs-announce] [issue15543] central documentation for
	'universal newlines'
Message-ID: <1343953234.25.0.0555174882779.issue15543@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

"Universal newlines" of PEP 278 does not seem to have a central, linkable description within the documentation.  In particular, there does not seem to be a glossary entry or any index entries for it.

The main documentation seems to be in the middle of the documentation for the open() built-in function:

http://docs.python.org/dev/library/functions.html?highlight=open#open

But this does not feature prominently when searching for universal newlines in the "Quick Search".

This would allow us, for example, to reference and link to an explanation of universal newlines in the documentation for str.splitlines():

http://docs.python.org/dev/library/stdtypes.html#str.splitlines

I would be happy to provide a patch.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 167279
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: central documentation for 'universal newlines'
versions: Python 3.3

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

From report at bugs.python.org  Fri Aug  3 04:54:03 2012
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 03 Aug 2012 02:54:03 +0000
Subject: [New-bugs-announce] [issue15544] math.isnan fails with some Decimal
	NaNs
Message-ID: <1343962443.78.0.878505736017.issue15544@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

math.nan fails on some Decimal NANs. For example, while this works:

  >>> import math
  >>> from decimal import Decimal
  >>> math.isnan(Decimal('nan'))
  True

These both fail with ValueError:

  math.isnan(Decimal('snan'))
  math.isnan(Decimal('nan123'))


(Tested on Python 3.2 and 3.3.0a1)

----------
messages: 167284
nosy: stevenjd
priority: normal
severity: normal
status: open
title: math.isnan fails with some Decimal NaNs
versions: Python 3.3

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

From report at bugs.python.org  Fri Aug  3 10:07:56 2012
From: report at bugs.python.org (Pierre Le Marre)
Date: Fri, 03 Aug 2012 08:07:56 +0000
Subject: [New-bugs-announce] [issue15545] sqlite3.Connection.iterdump() does
	not work with	row_factory = sqlite3.Row
Message-ID: <1343981276.31.0.0397998065256.issue15545@psf.upfronthosting.co.za>


Changes by Pierre Le Marre <lemarre at eifer.org>:


----------
components: None
nosy: plemarre
priority: normal
severity: normal
status: open
title: sqlite3.Connection.iterdump() does not work with row_factory = sqlite3.Row
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Fri Aug  3 11:04:34 2012
From: report at bugs.python.org (David Beazley)
Date: Fri, 03 Aug 2012 09:04:34 +0000
Subject: [New-bugs-announce] [issue15546] Iteration breaks with
	bz2.open(filename, 'rt')
Message-ID: <1343984674.35.0.733492369263.issue15546@psf.upfronthosting.co.za>


New submission from David Beazley:

The bz2 library in Python3.3b1 doesn't support iteration for text-mode properly.  Example:

>>> f = bz2.open('access-log-0108.bz2')
>>> next(f)       # Works
b'140.180.132.213 - - [24/Feb/2008:00:08:59 -0600] "GET /ply/ply.html HTTP/1.1" 200 97238\n'

>>> g = bz2.open('access-log-0108.bz2','rt')
>>> next(g)       # Fails
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration
>>>

----------
components: Library (Lib)
messages: 167299
nosy: dabeaz
priority: normal
severity: normal
status: open
title: Iteration breaks with bz2.open(filename,'rt')
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Aug  3 14:13:04 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Aug 2012 12:13:04 +0000
Subject: [New-bugs-announce] [issue15547] Why do we have os.truncate() and
	os.ftruncate() whereas	os.truncate() accepts a file descriptor?
Message-ID: <1343995984.36.0.909130129312.issue15547@psf.upfronthosting.co.za>


New submission from STINNER Victor:

posix_truncate() accepts a file descriptor, so os.ftruncate() can be removed from Python 3.3.

    memset(&path, 0, sizeof(path));
    path.function_name = "truncate";
#ifdef HAVE_FTRUNCATE
    path.allow_fd = 1;
#endif
    if (!PyArg_ParseTupleAndKeywords(args, kwargs, "O&O&:truncate", keywords,
                                     path_converter, &path,
                                     _parse_off_t, &length))
        return NULL;

----------
messages: 167311
nosy: haypo, larry
priority: deferred blocker
severity: normal
status: open
title: Why do we have os.truncate() and os.ftruncate() whereas os.truncate() accepts a file descriptor?
versions: Python 3.3

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

From report at bugs.python.org  Fri Aug  3 14:26:00 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 03 Aug 2012 12:26:00 +0000
Subject: [New-bugs-announce] [issue15548] Mention all new os functions in
	What's New in Python 3.3
Message-ID: <1343996760.47.0.232563077305.issue15548@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The os module has a lot of new functions in Python 3.3. It looks like only a few are documented in What's New in Python 3.3. Examples : truncate(), ftruncate() and sync() are not mentionned.

Does Sphinx have a function to list of new functions added to Python 3.3? At least to check that the What's New in Python 3.3 is complete.

I would like to have the full list to check that new functions are consistent. See for example the issue #15547.

----------
assignee: docs at python
components: Documentation
messages: 167315
nosy: docs at python, georg.brandl, haypo, larry, rhettinger
priority: normal
severity: normal
status: open
title: Mention all new os functions in What's New in Python 3.3
versions: Python 3.3

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

From report at bugs.python.org  Fri Aug  3 17:09:36 2012
From: report at bugs.python.org (Cory Mintz)
Date: Fri, 03 Aug 2012 15:09:36 +0000
Subject: [New-bugs-announce] [issue15549] openssl version in windows builds
	does not support	renegotiation
Message-ID: <1344006576.37.0.61147044371.issue15549@psf.upfronthosting.co.za>


New submission from Cory Mintz:

The Python 2.7.3 and 2.6.8 Windows builds are both built against "OpenSSL 0.9.8l 5 Nov 2009".

This specific version of OpenSSL had renegotiation removed due a security vulnerability. Except from http://svn.python.org/projects/external/openssl-0.9.8x/NEWS.

  Major changes between OpenSSL 0.9.8l and OpenSSL 0.9.8m:
      ...
      o Support for RFC5746 TLS renegotiation extension.
      ...
  Major changes between OpenSSL 0.9.8k and OpenSSL 0.9.8l:

      o Temporary work around for CVE-2009-3555: disable renegotiation.

Can the OpenSSL version be updated to at least OpenSSL 0.9.8m so renegotiation is supported?

----------
components: Windows
messages: 167336
nosy: cory.mintz
priority: normal
severity: normal
status: open
title: openssl version in windows builds does not support renegotiation
type: enhancement
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Fri Aug  3 17:40:15 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 03 Aug 2012 15:40:15 +0000
Subject: [New-bugs-announce] [issue15550] Trailing white spaces
Message-ID: <1344008415.84.0.0454996292543.issue15550@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

My editors are configured to remove trailing spaces (this is useful for removing artifacts of indentation). The flip side of this is that my patches sometimes contain unrelated trailing spaces fixes.

Trailing spaces are not significant in any CPython source file, their presence I believe mistake. Easier once we remove all spaces and then prevent the appearance of new, than constantly face to unrelated changes. I'm not attaching a patch (it is too big, over 5 MB), anyone can create it by the following commands:

    hg status -cn | tr '\n' '\0' | xargs -0 sed -i -re 's/[ \t]+$//'

It would be good if the Mercurial would had hook, which automatically remove trailing spaces or prohibit to commit patches that contain trailing spaces.

----------
messages: 167337
nosy: storchaka
priority: normal
severity: normal
status: open
title: Trailing white spaces
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Aug  3 20:08:18 2012
From: report at bugs.python.org (Jason Baker)
Date: Fri, 03 Aug 2012 18:08:18 +0000
Subject: [New-bugs-announce] [issue15551] Unit tests that return generators
	silently fail
Message-ID: <1344017298.6.0.769704462398.issue15551@psf.upfronthosting.co.za>


New submission from Jason Baker:

The following test will pass silently:


    class SomeTest(unittest.TestCase):

      def testSomething(self):
        yield 1
        self.fail()

----------
components: None
messages: 167340
nosy: Jason.Baker
priority: normal
severity: normal
status: open
title: Unit tests that return generators silently fail
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug  3 21:11:08 2012
From: report at bugs.python.org (Dominique Leuenberger)
Date: Fri, 03 Aug 2012 19:11:08 +0000
Subject: [New-bugs-announce] [issue15552] gettext: if looking for .mo in
	default locations, also look in locale-bundle location
Message-ID: <1344021068.11.0.875930388835.issue15552@psf.upfronthosting.co.za>


New submission from Dominique Leuenberger:

Coming from openSUSE, might be a bit special, but worthy the discussion.

Background:
 - Language files are per design split off from the main application rpm (package-lang). Rational is 'space concerns for live CDs'
- We offer bundle-lang-<LANG> packages, with a set of commonly used applications translations bundled in one 'Please translate my system to LANG' RPM. Again: for the Live CD, we do bundle a limited set of language files (thus installing a subset of all .mo files provided by all packages).

=> now as rpm does not like a file at the same location to be owned by two packages, the bundle-lang-<LANG> package 'moves' it's own .mo files to /usr/share/locale-bundle, wheras the <PACKAGE>-lang rpm installs the .mo files under /usr/share/locale (default path).

Now, the issue is gettext.py checks the path proposed by the calling app using bindtextdomain(domain,[path]).

If path is defined, it's being used, otherwise /usr/share/locale is being used.

The attached patch extends the logic to:
- If path is being used
  - If path = _default_localedir
    - Check for .mo in _default_bundlelocaledir
    - if not found in bundle, check in _default_localedir
  - Use path
- if path is not defined
  - use _default_bundlelocaledir
    - if not found, use _default_localedir

=> so in any case, if default_bundlelocaledir is not used, it falls back to _default_localedir, and as such I'd argue is unintrusive and keeping the patch in upstream codebase (instead of downstream package) would make sense.

Best regards,

----------
components: Library (Lib)
files: python-bundle-lang.patch
keywords: patch
messages: 167343
nosy: Dominique.Leuenberger
priority: normal
severity: normal
status: open
title: gettext: if looking for .mo in default locations, also look in locale-bundle location
versions: Python 2.7
Added file: http://bugs.python.org/file26679/python-bundle-lang.patch

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

From report at bugs.python.org  Sat Aug  4 02:54:09 2012
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 04 Aug 2012 00:54:09 +0000
Subject: [New-bugs-announce] [issue15553] Segfault in
	test_6_daemon_threads() of test_threading, on Mac OS X Lion
Message-ID: <1344041649.82.0.110527224272.issue15553@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20Lion%203.2/builds/80/steps/test/logs/stdio

[ 54/355/1] test_threading
test_acquire_contended (test.test_threading.LockTests) ... ok
test_acquire_destroy (test.test_threading.LockTests) ... ok
test_acquire_release (test.test_threading.LockTests) ... ok
test_constructor (test.test_threading.LockTests) ... ok
test_different_thread (test.test_threading.LockTests) ... ok
test_reacquire (test.test_threading.LockTests) ... ok
test_state_after_timeout (test.test_threading.LockTests) ... ok
test_thread_leak (test.test_threading.LockTests) ... ok
test_timeout (test.test_threading.LockTests) ... ok
test_try_acquire (test.test_threading.LockTests) ... ok
test_try_acquire_contended (test.test_threading.LockTests) ... ok
test_with (test.test_threading.LockTests) ... ok
test__is_owned (test.test_threading.PyRLockTests) ... ok
test_acquire_contended (test.test_threading.PyRLockTests) ... ok
test_acquire_destroy (test.test_threading.PyRLockTests) ... ok
test_acquire_release (test.test_threading.PyRLockTests) ... ok
test_constructor (test.test_threading.PyRLockTests) ... ok
test_different_thread (test.test_threading.PyRLockTests) ... ok
test_reacquire (test.test_threading.PyRLockTests) ... ok
test_release_unacquired (test.test_threading.PyRLockTests) ... ok
test_thread_leak (test.test_threading.PyRLockTests) ... ok
test_timeout (test.test_threading.PyRLockTests) ... ok
test_try_acquire (test.test_threading.PyRLockTests) ... ok
test_try_acquire_contended (test.test_threading.PyRLockTests) ... ok
test_with (test.test_threading.PyRLockTests) ... ok
test__is_owned (test.test_threading.CRLockTests) ... ok
test_acquire_contended (test.test_threading.CRLockTests) ... ok
test_acquire_destroy (test.test_threading.CRLockTests) ... ok
test_acquire_release (test.test_threading.CRLockTests) ... ok
test_constructor (test.test_threading.CRLockTests) ... ok
test_different_thread (test.test_threading.CRLockTests) ... ok
test_reacquire (test.test_threading.CRLockTests) ... ok
test_release_unacquired (test.test_threading.CRLockTests) ... ok
test_thread_leak (test.test_threading.CRLockTests) ... ok
test_timeout (test.test_threading.CRLockTests) ... ok
test_try_acquire (test.test_threading.CRLockTests) ... ok
test_try_acquire_contended (test.test_threading.CRLockTests) ... ok
test_with (test.test_threading.CRLockTests) ... ok
test_is_set (test.test_threading.EventTests) ... ok
test_notify (test.test_threading.EventTests) ... ok
test_set_and_clear (test.test_threading.EventTests) ... ok
test_timeout (test.test_threading.EventTests) ... ok
test__is_owned (test.test_threading.ConditionAsRLockTests) ... ok
test_acquire_contended (test.test_threading.ConditionAsRLockTests) ... ok
test_acquire_destroy (test.test_threading.ConditionAsRLockTests) ... ok
test_acquire_release (test.test_threading.ConditionAsRLockTests) ... ok
test_constructor (test.test_threading.ConditionAsRLockTests) ... ok
test_different_thread (test.test_threading.ConditionAsRLockTests) ... ok
test_reacquire (test.test_threading.ConditionAsRLockTests) ... ok
test_release_unacquired (test.test_threading.ConditionAsRLockTests) ... ok
test_thread_leak (test.test_threading.ConditionAsRLockTests) ... ok
test_timeout (test.test_threading.ConditionAsRLockTests) ... ok
test_try_acquire (test.test_threading.ConditionAsRLockTests) ... ok
test_try_acquire_contended (test.test_threading.ConditionAsRLockTests) ... ok
test_with (test.test_threading.ConditionAsRLockTests) ... ok
test_acquire (test.test_threading.ConditionTests) ... ok
test_notify (test.test_threading.ConditionTests) ... ok
test_timeout (test.test_threading.ConditionTests) ... ok
test_unacquired_notify (test.test_threading.ConditionTests) ... ok
test_unacquired_wait (test.test_threading.ConditionTests) ... ok
test_waitfor (test.test_threading.ConditionTests) ... ok
test_waitfor_timeout (test.test_threading.ConditionTests) ... ok
test_acquire (test.test_threading.SemaphoreTests) ... ok
test_acquire_contended (test.test_threading.SemaphoreTests) ... ok
test_acquire_destroy (test.test_threading.SemaphoreTests) ... ok
test_acquire_timeout (test.test_threading.SemaphoreTests) ... ok
test_constructor (test.test_threading.SemaphoreTests) ... ok
test_default_value (test.test_threading.SemaphoreTests) ... ok
test_release_unacquired (test.test_threading.SemaphoreTests) ... ok
test_try_acquire (test.test_threading.SemaphoreTests) ... ok
test_try_acquire_contended (test.test_threading.SemaphoreTests) ... ok
test_with (test.test_threading.SemaphoreTests) ... ok
test_acquire (test.test_threading.BoundedSemaphoreTests) ... ok
test_acquire_contended (test.test_threading.BoundedSemaphoreTests) ... ok
test_acquire_destroy (test.test_threading.BoundedSemaphoreTests) ... ok
test_acquire_timeout (test.test_threading.BoundedSemaphoreTests) ... ok
test_constructor (test.test_threading.BoundedSemaphoreTests) ... ok
test_default_value (test.test_threading.BoundedSemaphoreTests) ... ok
test_release_unacquired (test.test_threading.BoundedSemaphoreTests) ... ok
test_try_acquire (test.test_threading.BoundedSemaphoreTests) ... ok
test_try_acquire_contended (test.test_threading.BoundedSemaphoreTests) ... ok
test_with (test.test_threading.BoundedSemaphoreTests) ... ok
test_PyThreadState_SetAsyncExc (test.test_threading.ThreadTests) ...     started worker thread
    trying nonsensical thread id
    waiting for worker thread to get started
    verifying worker hasn't exited
    attempting to raise asynch exception in worker
    waiting for worker to say it caught the exception
    all OK -- joining worker
ok
test_dummy_thread_after_fork (test.test_threading.ThreadTests) ... ok
test_enumerate_after_join (test.test_threading.ThreadTests) ... ok
test_finalize_runnning_thread (test.test_threading.ThreadTests) ... ok
test_finalize_with_trace (test.test_threading.ThreadTests) ... ok
test_foreign_thread (test.test_threading.ThreadTests) ... ok
test_ident_of_no_threading_threads (test.test_threading.ThreadTests) ... ok
test_join_nondaemon_on_shutdown (test.test_threading.ThreadTests) ... ok
test_limbo_cleanup (test.test_threading.ThreadTests) ... ok
test_no_refcycle_through_target (test.test_threading.ThreadTests) ... ok
test_old_threading_api (test.test_threading.ThreadTests) ... ok
test_repr_daemon (test.test_threading.ThreadTests) ... ok
test_various_ops (test.test_threading.ThreadTests) ... task <thread 0> will run for 24.7 usec
1 tasks are running
task <thread 1> will run for 90.2 usec
2 tasks are running
task <thread 0> done
<thread 0> is finished. 1 tasks are running
task <thread 2> will run for 95.2 usec
2 tasks are running
task <thread 1> done
<thread 1> is finished. 1 tasks are running
task <thread 3> will run for 40.1 usec
2 tasks are running
task <thread 2> done
<thread 2> is finished. 1 tasks are running
task <thread 4> will run for 56.5 usec
2 tasks are running
task <thread 3> done
<thread 3> is finished. 1 tasks are running
task <thread 5> will run for 13.6 usec
2 tasks are running
task <thread 4> done
<thread 4> is finished. 1 tasks are running
task <thread 6> will run for 32.9 usec
2 tasks are running
task <thread 5> done
<thread 5> is finished. 1 tasks are running
task <thread 6> done
<thread 6> is finished. 0 tasks are running
task <thread 7> will run for 26.2 usec
1 tasks are running
task <thread 8> will run for 62.7 usec
2 tasks are running
task <thread 7> done
<thread 7> is finished. 1 tasks are running
task <thread 8> done
<thread 8> is finished. 0 tasks are running
task <thread 9> will run for 31.9 usec
1 tasks are running
waiting for all tasks to complete
task <thread 9> done
<thread 9> is finished. 0 tasks are running
all tasks done
ok
test_various_ops_large_stack (test.test_threading.ThreadTests) ... with 1MB thread stack size...
task <thread 0> will run for 44.6 usec
1 tasks are running
task <thread 0> done
<thread 0> is finished. 0 tasks are running
task <thread 1> will run for 38.3 usec
1 tasks are running
task <thread 2> will run for 85.7 usec
2 tasks are running
task <thread 3> will run for 98.3 usec
3 tasks are running
task <thread 1> done
<thread 1> is finished. 2 tasks are running
task <thread 2> done
<thread 2> is finished. 1 tasks are running
task <thread 4> will run for 22.0 usec
2 tasks are running
task <thread 5> will run for 49.5 usec
3 tasks are running
task <thread 6> will run for 60.1 usec
task <thread 3> done
<thread 3> is finished. 2 tasks are running
task <thread 4> done
<thread 4> is finished. 1 tasks are running
task <thread 5> done
<thread 5> is finished. 0 tasks are running
1 tasks are running
task <thread 7> will run for 63.6 usec
2 tasks are running
task <thread 8> will run for 92.0 usec
3 tasks are running
task <thread 9> will run for 60.7 usec
task <thread 6> done
<thread 6> is finished. 2 tasks are running
task <thread 7> done
<thread 7> is finished. 1 tasks are running
task <thread 8> done
<thread 8> is finished. 0 tasks are running
1 tasks are running
task <thread 9> done
<thread 9> is finished. 0 tasks are running
waiting for all tasks to complete
all tasks done
ok
test_various_ops_small_stack (test.test_threading.ThreadTests) ... with 256kB thread stack size...
task <thread 0> will run for 27.1 usec
1 tasks are running
task <thread 1> will run for 23.9 usec
2 tasks are running
task <thread 2> will run for 33.1 usec
3 tasks are running
task <thread 0> done
<thread 0> is finished. 2 tasks are running
task <thread 1> done
<thread 1> is finished. 1 tasks are running
task <thread 3> will run for 34.7 usec
2 tasks are running
task <thread 4> will run for 73.9 usec
3 tasks are running
task <thread 5> will run for 80.9 usec
task <thread 2> done
<thread 2> is finished. 2 tasks are running
task <thread 3> done
<thread 3> is finished. 1 tasks are running
task <thread 4> done
<thread 4> is finished. 0 tasks are running
1 tasks are running
task <thread 6> will run for 97.1 usec
2 tasks are running
task <thread 7> will run for 99.2 usec
3 tasks are running
task <thread 5> done
<thread 5> is finished. 2 tasks are running
task <thread 6> done
<thread 6> is finished. 1 tasks are running
task <thread 8> will run for 29.3 usec
2 tasks are running
task <thread 9> will run for 70.3 usec
3 tasks are running
waiting for all tasks to complete
task <thread 7> done
<thread 7> is finished. 2 tasks are running
task <thread 8> done
<thread 8> is finished. 1 tasks are running
task <thread 9> done
<thread 9> is finished. 0 tasks are running
all tasks done
ok
test_1_join_on_shutdown (test.test_threading.ThreadJoinOnShutdown) ... ok
test_2_join_in_forked_process (test.test_threading.ThreadJoinOnShutdown) ... ok
test_3_join_in_forked_from_thread (test.test_threading.ThreadJoinOnShutdown) ... ok
test_4_joining_across_fork_in_worker_thread (test.test_threading.ThreadJoinOnShutdown) ... ok
test_5_clear_waiter_locks_to_avoid_crash (test.test_threading.ThreadJoinOnShutdown) ... ok
test_6_daemon_threads (test.test_threading.ThreadJoinOnShutdown) ... FAIL
test_reinit_tls_after_fork (test.test_threading.ThreadJoinOnShutdown) ... ok
test_daemonize_active_thread (test.test_threading.ThreadingExceptionTests) ... ok
test_joining_current_thread (test.test_threading.ThreadingExceptionTests) ... ok
test_joining_inactive_thread (test.test_threading.ThreadingExceptionTests) ... ok
test_recursion_limit (test.test_threading.ThreadingExceptionTests) ... ok
test_start_thread_again (test.test_threading.ThreadingExceptionTests) ... ok
test_abort (test.test_threading.BarrierTests) ... ok
test_abort_and_reset (test.test_threading.BarrierTests) ... ok
test_action (test.test_threading.BarrierTests) ... ok
test_barrier (test.test_threading.BarrierTests) ... ok
test_barrier_10 (test.test_threading.BarrierTests) ... ok
test_default_timeout (test.test_threading.BarrierTests) ... ok
test_reset (test.test_threading.BarrierTests) ... ok
test_single_thread (test.test_threading.BarrierTests) ... ok
test_timeout (test.test_threading.BarrierTests) ... ok
test_wait_return (test.test_threading.BarrierTests) ... ok

======================================================================
FAIL: test_6_daemon_threads (test.test_threading.ThreadJoinOnShutdown)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/ambv/Buildbot/3.2.langa-lion/build/Lib/test/test_threading.py", line 696, in test_6_daemon_threads
    rc, out, err = assert_python_ok('-c', script)
  File "/Users/ambv/Buildbot/3.2.langa-lion/build/Lib/test/script_helper.py", line 53, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/Users/ambv/Buildbot/3.2.langa-lion/build/Lib/test/script_helper.py", line 45, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is -11, stderr follows:


----------------------------------------------------------------------
Ran 119 tests in 19.978s

FAILED (failures=1)
test test_threading failed

----------
assignee: ronaldoussoren
components: Interpreter Core, Macintosh
messages: 167391
nosy: haypo, ronaldoussoren
priority: normal
severity: normal
status: open
title: Segfault in test_6_daemon_threads() of test_threading, on Mac OS X Lion
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Aug  4 04:39:38 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 04 Aug 2012 02:39:38 +0000
Subject: [New-bugs-announce] [issue15554] correct and clarify
	str.splitlines() documentation
Message-ID: <1344047978.01.0.683229635888.issue15554@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The documentation for str.splitlines()--

http://docs.python.org/dev/library/stdtypes.html#str.splitlines

includes a statement that is not quite correct:

"Unlike split(), if the string ends with line boundary characters the returned list does not have an empty last element."

For example,

>>> '\n'.splitlines()
['']
>>> '\n\n'.splitlines()
['', '']
>>> '\r\n'.splitlines()
['']
>>> '\n\r\n'.splitlines()
['', '']
>>> '\r'.splitlines()
['']
>>> 'a\n\n'.splitlines()
['a', '']

Also, the note about split() only applies when split() is passed a separator.  For example--

>>> 'a\n'.split('\n')
['a', '']
>>> 'a\n'.split()
['a']

Finally, the function's behavior on the empty string is another difference worth mentioning that is not covered by the existing note.

I am attaching a patch that addresses these points.  Notice also that the patch phrases it not as whether the list *has* an empty last element, but whether an *additional* last element should be added, which is the more important point.

----------
assignee: docs at python
components: Documentation
files: issue-splitlines-docs-1.patch
keywords: easy, patch
messages: 167394
nosy: cjerdonek, docs at python, jcea, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: correct and clarify str.splitlines() documentation
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26680/issue-splitlines-docs-1.patch

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

From report at bugs.python.org  Sat Aug  4 17:59:58 2012
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Sat, 04 Aug 2012 15:59:58 +0000
Subject: [New-bugs-announce] [issue15555] Default newlines of
	io.TextIOWrapper
Message-ID: <1344095998.81.0.573935781933.issue15555@psf.upfronthosting.co.za>


New submission from Atsuo Ishimoto:

In http://docs.python.org/dev/library/io.html:

  "if newline is None, any '\n' characters written are translated to the system default line separator, os.linesep. "

But os.linesep is not referred at all. On Windows default newline is always '\r\n' on Windows, '\n' otherwise.

----------
assignee: docs at python
components: Documentation
messages: 167413
nosy: docs at python, ishimoto
priority: normal
severity: normal
status: open
title: Default newlines of io.TextIOWrapper

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

From report at bugs.python.org  Sat Aug  4 18:07:43 2012
From: report at bugs.python.org (Jeremy Kloth)
Date: Sat, 04 Aug 2012 16:07:43 +0000
Subject: [New-bugs-announce] [issue15556] os.stat fails for file pending
	delete on Windows
Message-ID: <1344096463.0.0.611888237472.issue15556@psf.upfronthosting.co.za>


New submission from Jeremy Kloth:

os.stat fails when called on a file that is pending delete but is still in the directory listing.

This in turn causes os.path.exists to return the wrong result.

Attached is a test case demonstrating this broken behavior.

----------
components: Library (Lib), Windows
files: stat-bug.py
messages: 167414
nosy: jkloth
priority: normal
severity: normal
status: open
title: os.stat fails for file pending delete on Windows
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26687/stat-bug.py

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

From report at bugs.python.org  Sat Aug  4 19:52:58 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Sat, 04 Aug 2012 17:52:58 +0000
Subject: [New-bugs-announce] [issue15557] Tests for webbrowser module
Message-ID: <1344102778.31.0.864118033074.issue15557@psf.upfronthosting.co.za>


New submission from Anton Barkovsky:

Attaching a patch with some tests for webbrowser module.

The tests fail unless #15509 is fixed.
They also print lots of warnings unless #15447 is fixed.

----------
components: Tests
files: test_webbrowser.patch
keywords: patch
messages: 167423
nosy: anton.barkovsky, r.david.murray
priority: normal
severity: normal
status: open
title: Tests for webbrowser module
versions: Python 3.3
Added file: http://bugs.python.org/file26688/test_webbrowser.patch

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

From report at bugs.python.org  Sat Aug  4 23:28:53 2012
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Sat, 04 Aug 2012 21:28:53 +0000
Subject: [New-bugs-announce] [issue15558] webbrowser output to console
Message-ID: <1344115733.09.0.946491153947.issue15558@psf.upfronthosting.co.za>


New submission from Juancarlo A?ez:

Under Ubuntu Linux 11.10 and 12.04, webbroser.open() will output the following message to the console:

Created new window in existing browser session.

The behavior is both unexpected and troublesome.

----------
components: Library (Lib)
messages: 167443
nosy: apalala
priority: normal
severity: normal
status: open
title: webbrowser output to console
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Sun Aug  5 10:03:13 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 05 Aug 2012 08:03:13 +0000
Subject: [New-bugs-announce] [issue15559] Bad interaction between ipaddress
	addresses and the	bytes constructor
Message-ID: <1344153793.69.0.927408739195.issue15559@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

I've been tinkering with the ipaddress module as I review Eli's documentation and have uncovered a *very* nasty interaction between ipaddress objects and the bytes constructor.

Specifically, if you pass an integer to bytes() it will attempt to allocate and zero-initialise a buffer of that size. It uses operator.index() to check for integers.

This creates a problem, because ipaddress objects currently implement __index__ so they can be treated as integers without an explicit cast.

This does very bad things if, say, you do "bytes(ipaddress.IPv4Address('192.168.0.1'))"

If I remove the __index__ implementation, then you can't call hex() directly on ipaddress objects anymore - you have to call hex(int(addr)) instead.

I'm a *lot* happier with that approach, and will be implementing it in a moment.

----------
messages: 167474
nosy: georg.brandl, ncoghlan, pmoody
priority: release blocker
severity: normal
status: open
title: Bad interaction between ipaddress addresses and the bytes constructor
type: crash

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

From report at bugs.python.org  Sun Aug  5 11:03:38 2012
From: report at bugs.python.org (Ned Deily)
Date: Sun, 05 Aug 2012 09:03:38 +0000
Subject: [New-bugs-announce] [issue15560] _sqlite3.so is built with wrong
	include file on OS X	when using an SDK
Message-ID: <1344157418.55.0.45856897604.issue15560@psf.upfronthosting.co.za>


New submission from Ned Deily:

setup.py supports building Python with an OS X SDK to allow building Python executables and libraries that will run on multiple versions of OS X.  There is an error in the SDK support code in detect_modules() for building the _sqlite3 extension that has the effect of incorrectly using header files for libsqlite3 from the build system's installed /usr/include rather than the selected SDK's usr/include. Depending on which SDK version and which OS X version of the build system, the effects of this bug can range from a few compile warning messages (and possible subtle execution errors) to a catastrophic build failure of the _sqlite3 extension.  The attached patches fix the problem.  One consequence of fixing the bug is that it is more important than ever to supply a local newer version of libsqlite3 if building with the obsolete MacOSX10.4u.sdk since the version of libsqlite3 in 10.4 is 3.1.3 and there are several conditional tests in the _sqlite modules to work around bugs and missing features for versions that old, tests that were previously incorrectly checking the system libsqlite3 version.  (By contrast, the version of libsqlite3 in MacOSX10.5.sdk is 3.4.0, old but usable; 10.6 has 3.6.12).

----------
assignee: ned.deily
components: Build, Macintosh
messages: 167478
nosy: ned.deily
priority: high
severity: normal
stage: patch review
status: open
title: _sqlite3.so is built with wrong include file on OS X when using an SDK
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Aug  5 21:51:57 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 05 Aug 2012 19:51:57 +0000
Subject: [New-bugs-announce] [issue15561] update subprocess docs to
	reference io.TextIOWrapper
Message-ID: <1344196317.87.0.366111796882.issue15561@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This is an issue to update the subprocess module documentation after updates to io.TextIOWrapper's documentation here: 

http://hg.python.org/cpython/rev/f17a1410ebe5

This issue was discussed briefly on python-dev:

http://mail.python.org/pipermail/python-dev/2012-August/121239.html

Patch attached.

----------
assignee: docs at python
components: Documentation
files: issue-subprocess-docs-1.patch
keywords: easy, patch
messages: 167512
nosy: cjerdonek, docs at python, haypo
priority: normal
severity: normal
stage: patch review
status: open
title: update subprocess docs to reference io.TextIOWrapper
versions: Python 3.3
Added file: http://bugs.python.org/file26703/issue-subprocess-docs-1.patch

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

From report at bugs.python.org  Sun Aug  5 23:39:36 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 05 Aug 2012 21:39:36 +0000
Subject: [New-bugs-announce] [issue15562] CaseFolding not working properly
Message-ID: <1344202776.28.0.0609772465169.issue15562@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

IIUC, Python 3.3 is intended to support CaseFolding.txt. In

http://unicode.org/Public/UNIDATA/CaseFolding.txt

U+00B5 maps to U+03BC. However, in 3.3.0b1 (80a1ae3a1b39), ascii('\u00b5'.lower()) gives '\xb5'.

----------
messages: 167515
nosy: benjamin.peterson, loewis
priority: normal
severity: normal
status: open
title: CaseFolding not working properly
versions: Python 3.3

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

From report at bugs.python.org  Mon Aug  6 09:41:17 2012
From: report at bugs.python.org (Walid Shaari)
Date: Mon, 06 Aug 2012 07:41:17 +0000
Subject: [New-bugs-announce] [issue15563] wrong conversion reported by
Message-ID: <1344238877.43.0.388724812742.issue15563@psf.upfronthosting.co.za>


New submission from Walid Shaari:

In the code below the time stamp 1341183050 should be 01 July 2012.  however datetime is converting it back to 7 July 2012, the reverse too is wrong, is that just the way i am using the code?

[g_geadm at plcig2 ~]$ ipython
Python 2.6.5 (r265:79063, Jul 14 2010, 11:36:05)
Type "copyright", "credits" or "license" for more information.


In [2]: import datetime
In [3]: import time
In [4]: datetime.datetime.fromtimestamp(1341183050)
Out[4]: datetime.datetime(2012, 7, 2, 1, 50, 50)
time.mktime(dt.timetuple())

In [5]: dt=datetime.datetime(2012, 7, 2, 1, 50, 50)
In [6]: time.mktime(dt.timetuple())
Out[6]: 1341183050.0

In [7]: dt=datetime.datetime(2012, 7, 1, 22, 50, 50)
In [8]: time.mktime(dt.timetuple())
Out[8]: 1341172250.0

In [9]: datetime.datetime.fromtimestamp(1341172250.0)
Out[9]: datetime.datetime(2012, 7, 1, 22, 50, 50)

----------
components: Library (Lib)
messages: 167541
nosy: wshaari
priority: normal
severity: normal
status: open
title: wrong conversion reported by
versions: Python 2.6

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

From report at bugs.python.org  Mon Aug  6 11:31:46 2012
From: report at bugs.python.org (patrick vrijlandt)
Date: Mon, 06 Aug 2012 09:31:46 +0000
Subject: [New-bugs-announce] [issue15564] cgi.FieldStorage should not call
	read_multi on files
Message-ID: <1344245506.28.0.499641288303.issue15564@psf.upfronthosting.co.za>


New submission from patrick vrijlandt:

.mht is an archive format created by Microsoft IE 8 when saving a webpage. It is essentially a mime multipart message.

My problem occurred when I uploaded such a file to a cgi-based server. The posted data would be fed to cgi.FieldStorage. (I can't post the file unfortunately)

As it turns out, cgi.FieldStorage tries to recursively parse the postdata, thereby splitting up the uploaded file; this fails. However, this (automatic) recursive behaviour seems unwanted for an uploaded file.

My proposal is thus to adapt cgi.py (line number for Python 3.2), so that in FieldStorage.__init__, line 542, read_multi would not be invoked in this case.

Currently it says:

    elif ctype[:10] == 'multipart/':
        self.read_multi(environ, keep_blank_values, strict_parsing)

Change this to:

    elif ctype[:10] == 'multipart/' and not self.filename: 
        self.read_multi(environ, keep_blank_values, strict_parsing)

(I apologise for not submitting a test case. When trying to create it, it is either very complicated, or not easily recognizable as valid. Moreover, my server used a 3rd party software (bottlypy.org: bottle.py))

----------
components: Library (Lib)
messages: 167548
nosy: patrick.vrijlandt
priority: normal
severity: normal
status: open
title: cgi.FieldStorage should not call read_multi on files
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Aug  6 11:53:58 2012
From: report at bugs.python.org (Paul)
Date: Mon, 06 Aug 2012 09:53:58 +0000
Subject: [New-bugs-announce] [issue15565] pdb displays runt Exception strings
Message-ID: <1344246838.35.0.931540837367.issue15565@psf.upfronthosting.co.za>


New submission from Paul:

In Python 2.6, pdb doesn't show exception strings properly:

#somecode.py
import pdb
pdb.set_trace()
raise Exception('This is a message that contains a lot of characters and is very long indeed.')

#terminal
> somecode.py
-> raise Exception('This is a message that contains a lot of characters and is very long indeed.')
(Pdb) n
Exception: Exceptio...ndeed.',)

The pdb code assumes that sys.exc_info()[1] is a string. In fact it's an Exception instance.

The solution I found was to use str()

#pdb.py line 186
print >>self.stdout, exc_type_name + ':', _saferepr(str(exc_value))

This may have been fixed already but I couldn't find any reference to it.

----------
components: None
messages: 167550
nosy: powlo
priority: normal
severity: normal
status: open
title: pdb displays runt Exception strings
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Mon Aug  6 12:24:21 2012
From: report at bugs.python.org (Sebastian Ramacher)
Date: Mon, 06 Aug 2012 10:24:21 +0000
Subject: [New-bugs-announce] [issue15566] tarfile.TarInfo.frombuf
	documentation is out of date
Message-ID: <1344248661.48.0.873103438616.issue15566@psf.upfronthosting.co.za>


New submission from Sebastian Ramacher:

tarfile.TarInfo.frombuf has gained two more parameters: encoding and errors. The documentation of frombuf claims that the only parameter is buf, which is not true anymore.

----------
assignee: docs at python
components: Documentation
messages: 167553
nosy: docs at python, sebastinas
priority: normal
severity: normal
status: open
title: tarfile.TarInfo.frombuf documentation is out of date
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Aug  6 13:05:23 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 06 Aug 2012 11:05:23 +0000
Subject: [New-bugs-announce] [issue15567] threading.py contains undefined
	name in self-test code
Message-ID: <1344251123.58.0.751879223209.issue15567@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

Line 912 of threading.py, Py2.7, reads:

            self.queue = deque()

"deque" hasn't been imported.

----------
components: Library (Lib)
messages: 167554
nosy: scoder
priority: normal
severity: normal
status: open
title: threading.py contains undefined name in self-test code
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Aug  7 02:16:17 2012
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 07 Aug 2012 00:16:17 +0000
Subject: [New-bugs-announce] [issue15568] yield from missed StopIteration
	raised from iterator	instead of getting value
Message-ID: <1344298577.11.0.925171364298.issue15568@psf.upfronthosting.co.za>


New submission from Dino Viehland:

When implementing an iterable object by hand, and raising StopIteration with a value, the value is not provided as the result of the yield from expression.  This differs from the behavior in the "Formal Semantics" section.  Here's an example of how it differs from working with a normal generator:

class C:
    def __iter__(self): return self
    def __next__(self):
            raise StopIteration(100)


def g():
    if False:
        yield 100
    return 100

def f(val):
    x = yield from val
    print('x', x)

list(f(C()))
list(f(g()))


This makes it impossible to wrap a generator in a non-generator and get the same behavior.  The issue seems to be that the yield from implementation calls PyIter_Next which clears the StopIteration exception rather than say directly doing something like "(*iter->ob_type->tp_iternext)(iter);".

----------
components: Interpreter Core
messages: 167591
nosy: dino.viehland
priority: normal
severity: normal
status: open
title: yield from missed StopIteration raised from iterator instead of getting value
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Aug  7 03:24:07 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 07 Aug 2012 01:24:07 +0000
Subject: [New-bugs-announce] [issue15569] Dev Guide format-only roles
Message-ID: <1344302647.18.0.307450045197.issue15569@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

After the section describing roles that create cross-references to C-language constructs, the Dev Guide says this, "The following roles don?t do anything special except formatting the text in a different style."

http://hg.python.org/devguide/file/f518f23d06d5/documenting.rst#l984

However, some of the roles following in that section do do special things other than formatting.  For example--

envvar
    An environment variable. Index entries are generated.

keyword
    The name of a Python keyword. Using this role will generate a link to the documentation of the keyword....
    
The description should be changed, or better yet, the roles that do something special should be moved to a different section.

----------
components: Devguide
keywords: easy
messages: 167594
nosy: cjerdonek, ezio.melotti
priority: normal
severity: normal
status: open
title: Dev Guide format-only roles

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

From report at bugs.python.org  Tue Aug  7 07:19:24 2012
From: report at bugs.python.org (Dmitry Dvoinikov)
Date: Tue, 07 Aug 2012 05:19:24 +0000
Subject: [New-bugs-announce] [issue15570] email.header.decode_header parses
	differently
Message-ID: <1344316764.02.0.79283890102.issue15570@psf.upfronthosting.co.za>


New submission from Dmitry Dvoinikov:

The following script
---
import email.header
print(email.header.decode_header("foo =?windows-1251?Q?bar?="))
---
produces

[(b'foo', None), (b'bar', 'windows-1251')]

in Python 3.2 but

[(b'foo ', None), (b'bar', 'windows-1251')]

in Python 3.3.0b1

----------
components: Library (Lib)
messages: 167602
nosy: ddvoinikov
priority: normal
severity: normal
status: open
title: email.header.decode_header parses differently
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Aug  7 07:27:37 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Aug 2012 05:27:37 +0000
Subject: [New-bugs-announce] [issue15571] Python version of TextIOWrapper
	ignores "write_through"	arg
Message-ID: <1344317257.52.0.527557434634.issue15571@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

In discussing #15216, I noticed that the write_through parameter is completely unused in the Python implementation of TextIOWrapper.

That also means we have a hole in the test coverage: there is no test that is run on both the C and Python versions to ensure that the data is being written directly through to the underlying buffer (e.g. by passing in a mock buffer object).

----------
components: Library (Lib)
messages: 167603
nosy: ncoghlan
priority: release blocker
severity: normal
stage: test needed
status: open
title: Python version of TextIOWrapper ignores "write_through" arg
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Aug  7 12:58:46 2012
From: report at bugs.python.org (Cherniavsky Beni)
Date: Tue, 07 Aug 2012 10:58:46 +0000
Subject: [New-bugs-announce] [issue15572] Python2 documentation of the
	file() built-in function
Message-ID: <1344337126.35.0.910638419892.issue15572@psf.upfronthosting.co.za>


New submission from Cherniavsky Beni:

[followup for issue 12642 which only fixed it for open()]

http://docs.python.org/library/functions.html#file
says the arg names are:
  file(filename[, mode[, bufsize]])
but in practice they are:
  file(name[, mode[, buffering]])

----------
assignee: docs at python
components: Documentation
messages: 167617
nosy: cben, docs at python
priority: normal
severity: normal
status: open
title: Python2 documentation of the file() built-in function
versions: Python 2.7

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

From report at bugs.python.org  Tue Aug  7 13:55:31 2012
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 07 Aug 2012 11:55:31 +0000
Subject: [New-bugs-announce] [issue15573] Support unknown formats in
	memoryview comparisons
Message-ID: <1344340531.12.0.758557763037.issue15573@psf.upfronthosting.co.za>


New submission from Stefan Krah:

Continuing the discussion from #13072. I hit a snag here:

Determining in full generality whether two format strings describe
identical items is pretty complicated, see also #3132.


I'm attaching a best effort fmtcmp() function that should do the
following:

  - recognize byte order specifiers at the start of the string.

  - recognize if an explicitly specified byte order happens to
    match the native byte order.

It won't catch:

  - byte order specifiers anywhere in the string.

  - C types that happen to be identical ('I', 'L' on a 32-bit
    platform). I'm also not sure if that is desirable in the
    first place.

  - ???


So fmtcmp() will return false negatives (not equal), but should be
correct for *most* format strings that are actually in use.


Mark, Meador: You did a lot of work on the struct module and of
course on issue #3132. Does this look like a reasonable compromise?
Did I miss obvious cases (see attachment)?

----------
assignee: skrah
components: Interpreter Core
files: format.c
messages: 167618
nosy: Arfrever, georg.brandl, haypo, mark.dickinson, meador.inge, ncoghlan, pitrou, python-dev, skrah
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Support unknown formats in memoryview comparisons
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26720/format.c

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

From report at bugs.python.org  Tue Aug  7 18:48:18 2012
From: report at bugs.python.org (Leon Maurer)
Date: Tue, 07 Aug 2012 16:48:18 +0000
Subject: [New-bugs-announce] [issue15574] IDLE crash in OS X even with 2.7.3
	and ActiveTcl 8.5.12
Message-ID: <1344358098.04.0.570334143116.issue15574@psf.upfronthosting.co.za>


New submission from Leon Maurer:

I'm getting crashes with IDLE like those that have been reported before (e.g. by trying to copy using Command-C), but I followed (or at least tried to follow) the directions at

http://www.python.org/getit/mac/tcltk/

and have installed Python 2.7.3 64-bit/32-bit and ActiveTcl 8.5.12.

I've attached the crash log. I believe the following lines shows that I am using Tk 8.5.12 and not Apple's buggy version:

0x671000 -   0x76fff7 +Tk 8.5.12 (8.5.12) <BF86DC19-7B3F-BDAA-B650-1DA10C23D73B> /Library/Frameworks/Tk.framework/Versions/8.5/Tk

Thanks.

----------
components: IDLE
files: IDLE crash.rtf
messages: 167624
nosy: Leon.Maurer
priority: normal
severity: normal
status: open
title: IDLE crash in OS X even with 2.7.3 and ActiveTcl 8.5.12
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file26722/IDLE crash.rtf

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

From report at bugs.python.org  Tue Aug  7 20:11:02 2012
From: report at bugs.python.org (Roy Smith)
Date: Tue, 07 Aug 2012 18:11:02 +0000
Subject: [New-bugs-announce] [issue15575] Tutorial is unclear on multiple
	imports of a module.
Message-ID: <1344363062.87.0.467457264308.issue15575@psf.upfronthosting.co.za>


New submission from Roy Smith:

Opening this bug at Ben Finney's request.  See https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/wmDUrpW2ZCU for the full thread discussing the problem.  Here's a significant excerpt:

-------------------------------------------------
The tutorial is misleading on this. It it says plainly: 

    A module can contain executable statements as well as function 
    definitions. [?] They are executed only the *first* time the module 
    is imported somewhere. 

    <URL:http://docs.python.org/tutorial/modules.html> 

but it doesn't make clear that a module can exist in the ?sys.modules? 
list multiple times under different names. 
-------------------------------------------------


Also note:

--------------------------------------------------
The footnote to that is wrong too: 

> [1]        In fact function definitions are also ?statements? that are ?executed?; the execution of a module-level function enters the function name in the module?s global symbol table. 

I think what it's supposed to say is "... the execution of a module-level def statement ..." 
---------------------------------------------------

----------
assignee: docs at python
components: Documentation
messages: 167628
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: Tutorial is unclear on multiple imports of a module.
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Aug  7 20:35:50 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 07 Aug 2012 18:35:50 +0000
Subject: [New-bugs-announce] [issue15576] importlib: ExtensionFileLoader not
	used to load packages	from __init__.so files
Message-ID: <1344364550.12.0.263881849199.issue15576@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

The new importlib shows a regression w.r.t. previous CPython versions. It no longer recognises an "__init__.so" file as a package. All previous CPython versions have always tested first for an extension file before testing for a .py/.pyc file. The new importlib explicitly excludes the ExtensionFileLoader from loading packages. See importlib/_bootstrap.py, line 1579 onwards:

   1579 def _get_supported_file_loaders():
   1580     """Returns a list of file-based module loaders.
   1581 
   1582     Each item is a tuple (loader, suffixes, allow_packages).
   1583     """
   1584     extensions = ExtensionFileLoader, _imp.extension_suffixes(), False    # <== bug here
   1585     source = SourceFileLoader, SOURCE_SUFFIXES, True
   1586     bytecode = SourcelessFileLoader, BYTECODE_SUFFIXES, True
   1587     return [extensions, source, bytecode]

(BTW, I'm not sure what to file this bug against - "Interpreter Core" or "Library"?)

----------
components: Library (Lib)
messages: 167630
nosy: scoder
priority: normal
severity: normal
status: open
title: importlib: ExtensionFileLoader not used to load packages from __init__.so files
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Aug  7 22:38:30 2012
From: report at bugs.python.org (nordaux)
Date: Tue, 07 Aug 2012 20:38:30 +0000
Subject: [New-bugs-announce] [issue15577] Real Argc Argv in embeded
	interpreter
Message-ID: <1344371910.44.0.262957922939.issue15577@psf.upfronthosting.co.za>


New submission from nordaux:

I have found out certain peculiarity of interpreter in case it is embedded.
There is no way to reference to the real parameters argv, argc of main process from embedded python's C extensions.
When python is not embedded, it is task of function Py_Main, which sets the value of variables orig_argv, orig_argc.
These variables keep references to the original values of  argv, argc and give opportunity to manage them from the python C extensions if necessary.
I understand that the function Py_GetArgcArgv is rarely used, and this is true, but still believe that ability to manipulate these variables should be exist in any form of python from its C extension modules.
I tried different modules of C-extensions with such functional in embedded environment, but they all causes Segmentation Fault. The problem is not only in their implementation quality without any additional inspections, but also the function Py_GetArgcArgv doesn't additionally reported that its returned, and just ruturn null pointer in self argv parameter when used in embedded environment.
The following quote all the code that refers to this functionality in Python 2.7-3.3 at the moment:

/* For Py_GetArgcArgv(); set by main() */
static char **orig_argv;
static int  orig_argc;

..........................................................................................
/* Main program */

int
Py_Main(int argc, char **argv)
{
..........................................................................................
    orig_argc = argc;           /* For Py_GetArgcArgv() */
    orig_argv = argv;
..........................................................................................
}

void
Py_GetArgcArgv(int *argc, char ***argv)
{
    *argc = orig_argc;
    *argv = orig_argv;
}

Thats why I would like to suggest something similar to such function and use it in Py_Main and probably make it available from Python C API.
And also extend Py_GetArgcArgv with more detailed null pointer handling if variables orig_argv, orig_argc had not been initialized.

void
Py_InitArgcArgv(int *argc, char ***argv)
{
    if(! *argv) return -1;

    orig_argc = *argc;           /* For Py_GetArgcArgv() */
    orig_argv = *argv;

    return 0;   
}

Would like to see other suggestions.
Thanks.

----------
components: Extension Modules, Interpreter Core
messages: 167639
nosy: nordaux
priority: normal
severity: normal
status: open
title: Real Argc Argv in embeded interpreter
type: crash
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug  7 22:50:30 2012
From: report at bugs.python.org (Thomas Wouters)
Date: Tue, 07 Aug 2012 20:50:30 +0000
Subject: [New-bugs-announce] [issue15578] Crash when modifying sys.modules
	during import
Message-ID: <1344372630.36.0.657008264392.issue15578@psf.upfronthosting.co.za>


New submission from Thomas Wouters:

In a submodule of a package, replacing the parent package in sys.modules during import of the package (meaning the only reference to it is in sys.modules) and then importing itself (or something from itself) crashes the interpreter:

centurion:~/python/crasher > cat sa/__init__.py
import v1
centurion:~/python/crasher > cat sa/v1/__init__.py
import sys
sys.modules['sa'] = sys.modules[__name__]
import sa
centurion:~/python/crasher > python -c 'import sa'
Segmentation fault (core dumped)

It seems the crash is not entirely deterministic, as we've had the original code this was reduced from run in Python 2.4 and 2.6 for years, and only discovered the crash when switching to 2.7. However, running the reduced testcase crashes for me in all of Python 2.7, 2.6, 2.4 and 2.2, in debug builds and opt builds. Given the nature of the bug I expect debug builds to crash reliably.

I haven't found the actual source of the problem, but what seems to happen is that the import mechanism has a borrowed reference to the 'sa' module around, assuming it'll stay alive while the submodules are imported because it's also stored in sys.modules. This assumption is incorrect. However, changing the import in sa/__init__.py into an absolute or explicit relative import seems to fix the problem, which means this probably won't affect Python 3.

----------
components: Interpreter Core
messages: 167640
nosy: twouters
priority: normal
severity: normal
status: open
title: Crash when modifying sys.modules during import
type: crash
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Aug  8 00:10:46 2012
From: report at bugs.python.org (axw)
Date: Tue, 07 Aug 2012 22:10:46 +0000
Subject: [New-bugs-announce] [issue15579] some unicode keys not found using
	in dictionary.keys()
Message-ID: <1344377446.47.0.0219808809776.issue15579@psf.upfronthosting.co.za>


New submission from axw:

This simple snippet demonstrates the misbehaviour. Confirmed on two amd64 machines, python 2.7.3. 

###################

import copy

uzlist = [u'abc', u'def', u'ghj', u'klm', u'zxc']
utzdict = {u'abc':1, u'def':2, u'ghj':3, u'klm':4, u'zxc':5}

utemplist = copy.copy(uzlist)
for m in utemplist:
    if m in utzdict.keys(): utemplist.remove(m)

# utemplist should be empty now - it is not!
>>> utemplist
[u'def', u'klm']

utemplist = copy.copy(uzlist)
for i in range(len(uzlist)):
   try: 
     if utzdict[ uzlist[i] ]: utemplist.remove( uzlist[i] )
   except KeyError: pass

# utemplist should be empty now. This time it is:
>>> utemplist
[]

----------
components: Interpreter Core, Unicode
messages: 167645
nosy: axw, ezio.melotti
priority: normal
severity: normal
status: open
title: some unicode keys not found using in dictionary.keys()
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug  8 03:49:38 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 08 Aug 2012 01:49:38 +0000
Subject: [New-bugs-announce] [issue15580] fix True/False/None reST markup
Message-ID: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The Dev Guide says not to markup True, False, and None in the documentation in a way that generates a link (e.g. ":const:`True`") because "they?re fundamental to the language and should be known to any programmer":

http://docs.python.org/devguide/documenting.html#documenting

Rather, it says to use "``True``" (and similarly for False and None):

This issue is to update the documentation to conform to this guidance.

While working on the documentation, I noticed many occurrences of ":const:`True`", for example.  See here for some examples, where you can see the hyperlinks:

http://docs.python.org/dev/library/tarfile.html#tarfile.TarFile.add

----------
assignee: docs at python
components: Documentation
messages: 167648
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: fix True/False/None reST markup

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

From report at bugs.python.org  Wed Aug  8 04:35:56 2012
From: report at bugs.python.org (hut)
Date: Wed, 08 Aug 2012 02:35:56 +0000
Subject: [New-bugs-announce] [issue15581] curses: segfault in addstr()
Message-ID: <1344393356.61.0.716752115095.issue15581@psf.upfronthosting.co.za>


New submission from hut:

Under certain circumstances, the curses function addstr() will cause a segfault in python3.2.3 and python2.7.3.

Necessary, but not sufficient conditions are:
1. the window has been resized while curses was running
2. addstr() attempts to write a string that doesn't fit into the window, resulting in the cursors y-position being outside of the boundaries (which would normally only raise a _curses.error)

Instead of the "Segmentation Fault" message, I also sometimes get one of these two messages when python crashes:
*** glibc detected *** python2.7: corrupted double-linked list: 0x0949cc98 ***
python2.7: malloc.c:3964: _int_free: Assertion `nextchunk->fd_nextsize->bk_nextsize == nextchunk' failed.

To my shame, I didn't try to debug python myself, and I can't offer a minimal program to reproduce this bug, but I did find a way to reproduce it in the python program "ranger":

Link to the bug in rangers bug tracker with steps to reproduce:
https://github.com/hut/ranger/issues/45

Download link to the affected version of ranger:
https://github.com/hut/ranger/tarball/5ee1e874cc5f9136af3a9a835b76076a85693bd0

----------
components: Extension Modules
messages: 167653
nosy: hut
priority: normal
severity: normal
status: open
title: curses: segfault in addstr()
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Aug  8 04:52:14 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 08 Aug 2012 02:52:14 +0000
Subject: [New-bugs-announce] [issue15582] Enhance inspect.getdoc to follow
	inheritance chains
Message-ID: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Currently, if you override a method from a base class, the docstring is not inherited, even if it remains accurate.

This issue proposes an enhancement to inspect.getdoc() that allows the docstring to be retrieved from the inheritance hierarchy in the case where it is not overridden in the subclass by providing an explicit docstring.

Specifically, in the case where obj.__doc__ is None, and either the first parameter is a bound method, or a class object is passed in as the second parameter, inspect.getdoc will search the MRO based on obj.__name__ until it finds an attribute with a non-None __doc__ value.

(In Python 2, this could have been automatic for both bound and unbound methods. Unfortunately, there are no unbound methods in Python 3, so the second parameter is needed to handle the unbound method case)

----------
components: Library (Lib)
messages: 167654
nosy: eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Enhance inspect.getdoc to follow inheritance chains
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug  8 06:27:01 2012
From: report at bugs.python.org (Sarbjit singh)
Date: Wed, 08 Aug 2012 04:27:01 +0000
Subject: [New-bugs-announce] [issue15583] Provide examples in Python doc for
	usage of various	modules
Message-ID: <1344400021.49.0.93410153522.issue15583@psf.upfronthosting.co.za>


New submission from Sarbjit singh:

For beginners who are learning Python, it would be very helpful if Python doc could provide examples on usage of various methods/attributes of different modules.

For eg: If you look at ElementTree XMl module or take any other standard module, examples which are provided are very limited making it hard for new users to learn those modules and have to search internet for its usage. Providing examples on usage of module attributes/methods will help users to quickly understand it.

----------
assignee: docs at python
components: Documentation
messages: 167657
nosy: Sarbjit.singh, docs at python
priority: normal
severity: normal
status: open
title: Provide examples in Python doc for usage of various modules
type: enhancement

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

From report at bugs.python.org  Wed Aug  8 07:17:07 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 08 Aug 2012 05:17:07 +0000
Subject: [New-bugs-announce] [issue15584] os.popen deprecation warning not
	in Python 3 docs
Message-ID: <1344403027.9.0.851552943116.issue15584@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

The os.popen deprecation warning is not in the Python 3 docs!

----------
assignee: docs at python
components: Documentation
messages: 167662
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: os.popen deprecation warning not in Python 3 docs

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

From report at bugs.python.org  Wed Aug  8 07:18:24 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 08 Aug 2012 05:18:24 +0000
Subject: [New-bugs-announce] [issue15585] usage of os.popen in standard
	library
Message-ID: <1344403104.8.0.699404283397.issue15585@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

The following standard library modules use os.popen which is deprecated.
These calls should be replaced with calls to subprocess.Popen .
Ironically, even the subprocess module uses os.popen!
webbrowser.py:            osapipe = os.popen("osascript", "w")
webbrowser.py:            osapipe = os.popen("osascript", "w")
pydoc.py:    pipe = os.popen(cmd, 'w')
uuid.py:            with os.popen(cmd) as pipe:
uuid.py:            pipe = os.popen(os.path.join(dir, 'ipconfig') + ' /all')
platform.py:#            to cover up situations where platforms don't have os.popen
platform.py:        This is mostly needed in case os.popen() is not available, or
platform.py:    # over os.popen over _popen
platform.py:            popen = os.popen
platform.py:        f = os.popen('uname %s 2> %s' % (option, DEV_NULL))
platform.py:        f = os.popen('file -b "%s" 2> %s' % (target, DEV_NULL))
idlelib/IOBinding.py:            pipe = os.popen(command, "r")
os.py:# Supply os.popen()
subprocess.py:    Execute the string 'cmd' in a shell with os.popen() and return a 2-tuple
subprocess.py:    Execute the string 'cmd' in a shell with os.popen() and return a 2-tuple
subprocess.py:    pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')
multiprocessing/__init__.py:            with os.popen(comm) as p:
pipes.py:for the built-in function open() or for os.popen().
pipes.py:        return os.popen(cmd, 'r')
pipes.py:        return os.popen(cmd, 'w')
ctypes/util.py:            f = os.popen(cmd)
ctypes/util.py:            with contextlib.closing(os.popen(cmd)) as f:
ctypes/util.py:            f = os.popen(cmd)
ctypes/util.py:            with contextlib.closing(os.popen(cmd)) as f:
ctypes/util.py:            with contextlib.closing(os.popen('/sbin/ldconfig -r 2>/dev/null')) as f:
ctypes/util.py:            with contextlib.closing(os.popen('LC_ALL=C LANG=C /sbin/ldconfig -p 2>/dev/null')) as f:
distutils/command/bdist_rpm.py:        out = os.popen(q_cmd)
distutils/emxccompiler.py:        out = os.popen(gcc_exe + ' -dumpversion','r')

----------
components: Library (Lib)
messages: 167663
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: usage of os.popen in standard library
versions: Python 3.2

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

From report at bugs.python.org  Wed Aug  8 08:34:39 2012
From: report at bugs.python.org (Sarbjit singh)
Date: Wed, 08 Aug 2012 06:34:39 +0000
Subject: [New-bugs-announce] [issue15586] Provide some examples for usage of
	ElementTree	methods/attributes
Message-ID: <1344407679.24.0.102359835139.issue15586@psf.upfronthosting.co.za>


New submission from Sarbjit singh:

Please provide some basic usage examples for ElementTree module documentation. While parsing an xml, most common scenarios will be reading elements from xml, modifying elements, removal of elements. Though there are few examples given for modification of xml element. 

But if you look from beginners learning point of view, its very hard to just get any idea from the example that is currently provided. There is lot of text there, but what would be more helpful is some small examples for each function so that user can quickly understand its usage there only.  I myself is learning Python, but in order to start using this module, i had to search lot of articles on internet on usage of this module. If we could have provided some basic use cases in Python doc itself, user would not have to rely on external sources for learning its usage.

Some Basic Scenarios:
1) Parsing an xml and finding some elements of xml
2) deletion of an element from an xml and writing back
3) Modification of an xml element
4) Usage of XPath queries (some basic usage)

----------
assignee: docs at python
components: Documentation
messages: 167670
nosy: Sarbjit.singh, docs at python, eli.bendersky
priority: normal
severity: normal
status: open
title: Provide some examples for usage of ElementTree methods/attributes
type: enhancement

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

From report at bugs.python.org  Wed Aug  8 09:20:17 2012
From: report at bugs.python.org (Tyler Crompton)
Date: Wed, 08 Aug 2012 07:20:17 +0000
Subject: [New-bugs-announce] [issue15587] IDLE is pixelated on the Macbook
	Pro with Retina Display
Message-ID: <1344410417.58.0.332657489061.issue15587@psf.upfronthosting.co.za>


New submission from Tyler Crompton:

I think this is more of a Tkinter issue than IDLE but since IDLE uses Tkinter, it inherits this "bug". Many programs that were not developed for the Macbook Pro with Retina Display still look great. Whereas others, look pixelated in some areas (i.e. the current stable release of Google Chrome IIRC (I installed the beta to get around that)), and some are just flat out pixelated everywhere. IDLE falls into the latter category. I know IDLE really has its issues and that few people use it, but it's a cosmetic change that I don't see being too difficult. Then again, I know hardly anything about how it is implemented.

----------
components: IDLE, Tkinter
files: Screen Shot 2012-08-08 at 2.07.19 AM.png
messages: 167671
nosy: Tyler.Crompton
priority: normal
severity: normal
status: open
title: IDLE is pixelated on the Macbook Pro with Retina Display
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26724/Screen Shot 2012-08-08 at 2.07.19 AM.png

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

From report at bugs.python.org  Wed Aug  8 09:30:59 2012
From: report at bugs.python.org (patrick vrijlandt)
Date: Wed, 08 Aug 2012 07:30:59 +0000
Subject: [New-bugs-announce] [issue15588] quopri: encodestring and
	decodestring handle bytes, not strings
Message-ID: <1344411059.45.0.404148694214.issue15588@psf.upfronthosting.co.za>


New submission from patrick vrijlandt:

quopri.py's functions encodestring and decodestring are documented to handle strings; and this is clearly suggested by their name. However, these functions accept and return bytes, not strings. This should be reflected in the documentation. 

Even better: deprecate these functions and introduce new ones with behaviour as suggested by their names: encode_string, encode_bytes etc.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 167672
nosy: docs at python, patrick.vrijlandt
priority: normal
severity: normal
status: open
title: quopri: encodestring and decodestring handle bytes, not strings
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Aug  8 11:16:51 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 08 Aug 2012 09:16:51 +0000
Subject: [New-bugs-announce] [issue15589] Bus error on Debian sparc
Message-ID: <1344417411.0.0.396332340112.issue15589@psf.upfronthosting.co.za>


New submission from Stefan Krah:

Running *any* test of the test suite currently produces a bus error
on Debian sparc [http://people.debian.org/~aurel32/qemu/sparc/].

After the bus error, the tests seem to proceed normally though.

This is definitely new. I've been testing memoryview for bus errors
a couple of months ago without problems.


Georg, I'm provisionally setting this to release blocker. The
qemu-sparc image is quite old though (Debian Etch). It's a pity
we don't have a sparc buildbot any more.




Example:


user at debian-sparc:~/cpython$ ./python -m test -uall -v test_flufl
== CPython 3.3.0b1 (default:67d36e8ddcfc+, Aug 7 2012, 23:49:57) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)]
Fatal Python error: Bus error

Current thread 0x00004000:
  File "/home/user/cpython/Lib/subprocess.py", line 1363 in _execute_child
  File "/home/user/cpython/Lib/subprocess.py", line 818 in __init__
  File "/home/user/cpython/Lib/os.py", line 995 in popen
  File "/home/user/cpython/Lib/platform.py", line 903 in _syscmd_uname
  File "/home/user/cpython/Lib/platform.py", line 1147 in uname
  File "/home/user/cpython/Lib/platform.py", line 1452 in platform
  File "/home/user/cpython/Lib/test/regrtest.py", line 537 in main
  File "/home/user/cpython/Lib/test/__main__.py", line 13 in <module>
  File "/home/user/cpython/Lib/runpy.py", line 73 in _run_code
  File "/home/user/cpython/Lib/runpy.py", line 160 in _run_module_as_main
==   Linux-2.6.18-6-sparc32-sparc-with-debian-4.0 big-endian
==   /home/user/cpython/build/test_python_3262
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1)
[1/1] test_flufl
test_barry_as_bdfl (test.test_flufl.FLUFLTests) ... ok
test_guido_as_bdfl (test.test_flufl.FLUFLTests) ... ok

----------------------------------------------------------------------
Ran 2 tests in 0.053s

OK
1 test OK.

----------
keywords: 3.2regression
messages: 167678
nosy: georg.brandl, skrah
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Bus error on Debian sparc
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Wed Aug  8 12:43:18 2012
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 08 Aug 2012 10:43:18 +0000
Subject: [New-bugs-announce] [issue15590] --libs is inconsistent for
	python-config --libs and	pkgconfig python --libs
Message-ID: <1344422598.39.0.464686614779.issue15590@psf.upfronthosting.co.za>


New submission from Matthias Klose:

seen with at least 2.7, 3.2 and 3.3:

$ python-config --libs
-lpthread -ldl -lutil -lm -lpython2.7

$ pkg-config python --static --libs
-lpthread -ldl -lutil -lpython2.7

python-config uses the SYSLIBS macro, while pkg-config uses the LIBS macro.

depending on what you want to do, both can be wrong or right:

 - to build an extension, LIBS should be used.

 - to link an embedded interpreter, SYSLIBS should be used,
   which might not be complete.
   Howver in this case MODLIBS is missing.

a patch should be easy once we can define the intended behaviour.

----------
components: Build
keywords: needs review
messages: 167683
nosy: doko
priority: normal
severity: normal
status: open
title: --libs is inconsistent for python-config --libs and pkgconfig python --libs
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Aug  8 12:52:57 2012
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 08 Aug 2012 10:52:57 +0000
Subject: [New-bugs-announce] [issue15591] when building the extensions,
	stdout is lost when stdout is redirected
Message-ID: <1344423177.77.0.190751096511.issue15591@psf.upfronthosting.co.za>


New submission from Matthias Klose:

I see this on all Debian and Ubuntu releases, when stdout is redirected. I expect to see the compiler and linker invocations for the sharedmods target, but I only see stderr (compiler and linker warnings).

e.g. make 2>&1 | tee log
or   script -c 'make' log

can this be reproduced on Debian/Ubuntu, or is this seen on other Linux distributions as well?

----------
components: Build
messages: 167684
nosy: doko
priority: normal
severity: normal
status: open
title: when building the extensions, stdout is lost when stdout is redirected
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Aug  8 18:38:00 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 08 Aug 2012 16:38:00 +0000
Subject: [New-bugs-announce] [issue15592] subprocess.communicate() breaks on
	no input with	universal newlines true
Message-ID: <1344443880.03.0.234384317121.issue15592@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Popen.communicate() raises an exception if passed no input when stdin=PIPE and universal_newlines=True.  With universal_newlines=False, no exception is raised.  For example, the following yields--

args = [sys.executable, '-c', 'pass']

popen = Popen(args, universal_newlines=False, stdin=PIPE, stdout=PIPE, stderr=PIPE)
print(popen.communicate())

popen = Popen(args, universal_newlines=True, stdin=PIPE, stdout=PIPE, stderr=PIPE)
print(popen.communicate())

(b'', b'[41449 refs]\n')
Traceback (most recent call last):
  ...
  File ".../Lib/subprocess.py", line 1581, in _communicate_with_poll
    self._input = self._input.encode(self.stdin.encoding)
AttributeError: 'NoneType' object has no attribute 'encode'

It seems like communicate() should not be trying to encode input if there is none.

I can provide a patch with tests if it is agreed this is an issue (along with a fix assuming it is reasonable).

----------
components: Library (Lib)
messages: 167694
nosy: cjerdonek
priority: normal
severity: normal
stage: test needed
status: open
title: subprocess.communicate() breaks on no input with universal newlines true
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Aug  8 21:47:51 2012
From: report at bugs.python.org (Rob Kinyon)
Date: Wed, 08 Aug 2012 19:47:51 +0000
Subject: [New-bugs-announce] [issue15593] urlparse.parse_qs documentation
	wrong re: urlencode
Message-ID: <1344455271.07.0.337513141168.issue15593@psf.upfronthosting.co.za>


New submission from Rob Kinyon:

This may appear to be a duplicate of http://bugs.python.org/issue12390 and http://bugs.python.org/issue833405, but it's not.

The documentation of urlparse.parse_qs() should state that in order for urllib.urlencode to properly reverse its output, the doseq parameter must be set to True. Please amend the documentation to make this very clear.

Ideally, the documentation of urlencode() would also make it clear that doseq=True is required if the output is from parse_qs().

----------
assignee: docs at python
components: Documentation
messages: 167707
nosy: Rob.Kinyon, docs at python
priority: normal
severity: normal
status: open
title: urlparse.parse_qs documentation wrong re: urlencode
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug  8 22:27:35 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Aug 2012 20:27:35 +0000
Subject: [New-bugs-announce] [issue15594] test_copyfile_named_pipe() fails
	on Mac OS X Snow	Leopard: OSError: [Errno 22] Invalid argument
Message-ID: <1344457655.9.0.373688420399.issue15594@psf.upfronthosting.co.za>


New submission from STINNER Victor:

======================================================================
ERROR: test_copyfile_named_pipe (test.test_shutil.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/ambv/Buildbot/3.x.langa-snowleopard/build/Lib/test/test_shutil.py", line 735, in test_copyfile_named_pipe
    os.mkfifo(TESTFN)
OSError: [Errno 22] Invalid argument

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leopard%203.x/builds/162/steps/test/logs/stdio

----------
assignee: ronaldoussoren
components: Macintosh
messages: 167711
nosy: haypo, ronaldoussoren
priority: normal
severity: normal
status: open
title: test_copyfile_named_pipe() fails on Mac OS X Snow Leopard: OSError: [Errno 22] Invalid argument
versions: Python 3.3

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

From report at bugs.python.org  Wed Aug  8 23:36:15 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 08 Aug 2012 21:36:15 +0000
Subject: [New-bugs-announce] [issue15595]
	subprocess.Popen(universal_newlines=True) does not work	for
	certain locales
Message-ID: <1344461775.23.0.274836365722.issue15595@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

subprocess.Popen() with universal_newlines=True does not convert line breaks correctly when the preferred encoding is UTF-16.  For example, the following code--

code = r"import sys; sys.stdout.buffer.write('a\r\nb'.encode('utf-16'))"
args = [sys.executable, '-c', code]
popen = Popen(args, universal_newlines=True, stdin=PIPE, stdout=PIPE)
print(popen.communicate(input=''))

yields--

('a\n\nb', None)

instead of--

('a\nb', None)

The reason is that the code attempts to convert newlines before decoding to unicode instead of after:

http://hg.python.org/cpython/file/85266c6f9ae4/Lib/subprocess.py#l830

I am attaching a failing test case.  I will upload a patch shortly.

Also see the related documentation issue 15561.

----------
components: Library (Lib)
files: failing-test-case-1.patch
keywords: easy, patch
messages: 167719
nosy: cjerdonek
priority: normal
severity: normal
stage: needs patch
status: open
title: subprocess.Popen(universal_newlines=True) does not work for certain locales
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26728/failing-test-case-1.patch

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

From report at bugs.python.org  Thu Aug  9 00:38:42 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Aug 2012 22:38:42 +0000
Subject: [New-bugs-announce] [issue15596] pickle: Faster serialization of
	Unicode strings
Message-ID: <1344465522.38.0.375715302831.issue15596@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Serialization of Unicode strings in the pickle module is suboptimal, especially for long strings.

Attached patch optimize the serialization thanks to new properties of Unicode strings (PEP 393):

 * text (protocol 0): avoid any temporary buffer if the string is an ASCII or latin1 string without "\\" or "\n" character; otherwise use a small buffer of 64 KB (instead of two buffer)
 * binary (protocol 1, 2): avoid any temporary buffer if string is an ASCII string or if the string is already available encoded as UTF-8

The current code for protocol 0 uses raw_unicode_escape() which is really suboptimal: it uses a first buffer to write the escape string, and then a new temporary buffer to store the buffer with the right size (instead of just calling _PyBytes_Resize).

----------
components: Library (Lib)
files: pickle_unicode.patch
keywords: patch
messages: 167730
nosy: alexandre.vassalotti, haypo, pitrou
priority: normal
severity: normal
status: open
title: pickle: Faster serialization of Unicode strings
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file26730/pickle_unicode.patch

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

From report at bugs.python.org  Thu Aug  9 01:16:48 2012
From: report at bugs.python.org (Ned Deily)
Date: Wed, 08 Aug 2012 23:16:48 +0000
Subject: [New-bugs-announce] [issue15597] exception __suppress_context__
	test failures on OS X ppc	systems
Message-ID: <1344467808.95.0.390375910208.issue15597@psf.upfronthosting.co.za>


New submission from Ned Deily:

== CPython 3.3.0b1 (default:efb30bdcfa1e, Aug 8 2012, 15:43:49) [GCC 4.0.1 (Apple Inc. build 5493)]
==   Darwin-8.11.0-Power_Macintosh-powerpc-32bit big-endian
==   /private/tmp/test_python_13864
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1)
[...]
======================================================================
FAIL: testChainingDescriptors (test.test_exceptions.ExceptionTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_exceptions.py", line 432, in testChainingDescriptors
    self.assertTrue(e.__suppress_context__)
AssertionError: False is not true

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

Other similar test failures include multiple test cases in test_ipaddress, test_raise, and test_traceback, for example:


======================================================================
FAIL: test_address_errors (test.test_ipaddress.NetworkTestCase_v6)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/ipaddress.py", line 1580, in _ip_int_from_string
    ip_int |= self._parse_hextet(parts[i])
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/ipaddress.py", line 1605, in _parse_hextet
    raise ValueError("Only hex digits permitted in %r" % hextet_str)
ValueError: Only hex digits permitted in 'axy'

During handling of the above exception, another exception occurred:

ipaddress.AddressValueError: Only hex digits permitted in 'axy' in '1234:axy::b'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_ipaddress.py", line 439, in test_address_errors
    assertBadAddress("1234:axy::b", "Only hex digits")
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_ipaddress.py", line 432, in assertBadAddress
    self.factory(addr)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/contextlib.py", line 66, in __exit__
    self.gen.throw(type, value, traceback)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_ipaddress.py", line 50, in assertCleanError
    self.assertTrue(exc.exception.__suppress_context__)
AssertionError: False is not true

The same universal build runs without error on an Intel Mac with the same os version.  The ppc failures are seen on both PPC OS X 10.5 and 10.4 systems.

----------
messages: 167734
nosy: benjamin.peterson, ned.deily, pitrou
priority: critical
severity: normal
stage: needs patch
status: open
title: exception __suppress_context__ test failures on OS X ppc systems
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Aug  9 02:18:08 2012
From: report at bugs.python.org (Antony Lee)
Date: Thu, 09 Aug 2012 00:18:08 +0000
Subject: [New-bugs-announce] [issue15598] relative import unexpectedly binds
	name
Message-ID: <1344471488.35.0.495705727003.issue15598@psf.upfronthosting.co.za>


New submission from Antony Lee:

The language reference is clear:
"The from form does not bind the module name" (Section 6.12)

However, consider the following example:

* package/__init__.py:
foo = "FOO"
from .foo import bar
print(foo)
os = "OS"
from os import path
print(os)

* package/foo.py:
foo = 42

Now "import package" results in printing:
<module 'pypackage.foo' from 'pypackage/foo.py'>
OS

i.e., the relative "from ... import" has not only bound "bar", but also "foo", which seems to contradict the documentation.
(I get the same behaviour using 3.2.3 as well as 2.7.3.)

----------
messages: 167742
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: relative import unexpectedly binds name
versions: Python 3.2

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

From report at bugs.python.org  Thu Aug  9 02:59:34 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Aug 2012 00:59:34 +0000
Subject: [New-bugs-announce] [issue15599] test_circular_imports() of
	test_threaded_import fails on	FreeBSD 9.0
Message-ID: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/3231/steps/test/logs/stdio

[111/369] test_threaded_import
test_circular_imports (test.test_threaded_import.ThreadedImportTests) ... Exception in thread Thread-586:
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 639, in _bootstrap_inner
    self.run()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 596, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_threaded_import.py", line 194, in import_ab
    import A
ImportError: No module named 'A'

Exception in thread Thread-587:
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 639, in _bootstrap_inner
    self.run()
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/threading.py", line 596, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_threaded_import.py", line 197, in import_ba
    import B
ImportError: No module named 'B'

FAIL
test_import_hangers (test.test_threaded_import.ThreadedImportTests) ... ok
test_parallel_meta_path (test.test_threaded_import.ThreadedImportTests) ... Trying 20 threads ... OK.
Trying 50 threads ... OK.
Trying 20 threads ... OK.
Trying 50 threads ... OK.
Trying 20 threads ... OK.
Trying 50 threads ... OK.
ok
test_parallel_module_init (test.test_threaded_import.ThreadedImportTests) ... Trying 20 threads ... OK.
Trying 50 threads ... OK.
Trying 20 threads ... OK.
Trying 50 threads ... OK.
Trying 20 threads ... OK.
Trying 50 threads ... OK.
ok
test_parallel_path_hooks (test.test_threaded_import.ThreadedImportTests) ... Trying 20 threads ... OK.
Trying 50 threads ... OK.
Trying 20 threads ... OK.
Trying 50 threads ... OK.
Trying 20 threads ... OK.
Trying 50 threads ... OK.
ok
test_side_effect_import (test.test_threaded_import.ThreadedImportTests) ... ok

======================================================================
FAIL: test_circular_imports (test.test_threaded_import.ThreadedImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_threaded_import.py", line 205, in test_circular_imports
    self.assertEqual(set(results), {'a', 'b'})
AssertionError: Items in the second set but not the first:
'a'
'b'

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

----------
messages: 167747
nosy: brett.cannon, haypo
priority: normal
severity: normal
status: open
title: test_circular_imports() of test_threaded_import fails on FreeBSD 9.0

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

From report at bugs.python.org  Thu Aug  9 05:43:20 2012
From: report at bugs.python.org (Eric Snow)
Date: Thu, 09 Aug 2012 03:43:20 +0000
Subject: [New-bugs-announce] [issue15600] expose the finder details used by
	the FileFinder path	hook
Message-ID: <1344483800.66.0.152640034936.issue15600@psf.upfronthosting.co.za>


New submission from Eric Snow:

The path hook associated with importlib.machinery.FileFinder hides away its loader details in a closure.  This is less than ideal for the purposes of introspection and general hacking.

Here's a simple patch that exposes the loader details as an attribute on the path hook.

This came up in issue 15576 (see msg167632).

----------
components: Interpreter Core
files: loader_details.diff
keywords: patch
messages: 167755
nosy: brett.cannon, eric.snow, scoder
priority: normal
severity: normal
stage: patch review
status: open
title: expose the finder details used by the FileFinder path hook
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26735/loader_details.diff

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

From report at bugs.python.org  Thu Aug  9 06:33:53 2012
From: report at bugs.python.org (Ned Deily)
Date: Thu, 09 Aug 2012 04:33:53 +0000
Subject: [New-bugs-announce] [issue15601] tkinter test_variables fails with
	OS X Aqua Tk 8.4
Message-ID: <1344486833.0.0.731183249876.issue15601@psf.upfronthosting.co.za>


New submission from Ned Deily:

======================================================================
FAIL: test_get (tkinter.test.test_tkinter.test_variables.TestStringVar)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/tkinter/test/test_tkinter/test_variables.py", line 85, in test_get
    self.assertEqual("1", v.get())
AssertionError: '1' != 'True'
- 1
+ True

The OS X 32-bit installers for OS X 10.5+ link with Tcl/Tk 8.4 as that was the only version supplied by Apple for 10.5.  The test passes when linked with the Aqua Tcl/Tk 8.5 available in OS X 10.6+ and used with the 64-/32-bit OS X installers.

----------
components: Tests, Tkinter
messages: 167759
nosy: asvetlov, ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: tkinter test_variables fails with OS X Aqua Tk 8.4
versions: Python 3.3

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

From report at bugs.python.org  Thu Aug  9 08:20:46 2012
From: report at bugs.python.org (monson)
Date: Thu, 09 Aug 2012 06:20:46 +0000
Subject: [New-bugs-announce] [issue15602] zipfile: wrong encoding charset of
	member filename
Message-ID: <1344493246.11.0.837013497182.issue15602@psf.upfronthosting.co.za>


New submission from monson:

In /cpython/Lib/zipfile.py, there are some codes like

            if flags & 0x800:
                # UTF-8 file names extension
                filename = filename.decode('utf-8')
            else:
                # Historical ZIP filename encoding
                filename = filename.decode('cp437')


But actually there is no "Historical ZIP filename encoding", because zip files contain no charset info.
In English countries, it's usually not a big deal. But if the files zip on a non-cp437-based system (especially like China or Japan), filename is encoded from charsets like gb18030, but ZipFile decodes the byte stream to cp437, then everything goes wrong and people are hard to find the reason.

It's a problem new in py3k, and I found it on python3.2 and python3.4.
I suggest the filename returned in Bytes objects, or add decoding parameter when opening zipfile.

----------
components: Library (Lib)
messages: 167760
nosy: monson
priority: normal
severity: normal
status: open
title: zipfile: wrong encoding charset of member filename
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Aug  9 17:03:19 2012
From: report at bugs.python.org (Chris)
Date: Thu, 09 Aug 2012 15:03:19 +0000
Subject: [New-bugs-announce] [issue15603] Multiprocessing creates incorrect
	pids
Message-ID: <1344524599.55.0.473734451095.issue15603@psf.upfronthosting.co.za>


New submission from Chris:

http://stackoverflow.com/questions/11884864/python-multiprocessing-creates-incorrect-pids

Jesse Noller suggested that I submit this stack overflow as a bug so it can be examined.  As the problem is kind of domain specific, it's not easy to come up with a test case that can reproduce the issue.

Please let me know what more information I can provide.  

Thanks!

----------
messages: 167788
nosy: cfriedline
priority: normal
severity: normal
status: open
title: Multiprocessing creates incorrect pids
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug  9 17:24:15 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Aug 2012 15:24:15 +0000
Subject: [New-bugs-announce] [issue15604] PyObject_IsTrue failure checks
Message-ID: <1344525855.66.0.08938802791.issue15604@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

PyObject_IsTrue can fail, but not everywhere in a code a returned value checked. Here is a patches which add such checks.

Note, patches for all three Python versions are rather different.

----------
components: Interpreter Core, Library (Lib)
files: istrue_check-3.3.patch
keywords: needs review, patch
messages: 167789
nosy: storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: PyObject_IsTrue failure checks
type: resource usage
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26742/istrue_check-3.3.patch

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

From report at bugs.python.org  Thu Aug  9 19:36:09 2012
From: report at bugs.python.org (Daniel Ellis)
Date: Thu, 09 Aug 2012 17:36:09 +0000
Subject: [New-bugs-announce] [issue15605] Explain sphinx documentation
	building in devguide
Message-ID: <1344533769.31.0.609415214451.issue15605@psf.upfronthosting.co.za>


New submission from Daniel Ellis:

At the bottom of this page: http://docs.python.org/devguide/documenting.html

There is a command explaining how to build the documentation without using make:

    python tools/sphinx-build.py -b<builder> . build/<outputdirectory>

It is unclear as to which directory the "tools" is referring to.  In the "Tools" directory of the main branch, there is no sphinx-build.py file.

On my system, I was able to do the build using sphinx-build as a bare command:

    sphinx-build -b<builder> . build/<outputdirectory>

I am not sure if this is system specific, but for someone building the documentation for the first time (as I was), this could be confusing.  Perhaps someone could explain whether the command that is currently written is obsolete or just differs by system.

----------
components: Devguide
messages: 167800
nosy: Daniel.Ellis, eric.araujo, ezio.melotti, ncoghlan
priority: normal
severity: normal
status: open
title: Explain sphinx documentation building in devguide

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

From report at bugs.python.org  Thu Aug  9 19:50:17 2012
From: report at bugs.python.org (Steven Collins)
Date: Thu, 09 Aug 2012 17:50:17 +0000
Subject: [New-bugs-announce] [issue15606] re.VERBOSE doesn't ignore certain
	whitespace
Message-ID: <1344534617.67.0.49137100671.issue15606@psf.upfronthosting.co.za>


New submission from Steven Collins:

Given the way the documentation is written for re.VERBOSE - "Whitespace within the pattern is ignored, except when in a character class or preceded by an unescaped backslash" - I would expect all three of the findall() commands below to return successfully with the same result:

Python 3.2.3 (default, Jun  8 2012, 05:37:15) 
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> re.findall('(?x) (?: a | b ) + ', 'abaabc')
['abaab']
>>> re.findall('(?x) (? : a | b ) + ', 'abaabc')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/re.py", line 193, in findall
    return _compile(pattern, flags).findall(string)
  File "/usr/lib/python3.2/re.py", line 255, in _compile
    return _compile_typed(type(pattern), pattern, flags)
  File "/usr/lib/python3.2/functools.py", line 184, in wrapper
    result = user_function(*args, **kwds)
  File "/usr/lib/python3.2/re.py", line 267, in _compile_typed
    return sre_compile.compile(pattern, flags)
  File "/usr/lib/python3.2/sre_compile.py", line 491, in compile
    p = sre_parse.parse(p, flags)
  File "/usr/lib/python3.2/sre_parse.py", line 692, in parse
    p = _parse_sub(source, pattern, 0)
  File "/usr/lib/python3.2/sre_parse.py", line 315, in _parse_sub
    itemsappend(_parse(source, state))
  File "/usr/lib/python3.2/sre_parse.py", line 627, in _parse
    raise error("unexpected end of pattern")
sre_constants.error: unexpected end of pattern
>>> re.findall('(?x) ( ?: a | b ) + ', 'abaabc')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.2/re.py", line 193, in findall
    return _compile(pattern, flags).findall(string)
  File "/usr/lib/python3.2/re.py", line 255, in _compile
    return _compile_typed(type(pattern), pattern, flags)
  File "/usr/lib/python3.2/functools.py", line 184, in wrapper
    result = user_function(*args, **kwds)
  File "/usr/lib/python3.2/re.py", line 267, in _compile_typed
    return sre_compile.compile(pattern, flags)
  File "/usr/lib/python3.2/sre_compile.py", line 491, in compile
    p = sre_parse.parse(p, flags)
  File "/usr/lib/python3.2/sre_parse.py", line 692, in parse
    p = _parse_sub(source, pattern, 0)
  File "/usr/lib/python3.2/sre_parse.py", line 315, in _parse_sub
    itemsappend(_parse(source, state))
  File "/usr/lib/python3.2/sre_parse.py", line 640, in _parse
    p = _parse_sub(source, state)
  File "/usr/lib/python3.2/sre_parse.py", line 315, in _parse_sub
    itemsappend(_parse(source, state))
  File "/usr/lib/python3.2/sre_parse.py", line 520, in _parse
    raise error("nothing to repeat")
sre_constants.error: nothing to repeat
>>> 

The behavior is the same in Python 2.7. Apparently the scan for the special '(?' character sequences happens before the whitespace is stripped out. In my opinion, the behavior should be changed, the documentation should be more clear about the current behavior, or at least the errors given should be more informative (I spent an hour or two debugging the "nothing to repeat" error in my work yesterday.) Thank you.

----------
components: Regular Expressions
messages: 167803
nosy: ezio.melotti, mrabarnett, stevencollins
priority: normal
severity: normal
status: open
title: re.VERBOSE doesn't ignore certain whitespace
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Aug  9 20:40:15 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Aug 2012 18:40:15 +0000
Subject: [New-bugs-announce] [issue15607] New print's argument "flush" is
	not mentioned in	docstring
Message-ID: <1344537615.2.0.181912402642.issue15607@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

New print's argument "flush" is not mentioned in docstring.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 167809
nosy: docs at python, storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: New print's argument "flush" is not mentioned in docstring
versions: Python 3.3

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

From report at bugs.python.org  Thu Aug  9 21:44:26 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 09 Aug 2012 19:44:26 +0000
Subject: [New-bugs-announce] [issue15608] Improve socketserver doc
Message-ID: <1344541466.79.0.410789330017.issue15608@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

On Windows, 3.3 socketserver defines 12 classes in 3 categories: servers, server mixins, and handlers. (At least, these are the one listed with dir(socketserver). Only BaseServer is indexed. I think all should be. There are also a couple of text issues.

BaseServer - indexed, doc is 20.19.2. Server Objects

TCPServer - mentioned in diagram and text of 20.19.1
UDPServer - ditto
(I presume *nix version have unixxxx classes also)

ForkingMixIn - text of 20.19.1
ThreadingMixIn - ditto

ForkingTCPServer
ForkingUDPServer
ThreadingTCPServer
ThreadingUDPServer

Text says "Forking and threading versions of each type of server can be created using the ForkingMixIn and ThreadingMixIn mix-in classes. For instance, a threading UDP server class is created as follows:
  class ThreadingUDPServer(ThreadingMixIn, UDPServer): pass
The mix-in class must come first, since it overrides a method defined in UDPServer."

"can be" means to me that user must create these. I am guessing that pre-defining them was added later. So text should change to 'have been'. The pre-created combinations should be listed. The last sentence could then say "Thhe mix-in class comes first since it overrides...". 

---
BaseRequestHandler

This is documented in 20.19.2 RequestHandler Objects. But instead of starting with something like

class socketserver.BaseRequestHandler 
This is the superclass of all RequestHandler objects. It defines the interface, given below, but does not implement most of the methods, which is done in subclasses. A new instance of the subclass is created for each request.

analogous to the initial entry in 20.19.1, 20.19.2 starts with

"The request handler class must define a new handle() method, and can override any of the following methods. A new instance is created for each request.

I suggest that this be replaced with a standard class entry like the one above. If done, I resume the "RequestHandler" method prefix should be "BaseRequestHandler".

StreamRequestHandler - these two are described in a paragraph
DatagramRequestHandler - after the handle method entry

---
In summary:
1. index all classes to point to locations indicated above.
2. state that mixin combinations are pre-defined.
3. give BaseRequestHandler a proper entry.
4. revise above as needed for *nix.
5. optionally adjust as needed for 2.7.

----------
assignee: docs at python
components: Documentation
messages: 167825
nosy: docs at python, terry.reedy
priority: normal
severity: normal
status: open
title: Improve socketserver doc
versions: Python 3.3

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

From report at bugs.python.org  Thu Aug  9 22:01:46 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Aug 2012 20:01:46 +0000
Subject: [New-bugs-announce] [issue15609] Format string: add more fast-path
Message-ID: <1344542506.78.0.404794794491.issue15609@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch adds tests to check that str%args and str.format(args) take all optimization opportunities for simple format strings. It takes also the fast-path when Unicode string argument when width and/or precision is set. For example, "%.3s" % "abc" now returns "abc" unmodified (instead of creating a copy). The patch also takes the fast-path when formatting integers with str%args when the argument is not an int, but an object with __int__ method.

----------
files: optimize_format.patch
keywords: patch
messages: 167827
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: Format string: add more fast-path
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file26749/optimize_format.patch

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

From report at bugs.python.org  Thu Aug  9 22:04:08 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 09 Aug 2012 20:04:08 +0000
Subject: [New-bugs-announce] [issue15610] PyImport_ImportModuleEx always
	fails in 3.3 with	"ValueError: level must be >= 0"
Message-ID: <1344542648.98.0.69001231241.issue15610@psf.upfronthosting.co.za>


New submission from Dave Malcolm:

I've been testing various 3rd-party python code against 3.3b1, and see
  ValueError: level must be >= 0
exceptions where C code is using PyImport_ImportModuleEx.

PyImport_ImportModuleEx reads as
    63 #define PyImport_ImportModuleEx(n, g, l, f) \
    64     PyImport_ImportModuleLevel(n, g, l, f, -1)
within http://hg.python.org/cpython/file/aaa68dce117e/Include/import.h as of now (2012-08-09)

Within PyImport_ImportModuleLevel there's this check:
  1280      if (level < 0) {
  1281          PyErr_SetString(PyExc_ValueError, "level must be >= 0");
  1282          goto error;
  1283      }
which thus always fires.

So it would seem that currently any usage of PyImport_ImportModuleEx will fail.

----------
components: Interpreter Core
messages: 167828
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: PyImport_ImportModuleEx always fails in 3.3 with "ValueError: level must be >= 0"
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Aug  9 23:14:55 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 09 Aug 2012 21:14:55 +0000
Subject: [New-bugs-announce] [issue15611] devguide: add "core mentors" area
	to Experts Index
Message-ID: <1344546895.77.0.0864519810759.issue15611@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

On the core-mentorship list, Nick Coghlan suggested adding an "area" to the Experts Index for core developers who are on the core-mentorship list (or at least those who wish to be listed).

This issue is to do that.  This can be done by adding a row to the Miscellaneous section with Interest Area "core mentors" or "core mentorship".

http://docs.python.org/devguide/experts.html#miscellaneous

----------
components: Devguide
messages: 167836
nosy: cjerdonek, eric.araujo, ezio.melotti, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: devguide: add "core mentors" area to Experts Index
type: enhancement

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

From report at bugs.python.org  Fri Aug 10 04:30:30 2012
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Aug 2012 02:30:30 +0000
Subject: [New-bugs-announce] [issue15612] Rewriter StringIO to use the
	_PyUnicodeWriter API
Message-ID: <1344565830.56.0.384034899089.issue15612@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch rewrites the C implementation of StringIO to use the _PyUnicodeWriter API instead of the PyAccu API. It provides better performance when writing non-ASCII strings.

The patch adds new functions:

 - _PyUnicodeWriter_Truncate()
 - _PyUnicodeWriter_WriteStrAt()
 - _PyUnicodeWriter_GetValue()

----------
components: IO, Unicode
files: stringio_unicode_writer.patch
keywords: patch
messages: 167850
nosy: ezio.melotti, haypo, pitrou
priority: normal
severity: normal
status: open
title: Rewriter StringIO to use the _PyUnicodeWriter API
versions: Python 3.4
Added file: http://bugs.python.org/file26752/stringio_unicode_writer.patch

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

From report at bugs.python.org  Fri Aug 10 08:06:53 2012
From: report at bugs.python.org (Alex Jurkiewicz)
Date: Fri, 10 Aug 2012 06:06:53 +0000
Subject: [New-bugs-announce] [issue15613] argparse
	ArgumentDefaultsHelpFormatter interacts badly	with --arg and nargs=+
Message-ID: <1344578813.57.0.70269968542.issue15613@psf.upfronthosting.co.za>


New submission from Alex Jurkiewicz:

Sample code:

#!/usr/bin/env python
import argparse

print("\n\narg=foo, nargs=+")
parser = argparse.ArgumentParser(formatter_class=argparse.ArgumentDefaultsHelpFormatter)
parser.add_argument('foo', nargs='+', help='foos', default=['foo1', 'foo2'])
parser.print_help()

print("\n\narg=foo, nargs=*")
parser = argparse.ArgumentParser(formatter_class=argparse.ArgumentDefaultsHelpFormatter)
parser.add_argument('foo', nargs='*', help='foos', default=['foo1', 'foo2'])
parser.print_help()

print("\n\narg=--foo, nargs=+")
parser = argparse.ArgumentParser(formatter_class=argparse.ArgumentDefaultsHelpFormatter)
parser.add_argument('--foo', nargs='+', help='foos', default=['foo1', 'foo2'])
parser.print_help()

print("\n\narg=--foo, nargs=*")
parser = argparse.ArgumentParser(formatter_class=argparse.ArgumentDefaultsHelpFormatter)
parser.add_argument('--foo', nargs='*', help='foos', default=['foo1', 'foo2'])
parser.print_help()


The first example's help text for 'foo' is missing "(default: ['foo1', 'foo2'])". I tested 2.7.2, 2.7.3, 3.2.3.

----------
components: Library (Lib)
messages: 167854
nosy: Alex.Jurkiewicz
priority: normal
severity: normal
status: open
title: argparse ArgumentDefaultsHelpFormatter interacts badly with --arg and nargs=+
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Aug 10 10:20:17 2012
From: report at bugs.python.org (laki)
Date: Fri, 10 Aug 2012 08:20:17 +0000
Subject: [New-bugs-announce] [issue15614] print statement not showing valid
	result
Message-ID: <1344586817.32.0.627259473007.issue15614@psf.upfronthosting.co.za>


New submission from laki:

Python 2.7.3 (default, Apr 10 2012, 23:24:47) [MSC v.1500 64 bit (AMD64)] on win32
>>> a = [1,2]
>>> b = [2,3]
>>> a.extend(b)
>>> a
[1, 2, 2, 3]
>>> print [1,2].extend([2,3])
None

I did not test this in linux.

----------
components: Windows
messages: 167859
nosy: laki
priority: normal
severity: normal
status: open
title: print statement not showing valid result
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug 10 12:12:46 2012
From: report at bugs.python.org (Kushal Das)
Date: Fri, 10 Aug 2012 10:12:46 +0000
Subject: [New-bugs-announce] [issue15615] More tests for JSON decoder to
	test Exceptions
Message-ID: <1344593566.55.0.653447713109.issue15615@psf.upfronthosting.co.za>


New submission from Kushal Das:

Added two more tests in json module to test exception cases. 

test_extra_data: this test checks the error condition when we have extra data in the stream.

test_invalid_escape: this test checks for the invalid escape sequence in the stream

----------
components: Tests
files: json_tests.patch
keywords: patch
messages: 167863
nosy: kushaldas
priority: normal
severity: normal
status: open
title: More tests for JSON decoder to test Exceptions
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26755/json_tests.patch

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

From report at bugs.python.org  Fri Aug 10 12:49:17 2012
From: report at bugs.python.org (Jordi Puigsegur)
Date: Fri, 10 Aug 2012 10:49:17 +0000
Subject: [New-bugs-announce] [issue15616] logging.FileHandler not correctly
	created with PyYaml	(unpickling problems?)
Message-ID: <1344595757.56.0.0377955516485.issue15616@psf.upfronthosting.co.za>


New submission from Jordi Puigsegur:

logging.FileHandler and logging.RotatingFileHandler (haven't tried other handlers) do not get correctly initialized in python 2.7 when loaded using  PyYaml. Therefore I suspect that there is some problem with the implementation of the pickle protocol of these clases in python 2.7.

Attached you can find a small test to reproduce the problem. It works in python 2.5 and 2.6 but fails in python 2.7. In all cases I've used PyYaml 3.10.

----------
components: Extension Modules
messages: 167864
nosy: jordipf
priority: normal
severity: normal
status: open
title: logging.FileHandler not correctly created with PyYaml (unpickling problems?)
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug 10 15:00:52 2012
From: report at bugs.python.org (Floris Bruynooghe)
Date: Fri, 10 Aug 2012 13:00:52 +0000
Subject: [New-bugs-announce] [issue15617] FAIL:
	test_create_connection	(test.test_socket.NetworkConnectionNoServer)
Message-ID: <1344603652.0.0.278766609424.issue15617@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe:

The SPARC Solaris 10 OpenCSW 3.x builder fails with

======================================================================
FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/buildarea/3.x.bruynooghe-solaris-csw/build/Lib/test/test_socket.py", line 4101, in test_create_connection
    self.assertEqual(cm.exception.errno, errno.ECONNREFUSED)
AssertionError: 128 != 146

Here 128 is ENETUNREACH

I think the issue here is that socket.create_connection iterates over the result of socket.getaddrinfo('localhost', port, 0, SOCK_STREAM) which returns [(2, 2, 0, '', ('127.0.0.1', 0)), (26, 2, 0, '', ('::1', 0, 0, 0))] on this host.

The first result is tried and returns ECONNREFUSED but then the second address is tried and this returns ENETUNREACH because this host has not IPv6 network configured.  And create_connection() raises the last exception it received.

If getaddrinfo() is called with the AI_ADDRCONFIG flag then it will only return the IPv4 version of localhost.

----------
components: Tests
messages: 167867
nosy: flub
priority: normal
severity: normal
status: open
title: FAIL: test_create_connection (test.test_socket.NetworkConnectionNoServer)
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Aug 10 18:03:20 2012
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Fri, 10 Aug 2012 16:03:20 +0000
Subject: [New-bugs-announce] [issue15618] turtle.pencolor() chokes on unicode
Message-ID: <1344614600.09.0.172205125468.issue15618@psf.upfronthosting.co.za>


New submission from Juancarlo A?ez:

>>> t.pencolor(u'red')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in pencolor
  File "/usr/lib/python2.7/lib-tk/turtle.py", line 2166, in pencolor
    color = self._colorstr(args)
  File "/usr/lib/python2.7/lib-tk/turtle.py", line 2600, in _colorstr
    return self.screen._colorstr(args)
  File "/usr/lib/python2.7/lib-tk/turtle.py", line 1111, in _colorstr
    r, g, b = [round(255.0*x) for x in (r, g, b)]
TypeError: can't multiply sequence by non-int of type 'float'

----------
components: Library (Lib)
messages: 167883
nosy: apalala
priority: normal
severity: normal
status: open
title: turtle.pencolor() chokes on unicode
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug 10 19:00:37 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Fri, 10 Aug 2012 17:00:37 +0000
Subject: [New-bugs-announce] [issue15619] set.pop() documentation is
	confusing
Message-ID: <1344618037.56.0.180857991175.issue15619@psf.upfronthosting.co.za>


New submission from Anton Barkovsky:

I've seen people being confused by the documentation for set.pop() method. It makes it look like the element is selected randomly while it's
just unspecified.

I'm attaching a patch that clarifies the doc, tested on 3.3, 3.2 and 2.7

----------
assignee: docs at python
components: Documentation
files: set_pop_doc.patch
keywords: patch
messages: 167895
nosy: anton.barkovsky, docs at python
priority: normal
severity: normal
status: open
title: set.pop() documentation is confusing
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26759/set_pop_doc.patch

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

From report at bugs.python.org  Fri Aug 10 23:49:13 2012
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Fri, 10 Aug 2012 21:49:13 +0000
Subject: [New-bugs-announce] [issue15620] readline.clear_history() missing
	in test_readline.py
Message-ID: <1344635353.75.0.297337587104.issue15620@psf.upfronthosting.co.za>


New submission from Juancarlo A?ez:

$ lsb_release -a
LSB Version:	core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch
Distributor ID:	Ubuntu
Description:	Ubuntu 12.04.1 LTS
Release:	12.04
Codename:	precise

$ hg branch
2.7

$ ./python Lib/test/test_readline.py
testHistoryUpdates (__main__.TestHistoryManipulation) ... ERROR

======================================================================
ERROR: testHistoryUpdates (__main__.TestHistoryManipulation)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_readline.py", line 16, in testHistoryUpdates
    readline.clear_history()
AttributeError: 'module' object has no attribute 'clear_history'

----------------------------------------------------------------------
Ran 1 test in 0.003s

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_readline.py", line 43, in <module>
    test_main()
  File "Lib/test/test_readline.py", line 40, in test_main
    run_unittest(TestHistoryManipulation)
  File "/art/python/cpython/Lib/test/test_support.py", line 1125, in run_unittest
    _run_suite(suite)
  File "/art/python/cpython/Lib/test/test_support.py", line 1108, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_readline.py", line 16, in testHistoryUpdates
    readline.clear_history()
AttributeError: 'module' object has no attribute 'clear_history'

----------
components: Tests
messages: 167919
nosy: apalala
priority: normal
severity: normal
status: open
title: readline.clear_history() missing in test_readline.py
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Aug 11 02:19:21 2012
From: report at bugs.python.org (zipher)
Date: Sat, 11 Aug 2012 00:19:21 +0000
Subject: [New-bugs-announce] [issue15621] UnboundLocalError on simple
	in-place assignment of an	inner scope
Message-ID: <1344644361.49.0.381165931673.issue15621@psf.upfronthosting.co.za>


New submission from zipher:

>>> num = 1
>>> def t1():
      print num
>>> t1()
1
>>> def t2():
...   num+=1
...   print num
>>> t2()
UnboundLocalError: local variable 'num' referenced before assignment

It seems num is bound in t1, but not t2, even though they are the same scope.  Am I missing something?

----------
components: Interpreter Core
messages: 167928
nosy: Mark.Janssen
priority: normal
severity: normal
status: open
title: UnboundLocalError on simple in-place assignment of an inner scope
versions: Python 2.7

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

From report at bugs.python.org  Sat Aug 11 09:48:53 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 11 Aug 2012 07:48:53 +0000
Subject: [New-bugs-announce] [issue15622] memoryview.to_list() incorrect for
	'c' format
Message-ID: <1344671333.76.0.693259168971.issue15622@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

PEP 3118 specifies that the 'c'format denotes UCS-1 characters, yet .tolist() converts the memoryview into a list of bytes objects. This is incorrect; it ought to be a list of string objects (as it should for 'u' and 'w' codes). The same holds for item access.

----------
messages: 167937
nosy: loewis, skrah
priority: normal
severity: normal
status: open
title: memoryview.to_list() incorrect for 'c' format
versions: Python 3.3

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

From report at bugs.python.org  Sat Aug 11 17:02:05 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 11 Aug 2012 15:02:05 +0000
Subject: [New-bugs-announce] [issue15623] Init time relative imports no
	longer work from	__init__.so modules
Message-ID: <1344697325.25.0.880049566038.issue15623@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

Since CPython 2.5, relative imports could be used from __init__.so package modules. This stopped working in CPython 3.3.

This is a follow-up ticket to issue15576.

This feature is exercised by Cython's initial_file_path test, which now gives this result:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "__init__.py", line 8, in init my_test_package (my_test_package/__init__.c:1032)
SystemError: Parent module 'my_test_package' not loaded, cannot perform relative import

It is meant to check that Cython provides a fake __path__ for the package module for the init function (as long as issue13429 isn't resolved). With that, relative imports worked before.

The test code is here, failing in line 21 (each section is a separate file), when it tries to do a relative import at the module level, i.e. at module init time.

https://github.com/cython/cython/blob/master/tests/run/initial_file_path.srctree

I'm running the test like this:

python3 runtests.py --no-cpp --no-pyregr --no-unit --debug -vv initial_file_path

I also tried printing sys.modules and the package really isn't registered there yet at the time of the import.

----------
components: Interpreter Core
messages: 167967
nosy: scoder
priority: normal
severity: normal
status: open
title: Init time relative imports no longer work from __init__.so modules
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Aug 11 21:14:24 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 11 Aug 2012 19:14:24 +0000
Subject: [New-bugs-announce] [issue15624] clarify io.TextIOWrapper newline
	documentation
Message-ID: <1344712464.43.0.600420981046.issue15624@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The documentation of io.TextIOWrapper's newline argument is somewhat confusing and perhaps reversed from what was intended.  (For example, the subprocess module uses the reverse terminology.)  Either way, it can be improved somewhat.  Currently, it says--

"* On input, if newline is None,... Lines in the input can end in '\n', '\r', or '\r\n', and these are translated into '\n' before being returned to the caller...
* On output, if newline is None, any '\n' characters written are translated to the system default line separator, os.linesep..."

(from http://docs.python.org/dev/library/io.html#io.TextIOWrapper )

It is somewhat confusing because "On input" does not mean "On input to the buffer," and "On output" does not mean "On output from the buffer."  It is the reverse.

A minimal change to address this would be something along the lines of--

"On input" -> "When reading input from the buffer"
"On output" -> "When writing output to the buffer

The same change could also be made to the open() documentation:

http://docs.python.org/dev/library/functions.html#open

I can prepare a patch for affected versions.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 167995
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: clarify io.TextIOWrapper newline documentation

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

From report at bugs.python.org  Sat Aug 11 23:16:27 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 11 Aug 2012 21:16:27 +0000
Subject: [New-bugs-announce] [issue15625] Support u and w codes in memoryview
Message-ID: <1344719787.86.0.485615026169.issue15625@psf.upfronthosting.co.za>


New submission from Martin v. L?wis:

Currently, the following test case fails:

>>> import array
>>> a=array.array('u', 'foo')
>>> memoryview(a)==memoryview(a)
False

This is because the memoryview object doesn't support the u and w codes, as it should per PEP 3118. This patch fixes it.

----------
files: uwcodes.diff
keywords: patch
messages: 168009
nosy: loewis, ncoghlan, skrah
priority: normal
severity: normal
status: open
title: Support u and w codes in memoryview
Added file: http://bugs.python.org/file26769/uwcodes.diff

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

From report at bugs.python.org  Sun Aug 12 02:12:56 2012
From: report at bugs.python.org (Ben Darnell)
Date: Sun, 12 Aug 2012 00:12:56 +0000
Subject: [New-bugs-announce] [issue15626] unittest.main negates -bb option
	and programmatic	warning configuration
Message-ID: <1344730376.57.0.519562827761.issue15626@psf.upfronthosting.co.za>


New submission from Ben Darnell:

In python 3.2, unittest.main by default modifies the warning configuration if no -W options were given on the command line.  This undoes the effect of -bb, turning BytesWarning back into a warning instead of an error.

If both -bb and -Werror::BytesWarning are given, then unittest does not tamper with the warning configuration and byte operations raise errors as expected (but note that -Werror doesn't work in the current version of virtualenv due to https://github.com/pypa/virtualenv/issues/194 ).  unittest.main should check for the -bb flag in addition to sys.warnoptions.

Additionally, if warning filters were modified programmatically before calling unittest.main, unittest will still modify the configuration and potentially override the user's settings.  This is a rarer case, but I've done it before to avoid the problem with -W in a virtualenv (https://github.com/facebook/tornado/blob/master/tornado/test/runtests.py).  It would be good for there to be some way to tell unittest.main not to touch the warnings at all.  main(warnings=False) currently works, but that's relying on an implementation detail (any non-None, non-truthy value works), so either this should be documented or an official way to do the same thing should be added.

The attached test file demonstrates the problem:  when run with -bb, an warning is logged, but the test passes.

----------
files: testbb.py
messages: 168013
nosy: Ben.Darnell
priority: normal
severity: normal
status: open
title: unittest.main negates -bb option and programmatic warning configuration
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file26771/testbb.py

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

From report at bugs.python.org  Sun Aug 12 02:44:36 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 12 Aug 2012 00:44:36 +0000
Subject: [New-bugs-announce] [issue15627] Add a method to
	importlib.abc.SourceLoader for	converting source to a code object
Message-ID: <1344732276.83.0.543554641885.issue15627@psf.upfronthosting.co.za>


New submission from Brett Cannon:

A classmethod called importlib.abc.SourceLoader.source_to_code(source_bytes, path) would return a code object. By default it would be equivalent to ``compile(source_bytes, source_path, 'exec', dont_inherit=True)``, but others could override this to e.g. convert the source to an AST, optimize the AST, and then call compile() to get the desired code object.

----------
components: Library (Lib)
messages: 168015
nosy: brett.cannon, eric.snow
priority: low
severity: normal
stage: test needed
status: open
title: Add a method to importlib.abc.SourceLoader for converting source to a code object
versions: Python 3.4

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

From report at bugs.python.org  Sun Aug 12 04:07:22 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 12 Aug 2012 02:07:22 +0000
Subject: [New-bugs-announce] [issue15628] Add import ABC hierarchy to docs
	for importlib
Message-ID: <1344737242.66.0.0570077478746.issue15628@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

It would be useful to show import ABC hierarchy in the docs.
See attached patch.

----------
files: import_abc.diff
keywords: patch
messages: 168017
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Add import ABC hierarchy to docs for importlib
versions: Python 3.3
Added file: http://bugs.python.org/file26772/import_abc.diff

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

From report at bugs.python.org  Sun Aug 12 15:54:20 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 12 Aug 2012 13:54:20 +0000
Subject: [New-bugs-announce] [issue15629] Run doctests in Doc/*.rst as part
	of regrtest
Message-ID: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to start running (at least some of) the doctests in the Doc/ folder's *.rst files as part of regrtest.

We will need a whitelist mechanism to tell regrtest which files to process since currently many doctests are not runnable (e.g. some kind of "doctest-safe" marker that can go in a file as suggested by Nick).

See also the discussion thread started here:

http://mail.python.org/pipermail/python-dev/2012-August/121304.html

----------
assignee: docs at python
components: Documentation
messages: 168036
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: Run doctests in Doc/*.rst as part of regrtest
type: enhancement

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

From report at bugs.python.org  Sun Aug 12 17:38:48 2012
From: report at bugs.python.org (Daniel Ellis)
Date: Sun, 12 Aug 2012 15:38:48 +0000
Subject: [New-bugs-announce] [issue15630] Missing "continue" example for
	"for" loop tutorial
Message-ID: <1344785928.67.0.868408879756.issue15630@psf.upfronthosting.co.za>


New submission from Daniel Ellis:

Found by Jesse Bikman:

On this page, http://docs.python.org/tutorial/controlflow.html there is no example in the code of a "continue" statement (section 4.4). It is explained, but not actually used in code.

----------
assignee: docs at python
components: Documentation
messages: 168049
nosy: Daniel.Ellis, docs at python
priority: normal
severity: normal
status: open
title: Missing "continue" example for "for" loop tutorial

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

From report at bugs.python.org  Sun Aug 12 19:58:24 2012
From: report at bugs.python.org (ita1024)
Date: Sun, 12 Aug 2012 17:58:24 +0000
Subject: [New-bugs-announce] [issue15631] Python 3.3 beta 1 installation
	issue lib/lib64 folders
Message-ID: <1344794304.26.0.478120841355.issue15631@psf.upfronthosting.co.za>


New submission from ita1024:

On opensuse 12.1, python 3.3 installs its extensions in /usr/local/lib64/python3.3/lib-dynload/, but the .py files are in /usr/local/lib/python3.3/.

When launching python 3.3 one gets:
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Python 3.3.0b1 (default, Aug 11 2012, 10:45:34) 
[GCC 4.6.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
Traceback (most recent call last):
  File "/etc/pythonstart", line 5, in <module>
    import atexit
  File "<frozen importlib._bootstrap>", line 1294, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1258, in _find_and_load_unlocked
ImportError: No module named 'atexit'

The same thing happens when installing with a --prefix.

Moving the directory lib64/python3.3/lib-dynload to lib/python3.3/lib-dynload fixes the problem.

----------
components: Build
messages: 168059
nosy: ita1024
priority: normal
severity: normal
status: open
title: Python 3.3 beta 1 installation issue lib/lib64 folders
versions: Python 3.3

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

From report at bugs.python.org  Sun Aug 12 21:31:46 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 12 Aug 2012 19:31:46 +0000
Subject: [New-bugs-announce] [issue15632] regrtest.py: spurious leaks with
	-R option
Message-ID: <1344799906.56.0.0975538971998.issue15632@psf.upfronthosting.co.za>


New submission from Stefan Krah:

With the -R option, test_buffer.py needs an additional warm-up for
the unicode_latin1 cache. Patch attached.

----------
components: Tests
files: warm_latin1_cache.diff
keywords: patch
messages: 168063
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: regrtest.py: spurious leaks with -R option
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26777/warm_latin1_cache.diff

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

From report at bugs.python.org  Mon Aug 13 03:31:03 2012
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 13 Aug 2012 01:31:03 +0000
Subject: [New-bugs-announce] [issue15633] httplib.response is not closed
	after all data has been	read
Message-ID: <1344821463.76.0.139090148106.issue15633@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

Occasionally, the isclosed() method of HTTPResponse instances returns False, even though a preceding read() call returned '' (or something else that evalues to False).

This is a problem, because then the corresponding HTTPConnection can still be used to send another request, but an attempt to retrieve its response result it in ResponseNotReady() exception.

I have not found anything special about the requests for which this happens. I also looked at the httplib code and found no way for this to happen, but obviously I am missing something. Maybe someone more familiar with the codebase can tell what's happening there.

The problem happens to rarely to be able to run packet capture, but I can provide attributes of the relevant httplib instances if desired.

----------
components: Library (Lib)
messages: 168068
nosy: Nikratio
priority: normal
severity: normal
status: open
title: httplib.response is not closed after all data has been read
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Aug 13 10:04:28 2012
From: report at bugs.python.org (Juan Javier)
Date: Mon, 13 Aug 2012 08:04:28 +0000
Subject: [New-bugs-announce] [issue15634] synchronized decorator for the
	threading module
Message-ID: <1344845068.87.0.536585589553.issue15634@psf.upfronthosting.co.za>


New submission from Juan Javier:

I think it will be useful to have a decorator like this one on the threading module:

def synchronized(func):
    """A decorator to make a function execution synchronized.

    Examples:

    @synchronized
    def foo():
        pass

    class Foo:
        def __init__(self):
            self.__syncdata = None

        @property
        def syncdata(self):
            return self.__syncdata

        @syncdata.setter
        @synchronized
        def syncdata(self, value):
            self.__syncdata = value
    """
    if not hasattr(func, "__lock"):
        func.__lock = threading.Lock()
    def _synchronized(*args, **kwds):
        with func.__lock:
            func(*args, **kwds)
    _synchronized.__doc__ = func.__doc__
    return _synchronized

What do you think?

----------
components: Library (Lib)
messages: 168071
nosy: jjdominguezm
priority: normal
severity: normal
status: open
title: synchronized decorator for the threading module
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug 13 11:25:31 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 13 Aug 2012 09:25:31 +0000
Subject: [New-bugs-announce] [issue15635] memory leak with generators
Message-ID: <1344849931.31.0.449386115809.issue15635@psf.upfronthosting.co.za>


New submission from Florent Xicluna:

Hello,

I noticed a large memory consumption in my application.
I tracked it down to be a problem with garbage collection of generator locals.

The issue was noticed in 2.6 first. Then I reproduced it in 2.7.
The test case finds some leak in 3.3 too, it seems.

----------
components: Interpreter Core
files: testiterbug.py
messages: 168072
nosy: flox
priority: normal
severity: normal
status: open
title: memory leak with generators
type: resource usage
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26779/testiterbug.py

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

From report at bugs.python.org  Mon Aug 13 13:47:10 2012
From: report at bugs.python.org (Andrew Scheller)
Date: Mon, 13 Aug 2012 11:47:10 +0000
Subject: [New-bugs-announce] [issue15636] base64.decodebytes is only
	available in Python3.1+
Message-ID: <1344858430.17.0.615853795219.issue15636@psf.upfronthosting.co.za>


New submission from Andrew Scheller:

According to the documentation ( http://docs.python.org/py3k/library/base64.html#base64.decodebytes ) both the decodebytes and the deprecated decodestring methods are available in the base64 module in Python3.x
However in Python3.0 (I'm testing with version 3.0.1 built from source) the base64 module only has the decodestring method, it doesn't have decodebytes. IMHO the documentation should be updated to reflect this.

It looks like decodebytes was added to Python3.1 by http://bugs.python.org/issue3613

----------
assignee: docs at python
components: Documentation
messages: 168080
nosy: docs at python, lurchman
priority: normal
severity: normal
status: open
title: base64.decodebytes is only available in Python3.1+
type: enhancement
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Aug 13 14:20:15 2012
From: report at bugs.python.org (Alberto Milone)
Date: Mon, 13 Aug 2012 12:20:15 +0000
Subject: [New-bugs-announce] [issue15637] Segfault reading null VMA (works
	fine in python 2.x)
Message-ID: <1344860415.33.0.2201769173.issue15637@psf.upfronthosting.co.za>


New submission from Alberto Milone:

The attached test case works fine in Python 2.7 but causes Pyhton 3.2 to segfault.

----------
components: ctypes
files: randr_test
messages: 168087
nosy: albertomilone
priority: normal
severity: normal
status: open
title: Segfault reading null VMA (works fine in python 2.x)
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file26782/randr_test

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

From report at bugs.python.org  Mon Aug 13 14:36:42 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 13 Aug 2012 12:36:42 +0000
Subject: [New-bugs-announce] [issue15638] incorrect version info for
	TextIOWrapper write_through	docs
Message-ID: <1344861402.45.0.422601843379.issue15638@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The io.TextIOWrapper documentation says that the write_through argument was added in version 3.3:

"Changed in version 3.3: The write_through argument has been added."

http://docs.python.org/dev/library/io.html#io.TextIOWrapper

However, it seems to be present in 3.2.  Also, the 3.2 documentation does not mention the write_through argument.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 168092
nosy: asvetlov, cjerdonek, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: incorrect version info for TextIOWrapper write_through docs
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Aug 13 14:45:00 2012
From: report at bugs.python.org (Xavier Morel)
Date: Mon, 13 Aug 2012 12:45:00 +0000
Subject: [New-bugs-announce] [issue15639] csv.Error description is
	incorrectly broad
Message-ID: <1344861900.41.0.500081964818.issue15639@psf.upfronthosting.co.za>


New submission from Xavier Morel:

In both Python 2.7 and Python 3.x, csv.Error is documented as:

    Raised by any of the functions when an error is detected.

As far as I can tell from using the module and looking at the code, this is completely incorrect. There is actually a single instance of csv.Error being used: the instantiation of csv.Dialect (which converts TypeError raised from _csv._Dialect() into csv.Error, a comment notes that this is "for compatibility with py 2.3").

And the only way to hit that code paths seems to be subclassing `Dialect` and putting incorrect values in the various attributes (providing them to `csv.reader` raises a TypeError).

I believe the documentation to csv.Error should be changed to:

1. Mark it as effectively deprecated
2. Indicate that the only situation in which it it may be raised is when initializing a subclass of csv.Dialect

----------
assignee: docs at python
components: Documentation
messages: 168096
nosy: docs at python, xmorel
priority: normal
severity: normal
status: open
title: csv.Error description is incorrectly broad
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Aug 13 21:47:18 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 13 Aug 2012 19:47:18 +0000
Subject: [New-bugs-announce] [issue15640] Document deprecate
	importlib.abc.Finder
Message-ID: <1344887238.09.0.248857343378.issue15640@psf.upfronthosting.co.za>


New submission from Brett Cannon:

importlib.abc.Finder is no longer the proper level of abstraction for either meta path finders or path entry finders, so direct inheritance should be discouraged by documenting deprecation for the class (actual deprecation will need to be avoided as the constructor gets involved and having that error out if someone sets warnings to errors would be bad). Should probably also document as deprecated importlib.abc.PathEntryFinder.find_module().

Also need to remember to update the inheritance hierarchy now added to the docs with a note next to the class about the deprecation (along with PyLoader and PyPycLoader).

----------
assignee: brett.cannon
components: Documentation
messages: 168138
nosy: barry, brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Document deprecate importlib.abc.Finder
versions: Python 3.3

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

From report at bugs.python.org  Mon Aug 13 22:00:35 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 13 Aug 2012 20:00:35 +0000
Subject: [New-bugs-announce] [issue15641] Clean up importlib for Python 3.4
Message-ID: <1344888035.57.0.935580041455.issue15641@psf.upfronthosting.co.za>


New submission from Brett Cannon:

importlib.abc.PyLoader and importlib.abc.PyPycLoader were both deprecated in 3.2 and slated for removal in Python 3.4. There is also some os2 stuff in importlib._bootstrap which can go as PEP 11 has os2 support slated for removal in Python 3.4.

----------
assignee: brett.cannon
messages: 168140
nosy: brett.cannon, eric.snow, ncoghlan
priority: low
severity: normal
stage: needs patch
status: open
title: Clean up importlib for Python 3.4
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug 13 22:48:40 2012
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 13 Aug 2012 20:48:40 +0000
Subject: [New-bugs-announce] [issue15642] Integrate pickle protocol version
	4 GSoC work by Stefan	Mihaila
Message-ID: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za>


New submission from Alexandre Vassalotti:

Stefan Mihaila has been working on the implementation of PEP 3154, plus some other enhancements. His work is pretty complete and ready to be reviewed. I will do my best to finish a thorough review of his changes by the end of next week.

----------
assignee: alexandre.vassalotti
components: Library (Lib)
hgrepos: 145
keywords: gsoc, patch
messages: 168144
nosy: alexandre.vassalotti, mstefanro, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Integrate pickle protocol version 4 GSoC work by Stefan Mihaila
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug 14 00:15:35 2012
From: report at bugs.python.org (Floris Bruynooghe)
Date: Mon, 13 Aug 2012 22:15:35 +0000
Subject: [New-bugs-announce] [issue15643] Support OpenCSW in setup.py
Message-ID: <1344896135.95.0.0625174180507.issue15643@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe:

This patch proposes to add out of the box support for building against OpenCSW libraries on Solaris.  It makes building all the extension modules a lot simpler since the CSW repositories provide almost all required libaries.

The order of preference is /usr/local, then /opt/csw which should prefer libaries manually installed by the admin.

----------
components: Build
files: csw_setup.py.diff
keywords: patch
messages: 168156
nosy: flub
priority: normal
severity: normal
status: open
title: Support OpenCSW in setup.py
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26789/csw_setup.py.diff

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

From report at bugs.python.org  Tue Aug 14 07:03:31 2012
From: report at bugs.python.org (umedoblock)
Date: Tue, 14 Aug 2012 05:03:31 +0000
Subject: [New-bugs-announce] [issue15644] after _bytesio.seek(0),
	_bytesio.getvalue() returned reversed data.
Message-ID: <1344920611.47.0.245957417255.issue15644@psf.upfronthosting.co.za>


New submission from umedoblock:

import io
_bytesio = io.BytesIO()

_bytesio.write(b'abc')
_bytesio.write(b'def')
_bytesio.seek(0)
_bytesio.write(b'xyz')

print(_bytesio.read(2))
print(_bytesio.read(2))
print(_bytesio.getvalue())

# output
b'de'
b'f'
b'xyzdef'
# where is the b'abc' ?

----------
components: IO
messages: 168174
nosy: umedoblock
priority: normal
severity: normal
status: open
title: after _bytesio.seek(0), _bytesio.getvalue() returned reversed data.
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Aug 14 10:16:20 2012
From: report at bugs.python.org (Stefan Holek)
Date: Tue, 14 Aug 2012 08:16:20 +0000
Subject: [New-bugs-announce] [issue15645] 2to3 Grammar pickles not created
	when upgrading to	3.3.0b2
Message-ID: <1344932180.41.0.826216341416.issue15645@psf.upfronthosting.co.za>


New submission from Stefan Holek:

After upgrading 3.3.0b1 to b2 (make install to same location) I noticed that the Grammar pickles for beta.2 were missing (the beta.1 pickles still being there).

The result is permission errors and/or virtualenv SandboxViolations, when 2to3 is used for the first time. E.g.:

SandboxViolation: open('/usr/local/python3.3/lib/python3.3/lib2to3/Grammar3.3.0.beta.2.pickle', 'wb') {}

This is because users of Python (as opposed to root) may of course not write to the library dir.

The pickles are created fine on a fresh install of Python 3.3.0b2 (make install to new location).

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 168180
nosy: stefanholek
priority: normal
severity: normal
status: open
title: 2to3 Grammar pickles not created when upgrading to 3.3.0b2
versions: Python 3.3

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

From report at bugs.python.org  Tue Aug 14 12:34:33 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 14 Aug 2012 10:34:33 +0000
Subject: [New-bugs-announce] [issue15646] multiprocessing can do equivalent
	of a fork bomb on	Windows
Message-ID: <1344940473.31.0.674341718518.issue15646@psf.upfronthosting.co.za>


New submission from Richard Oudkerk:

If the "if __name__ == '__main__'" idiom is not used on Windows you can get the recursive starting of new processes.

This is because importing the main module in a child process starts a new child process as a side effect.

There is a test intended to prevent this and raise RuntimeError instead, but it is currently ineffective.

----------
messages: 168189
nosy: sbt
priority: normal
severity: normal
status: open
title: multiprocessing can do equivalent of a fork bomb on Windows
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug 14 12:41:12 2012
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 14 Aug 2012 10:41:12 +0000
Subject: [New-bugs-announce] [issue15647] isdir should be a local symbol,
	not exported
Message-ID: <1344940872.16.0.49661392396.issue15647@psf.upfronthosting.co.za>


New submission from Matthias Klose:

2.7 only:

isdir should not be exported, but a local symbol instead (this was accidentally changed after the 2.7.3 release.

currently defined and used in Modules/getpath.c and Python/import.c, and used in Python/bltinmodule.c

proposal to rename the implementation in import.c to _Py_isdir and use it in import.c and bltinmodule.c.

as an alternative, make the isdir implementation static for windows and posix builds.

----------
components: Interpreter Core
files: local-isdir-symbol.diff
keywords: needs review, patch
messages: 168190
nosy: doko
priority: normal
severity: normal
status: open
title: isdir should be a local symbol, not exported
versions: Python 2.7
Added file: http://bugs.python.org/file26801/local-isdir-symbol.diff

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

From report at bugs.python.org  Tue Aug 14 13:40:28 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 14 Aug 2012 11:40:28 +0000
Subject: [New-bugs-announce] [issue15648] stderr "refs" output does not
	respect PYTHONIOENCODING
Message-ID: <1344944428.64.0.0280287905357.issue15648@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

The --help documentation for the python executable says--

PYTHONIOENCODING: Encoding[:errors] used for stdin/stdout/stderr.

However, PYTHONIOENCODING doesn't seem to be respected for the python executable's "refs" output to stderr.  For example, this--

args = [sys.executable, '-c', "print('[100 refs]')"]

env = {'PYTHONIOENCODING': 'utf-8'}
popen = Popen(args, universal_newlines=False, stdin=PIPE, stdout=PIPE, stderr=PIPE, env=env)
print(repr(popen.communicate()))

env = {'PYTHONIOENCODING': 'utf-16'}
popen = Popen(args, universal_newlines=False, stdin=PIPE, stdout=PIPE, stderr=PIPE, env=env)
print(repr(popen.communicate()))

yields--

(b'[10 refs]\n', b'[41761 refs]\n')
(b'[\x001\x000\x00 \x00r\x00e\x00f\x00s\x00]\x00\n\x00', b'[42367 refs]\n')

----------
messages: 168192
nosy: cjerdonek
priority: normal
severity: normal
status: open
title: stderr "refs" output does not respect PYTHONIOENCODING
versions: Python 3.3

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

From report at bugs.python.org  Tue Aug 14 17:47:01 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 14 Aug 2012 15:47:01 +0000
Subject: [New-bugs-announce] [issue15649] subprocess.Popen.communicate:
	accept str for input	parameter if universal_newlines is False
Message-ID: <1344959221.38.0.0409924242397.issue15649@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

Currently Popen.communicate accept str is universal_newlines==True and bytes if universal_newlines==False.

I like to accept both str and bytes if universal_newlines is False and raise explicit exception for bytes if universal_newlines is True.

Looks like universal_newlines for bytes doesn't make sense, also we prefer to use str everywhere. Bytes should be used if it is really byte-stream or if unicode cannot be passed by some limitations of underlying OS etc.

There are couple dark corners:
1. What to do if stdin doesn't have `encoding` attribute? Convert to bytes using filesystemencoding? Raise explicit exception? Adding `encode` parameter for .communicate doesn't looks elegant.
2. How .communicate works on Windows? I see completely different implementation of this method for win32.

----------
messages: 168207
nosy: asvetlov
priority: normal
severity: normal
stage: needs patch
status: open
title: subprocess.Popen.communicate: accept str for input parameter if universal_newlines is False
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug 14 20:14:34 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Tue, 14 Aug 2012 18:14:34 +0000
Subject: [New-bugs-announce] [issue15650] PEP 3121,
	384 refactoring applied to dbm module
Message-ID: <1344968074.48.0.47544287235.issue15650@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the dbm module!

----------
components: Extension Modules
files: _dbmmodule_pep3121-384_v0.patch
keywords: patch
messages: 168216
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 refactoring applied to dbm module
versions: Python 3.4
Added file: http://bugs.python.org/file26804/_dbmmodule_pep3121-384_v0.patch

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

From report at bugs.python.org  Tue Aug 14 20:25:21 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Tue, 14 Aug 2012 18:25:21 +0000
Subject: [New-bugs-announce] [issue15651] PEP 3121,
	384 refactoring applied to elementtree module
Message-ID: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the elementtree module!

----------
components: Extension Modules
files: _elementtree_pep3121-384_v0.patch
keywords: patch
messages: 168217
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 refactoring applied to elementtree module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26805/_elementtree_pep3121-384_v0.patch

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

From report at bugs.python.org  Tue Aug 14 20:31:40 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Tue, 14 Aug 2012 18:31:40 +0000
Subject: [New-bugs-announce] [issue15652] PEP 3121,
	384 refactoring applied to gdbm module
Message-ID: <1344969100.54.0.643991722265.issue15652@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the gdbm module!

----------
components: Extension Modules
files: _gdbm_pep3121-384_v0.patch
keywords: patch
messages: 168219
nosy: Robin.Schreiber, anthony_baxter
priority: normal
severity: normal
status: open
title: PEP 3121, 384 refactoring applied to gdbm module
versions: Python 3.4
Added file: http://bugs.python.org/file26806/_gdbm_pep3121-384_v0.patch

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

From report at bugs.python.org  Tue Aug 14 20:42:13 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Tue, 14 Aug 2012 18:42:13 +0000
Subject: [New-bugs-announce] [issue15653] PEP 3121,
	384 refactoring applied to hashopenssl module
Message-ID: <1344969733.85.0.308586175776.issue15653@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the hashopenssl module!

----------
components: Extension Modules
files: _hashopenssl_pep3121-384_v0.patch
keywords: patch
messages: 168220
nosy: Robin.Schreiber, gstein
priority: normal
severity: normal
status: open
title: PEP 3121, 384 refactoring applied to hashopenssl module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26807/_hashopenssl_pep3121-384_v0.patch

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

From report at bugs.python.org  Tue Aug 14 20:47:38 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Tue, 14 Aug 2012 18:47:38 +0000
Subject: [New-bugs-announce] [issue15654] PEP 384 Refactoring applied to bz2
	module
Message-ID: <1344970058.86.0.178955604138.issue15654@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP384 have now been applied to the bz2 module!

----------
components: Extension Modules
files: _bz2_pep384_v0.patch
keywords: patch
messages: 168221
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 384 Refactoring applied to bz2 module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26808/_bz2_pep384_v0.patch

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

From report at bugs.python.org  Tue Aug 14 20:53:18 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Tue, 14 Aug 2012 18:53:18 +0000
Subject: [New-bugs-announce] [issue15655] PEP 384 Refactoring applied to
	json module
Message-ID: <1344970398.16.0.223655068768.issue15655@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the json module!

----------
components: Extension Modules
files: _json_pep384_v0.patch
keywords: patch
messages: 168222
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 384 Refactoring applied to json module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26809/_json_pep384_v0.patch

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

From report at bugs.python.org  Tue Aug 14 20:57:45 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 14 Aug 2012 18:57:45 +0000
Subject: [New-bugs-announce] [issue15656] "Extending Python with C" page
	needs update for 3.x
Message-ID: <1344970665.85.0.951420699824.issue15656@psf.upfronthosting.co.za>


New submission from Sandro Tosi:

Hello,
this has been reported at http://mail.python.org/pipermail/docs/2012-July/009223.html but since I have no experience to judge if it's correct or not, i'll just report it:

>>>
I've recenty started to try using C code in python using the wonderful
python API, although i have to say the learning curve was non neglectable :P
I've spotted what I believe to be a small mistake in the documentation
from this page:
http://docs.python.org/release/3.2/extending/extending.html

In paragraph 1.8
(http://docs.python.org/release/3.2/extending/extending.html#keyword-parameters-for-extension-functions),
the code example given contains an error, which is actually obsolete
code from python 2.7:

void
initkeywdarg(void)
{
  /* Create the module and add the functions */
  Py_InitModule("keywdarg", keywdarg_methods);
}


This doesn't work in Python3.2. It's supposed to be

static struct PyModuleDef keywdargmodule = {
   PyModuleDef_HEAD_INIT,
   "keywdarg",   /* name of module */
   keywdarg_doc, /* module documentation, may be NULL */
   -1,       /* size of per-interpreter state of the module,
                or -1 if the module keeps state in global variables. */
   keywdarg_methods
};

PyMODINIT_FUNC
PyInit_keywdarg(void)
{
    return PyModule_Create(&keywdargmodule);
}

As explained above (and confirmed by experience).
<<<

----------
assignee: docs at python
components: Documentation
messages: 168223
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: "Extending Python with C" page needs update for 3.x
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug 14 21:02:46 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 14 Aug 2012 19:02:46 +0000
Subject: [New-bugs-announce] [issue15657] Error in Python 3 docs for
	PyMethodDef
Message-ID: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za>


New submission from Sandro Tosi:

Hello,
it has been reported at http://mail.python.org/pipermail/docs/2012-April/008215.html but given it raises some question whether it's a bug in the doc or in the code, i'd rather report the issue here and hear what other think:

>>>
In the Python 3.2.2 documentation (and earlier Python 3 versions), in
the Python/C API Reference Manual, chapter Object Implementation
Support, the documentation for PyMethodDef says:

  The ml_flags field is a bitfield which can include the following
  flags. The individual flags indicate either a calling convention or a
  binding convention. Of the calling convention flags, only METH_VARARGS
  and METH_KEYWORDS can be combined (but note that METH_KEYWORDS alone
  is equivalent to METH_VARARGS | METH_KEYWORDS).

The bit in the parenthetical is incorrect.  If you take a look at
PyCFunction_Call in Objects/methodobject.c, you will find a switch for
METH_VARARGS | METH_KEYWORDS, but no switch for METH_KEYWORDS.  Hence,
using METH_KEYWORDS will land you with a SystemError that complains
about METH_OLDARGS.

This is either a bug in the documentation, or a bug in Python.  In this
case, since the code has persisted through three major revisions of
Python 3, I suggest that the bug _is_ in the documentation (whether it
should be or not), since changing the code for this at this late date
means a programmer has to use METH_VARARGS | METH_KEYWORDS anyway for
compatibility.

It may be work pointing out specifically in the documentation that just
using METH_KEYWORDS will not work.
<<<

----------
assignee: docs at python
components: Documentation
messages: 168226
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Error in Python 3 docs for PyMethodDef
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Aug 15 00:41:17 2012
From: report at bugs.python.org (Oskars)
Date: Tue, 14 Aug 2012 22:41:17 +0000
Subject: [New-bugs-announce] [issue15658] Idle stopped working
Message-ID: <1344984077.82.0.261608430335.issue15658@psf.upfronthosting.co.za>


New submission from Oskars:

For some years I used Python with IDLE, including my Windows 7 machine.  In January IDLE stopped working.  Whenever I tried to open with file with IDLE, nothing happened.  No error message.  Nothing.

After some help from help at python.org I typed at the command line "C:\Python27\Lib\idlelib\idle.py -n" and I got this error:
IO Error: [Errno 13] Permission denied: 'C:\\Users\\Osk\\.idlerc\\recent-files.lst'

So I went to look at the directory .idlerc and found it empty.  No recent-files.lst. (Though it may be because it is a hidden file)

Now I think the problem is fixed - or at least for the time being.

I went to the admin identity and found that IDLE does open up there.  So I made a copy of the recent-files.lst file and emailed it to myself.  Then I went to my wife's identity.  And, again, IDLE opened OK.

Finally, I went back to my identity and renamed the file there to "recent-files-H.lst".  Then I retrieved the file I had emailed to myself and placed it into the .idlerc directory of my account as "recent-files.lst".

Suddenly I could open IDLE and run Python, as before!

The mystery remains - what happened?  When I compared the contents of the old recent-files.lst and the one I replace it with, the only difference I could find is that the old one had 17 entries, the new one had only one entry.

----------
components: IDLE
messages: 168244
nosy: opapOj
priority: normal
severity: normal
status: open
title: Idle stopped working
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug 15 03:30:19 2012
From: report at bugs.python.org (Michael)
Date: Wed, 15 Aug 2012 01:30:19 +0000
Subject: [New-bugs-announce] [issue15659] using os.fork() and import user's
	modules results in	errors
Message-ID: <1344994219.74.0.135475892924.issue15659@psf.upfronthosting.co.za>


New submission from Michael:

if I import any python script in the beginning of the code in then I haver next errors:

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/lib/python2.7/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/usr/lib/python2.7/multiprocessing/util.py", line 295, in _exit_function
    p.join()
  File "/usr/lib/python2.7/multiprocessing/process.py", line 143, in join
    assert self._parent_pid == os.getpid(), 'can only join a child process'
AssertionError: can only join a child process
Error in sys.exitfunc:
Traceback (most recent call last):
  File "/usr/lib/python2.7/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/usr/lib/python2.7/multiprocessing/util.py", line 295, in _exit_function
    p.join()
  File "/usr/lib/python2.7/multiprocessing/process.py", line 143, in join
    assert self._parent_pid == os.getpid(), 'can only join a child process'
AssertionError: can only join a child process

----------
components: None
files: mydaemon.py
messages: 168251
nosy: michaeluc
priority: normal
severity: normal
status: open
title: using os.fork() and import user's modules results in errors
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26816/mydaemon.py

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

From report at bugs.python.org  Wed Aug 15 06:20:40 2012
From: report at bugs.python.org (py.user)
Date: Wed, 15 Aug 2012 04:20:40 +0000
Subject: [New-bugs-announce] [issue15660] In str.format there is a
	misleading error message about	alignment
Message-ID: <1345004440.11.0.680139192916.issue15660@psf.upfronthosting.co.za>


New submission from py.user:

>>> '{:02}'.format('a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: '=' alignment not allowed in string format specifier
>>>


according to http://docs.python.org/py3k/library/string.html#formatspec
the default alignment is '<' or '>'

----------
components: Interpreter Core
messages: 168258
nosy: py.user
priority: normal
severity: normal
status: open
title: In str.format there is a misleading error message about alignment
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Wed Aug 15 08:55:07 2012
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Aug 2012 06:55:07 +0000
Subject: [New-bugs-announce] [issue15661] OS X installer packages should be
	signed for OS X 10.8	Gatekeeper feature
Message-ID: <1345013707.82.0.343684011424.issue15661@psf.upfronthosting.co.za>


New submission from Ned Deily:

OS 10.8 Mountain Lion includes a new feature that "helps protect users from downloading and installing malicious software" by providing a mechanism for developers to sign their installable objects with a unique Apple-signed Developer ID certificate.  The default security policy for 10.8 is to only allow installation of items that have been signed.  The user is able to override that policy either persistently for all installs (using System Preferences) or selectively for individual unsigned items (for example, by using control-click and "Open with").

OS X allows various items to be signed, including executables, application bundles, application frameworks, and installer packages.  The python.org OS X installations includes all of these.  For applications to be made available through the Mac App Store, all of these have to be signed and there are additional requirements, such as sandboxing and restrictions on API usage, that are not compatible with a general-purpose programming environment such as Python provides.  Therefore, this issue is only concerned with meeting the requirements for 10.8 Gatekeeper and "Distributing Outside the Mac App Store" (see references below).

Each python.org OS X release is delivered via an OS X installer package (.mpkg) within an OS X diskimage file (.dmg) and installed using the standard OS X installer.  So, at a minimum, the only entity that needs to be signed is each installer package we produce.  Unfortunately, the Python installer build process (as encapsulated in Mac/BuildScript/build-installer.py) currently packages releases in an old deprecated bundle (non-flat) metapackage format that cannot be signed.  That means build-installer.py and the manual process surrounding releases need to be updated to produce the newer flat package formats that can then be signed using a unique Developer ID Installer certificate requested from and signed by Apple.

Several points:

1. The changes needed to support the newer sign-able installer formats should be able to be limited to python-installer.py itself and so should minimize risk to other releases and Python itself.  Likewise, to the end user, the installation process should look (nearly) identical to the current process as the same system installer app is used.  Of course, the install process will need to be tested to ensure that the new format packages produce the same results (i.e. files, permissions) on the user system as the old format packages do.  It may be possible and desirable to include these changes in the upcoming 3.3.0 release or, if not available in time, in a subsequent 3.3.x maintenance release.  (I am currently working on the changes.)

2. There is a process question of what Developer ID(s) to use for requesting Installer certificates for singing.  As documented, Apple requires the requestor of a singing certificate to be a member of the Mac Developer Program which normally involves a modest annual fee.  One can be a member of the developer program as an individual developer or as a member of a development team associated with a company or other legal entity.  This distinction affects how the installation is presented to the user.  I believe that we should aim to have a Python Software Foundation development team membership with the builders of python.org releases as team members as needed (currently that means me with Ronald as backup).  It is beyond the scope of this issue to define and implement that process.  In the immediate future, once the new installer package is supported, in lieu of a PSF-backed certificate, it *may* be desirable to sign the package with an individual certificate (both Ronald and I are individual members of the developer program).  That is roughly analogous to the current practice of using individual release team members' PGP keys to sign Python release artifacts (source tar balls and binary installers) that are downloadable from python.org although it may not be as visible to the user as the Gatekeeper signing.  We will pursue the development team option outside of this tracker issue with PSF officers.

3. I believe it is the case that the newer flat package formats are not supported on OS X 10.3 and only partially supported on OS X 10.4.  For Python 2.7.x and 3.2.x, we have been producing two installers: a 32-bit-only installer for 10.3+ and a 64-bit/32-bit installer for 10.6+.  For Python 3.3, we have changed the minimum requirements for the 32-bit-only installer to be 10.5+.  So it should be possible to move all 3.3.x installers to the new format and sign them.  For older releases, we will have to look at the tradeoffs. Since we have kept the build-installer.py script identical for current releases of Python 2.7.x and Python 3.2.x, additional implementation costs and risks are small: the modified 3.3.0 script should work for 3.2.x and 2.7.x releases as well.  Without introducing ABI incompatibilities within a major release cycle, one option may be to: do not change the 2.7.x 32-bit-installer format (so that it is still usable on 10.3 and 10.4), change the 2.7.x 64-bit-installer to the new format so it can be signed, and either do the same for 3.2.x or do nothing new (since 3.2.x will be entering security-fix-only mode sometime after the release of 3.3.0).

The open issues should be decided after implementing the new format support and testing to see if the assumptions are correct.

References:

http://support.apple.com/kb/HT5290
https://developer.apple.com/resources/developer-id/
https://developer.apple.com/programs/mac/team.html

----------
assignee: ned.deily
components: Build, Installation, Macintosh
messages: 168262
nosy: ned.deily, ronaldoussoren
priority: high
severity: normal
stage: needs patch
status: open
title: OS X installer packages should be signed for OS X 10.8 Gatekeeper feature
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Aug 15 11:05:32 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Wed, 15 Aug 2012 09:05:32 +0000
Subject: [New-bugs-announce] [issue15662] PEP 3121 refactoring applied to
	locale module
Message-ID: <1345021532.95.0.601509802957.issue15662@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 have now been applied to the locale module!

----------
components: Extension Modules
files: _locale_pep3121_v0.patch
keywords: patch
messages: 168268
nosy: Robin.Schreiber, loewis
priority: normal
severity: normal
status: open
title: PEP 3121 refactoring applied to locale module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26819/_locale_pep3121_v0.patch

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

From report at bugs.python.org  Wed Aug 15 11:20:34 2012
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Aug 2012 09:20:34 +0000
Subject: [New-bugs-announce] [issue15663] Investigate providing Tcl/Tk 8.5
	with OS X installers
Message-ID: <1345022434.53.0.691858342769.issue15663@psf.upfronthosting.co.za>


New submission from Ned Deily:

The current situation with Tcl/Tk on OS X is less than ideal.  The Apple-supplied versions of the Cocoa-based Aqua Tk 8.5 on 10.6 was unusable with IDLE and most Tkinter applications.  The 10.7 and 10.8 versions are better but still have serious crashers that have been more recently fixed.  python.org installers currently also support using ActiveTcl release but that is also not ideal as there are license restrictions for some users and a separate download and install is required.  We should be able to provide a better out-of-the-box experience if python.org installers included its own copies of up-to-date Tcl/Tk libraries (as is the case with the Windows installers).  It would be good to still give users the option to use ActiveTcl for any of its additional features or to use system Python.  Also we could also look at providing Tcl/Tk 8.5 for 10.5 users (possibly only Intel ones) which we currently do not.

----------
assignee: ned.deily
components: Build, Installation, Macintosh
messages: 168269
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Investigate providing Tcl/Tk 8.5 with OS X installers
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 15 12:31:19 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 15 Aug 2012 10:31:19 +0000
Subject: [New-bugs-announce] [issue15664] test_curses not run with 'make
	test'
Message-ID: <1345026679.72.0.767220182308.issue15664@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

I noticed that 'test_curses' is not started when performing "make test" on an OSX box:

...
[ 42/369] test_curses
test_curses skipped -- sys.__stdout__ is not a tty
...

The host is a machine running OSX 10.8, fully up-to-date with patches and the current version of Xcode. 

The same thing happens when starting the testrunning in the same way as used by the test target in the Makefile:

$ ./python.exe -W default -bb -E -R -m test -r -w -j 0 -u all,-largefile,-audio,-gui test_curses
Using random seed 9471227
[1/1] test_curses
test_curses skipped -- sys.__stdout__ is not a tty
1 test skipped:
    test_curses
Those skips are all expected on darwin.

----------
components: Tests
messages: 168272
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: test_curses not run with 'make test'
versions: Python 3.3

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

From report at bugs.python.org  Wed Aug 15 15:06:02 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Wed, 15 Aug 2012 13:06:02 +0000
Subject: [New-bugs-announce] [issue15665] PEP 3121,
	384 refactoring applied to lsprof module
Message-ID: <1345035962.65.0.979590709355.issue15665@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the lsprof module!

----------
components: Extension Modules
files: _lsprof_pep3121-384_v0.patch
keywords: patch
messages: 168292
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 refactoring applied to lsprof module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26823/_lsprof_pep3121-384_v0.patch

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

From report at bugs.python.org  Wed Aug 15 15:24:31 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Wed, 15 Aug 2012 13:24:31 +0000
Subject: [New-bugs-announce] [issue15666] PEP 3121,
	384 refactoring applied to lzma module
Message-ID: <1345037071.28.0.307240191092.issue15666@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the lzma module!

----------
components: Extension Modules
files: _lzma_pep3121-384_v0.patch
keywords: patch
messages: 168294
nosy: Robin.Schreiber, nadeem.vawda
priority: normal
severity: normal
status: open
title: PEP 3121, 384 refactoring applied to lzma module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26824/_lzma_pep3121-384_v0.patch

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

From report at bugs.python.org  Wed Aug 15 15:55:57 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Wed, 15 Aug 2012 13:55:57 +0000
Subject: [New-bugs-announce] [issue15667] PEP 3121,
	384 refactoring applied to pickle module
Message-ID: <1345038957.09.0.78094807427.issue15667@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the pickle module!

----------
components: Extension Modules
files: _pickle_pep3121-384_v0.patch
keywords: patch
messages: 168295
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 refactoring applied to pickle module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26825/_pickle_pep3121-384_v0.patch

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

From report at bugs.python.org  Wed Aug 15 16:10:36 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Wed, 15 Aug 2012 14:10:36 +0000
Subject: [New-bugs-announce] [issue15668] PEP 3121,
	384 Refactoring applied to random module
Message-ID: <1345039836.78.0.438193538839.issue15668@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the lsprof module!

----------
components: Extension Modules
files: _random_pep3121-384_v0.patch
keywords: patch
messages: 168297
nosy: Robin.Schreiber, rhettinger
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to random module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26828/_random_pep3121-384_v0.patch

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

From report at bugs.python.org  Wed Aug 15 16:18:53 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Wed, 15 Aug 2012 14:18:53 +0000
Subject: [New-bugs-announce] [issue15669] PEP 3121,
	384 Refactoring applied to sre module
Message-ID: <1345040333.3.0.897611485757.issue15669@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the sre module!

----------
components: Extension Modules
files: _sre_pep3121-384_v0.patch
keywords: patch
messages: 168298
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to sre module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26829/_sre_pep3121-384_v0.patch

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

From report at bugs.python.org  Wed Aug 15 16:30:29 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Wed, 15 Aug 2012 14:30:29 +0000
Subject: [New-bugs-announce] [issue15670] PEP 3121,
	384 Refactoring applied to ssl module
Message-ID: <1345041029.57.0.223670432026.issue15670@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the ssl module!

----------
components: Extension Modules
files: _ssl_pep3121-384_v0.patch
keywords: patch
messages: 168300
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to ssl module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26830/_ssl_pep3121-384_v0.patch

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

From report at bugs.python.org  Wed Aug 15 16:42:59 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Wed, 15 Aug 2012 14:42:59 +0000
Subject: [New-bugs-announce] [issue15671] PEP 3121,
	384 Refactoring applied to struct module
Message-ID: <1345041779.43.0.428829398339.issue15671@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the struct module!

----------
components: Extension Modules
files: _struct_pep3121-384_v0.patch
keywords: patch
messages: 168302
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to struct module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26832/_struct_pep3121-384_v0.patch

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

From report at bugs.python.org  Wed Aug 15 16:50:59 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Wed, 15 Aug 2012 14:50:59 +0000
Subject: [New-bugs-announce] [issue15672] PEP 3121,
	384 Refactoring applied to testbuffer module
Message-ID: <1345042259.48.0.277311619921.issue15672@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the testbuffer module!

----------
components: Extension Modules
files: _testbuffer_pep3121-384_v0.patch
keywords: patch
messages: 168304
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to testbuffer module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26833/_testbuffer_pep3121-384_v0.patch

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

From report at bugs.python.org  Wed Aug 15 16:58:29 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Wed, 15 Aug 2012 14:58:29 +0000
Subject: [New-bugs-announce] [issue15673] PEP 3121,
	384 Refactoring applied to testcapi module
Message-ID: <1345042709.67.0.745658134358.issue15673@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the testcapi module!

----------
components: Extension Modules
files: _testcapi_pep3121-384_v0.patch
keywords: patch
messages: 168305
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to testcapi module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26834/_testcapi_pep3121-384_v0.patch

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

From report at bugs.python.org  Wed Aug 15 17:06:23 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Wed, 15 Aug 2012 15:06:23 +0000
Subject: [New-bugs-announce] [issue15674] PEP 3121,
	384 Refactoring applied to thread module
Message-ID: <1345043183.1.0.612175209954.issue15674@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the thread module!

----------
components: Extension Modules
files: _thread_pep3121-384_v0.patch
keywords: patch
messages: 168306
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to thread module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26835/_thread_pep3121-384_v0.patch

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

From report at bugs.python.org  Wed Aug 15 17:13:46 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Wed, 15 Aug 2012 15:13:46 +0000
Subject: [New-bugs-announce] [issue15675] PEP 3121,
	384 Refactoring applied to array module
Message-ID: <1345043626.95.0.208765115861.issue15675@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the array module!

----------
components: Extension Modules
files: array_pep3121-385_v0.patch
keywords: patch
messages: 168307
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to array module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26836/array_pep3121-385_v0.patch

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

From report at bugs.python.org  Wed Aug 15 19:46:34 2012
From: report at bugs.python.org (Steven Willis)
Date: Wed, 15 Aug 2012 17:46:34 +0000
Subject: [New-bugs-announce] [issue15676] mmap: add empty file check prior
	to offset check
Message-ID: <1345052794.26.0.230448790651.issue15676@psf.upfronthosting.co.za>


New submission from Steven Willis:

There are a number of issues dealing with the offset and length checks in offset, such as issue12556.

I'm running into this issue as well, but with a normal file that happens to be empty. I'm trying to access it with:

mmap.mmap(f.fileno(), length=0, access=mmap.ACCESS_READ)

So the length and offset should be calculated automatically. The man page for mmap says:

"SUSv3 specifies that mmap() should fail if length is 0.  However, in kernels before 2.6.12, mmap() succeeded in this case: no mapping was created and the call returned  addr.   Since  kernel  2.6.12, mmap() fails with the error EINVAL for this case."

So alright, mmapping an empty file is now allowed. But, could the check for an empty file be done prior to the check for the offset exceeding the size of the file? It would be much clearer in the cases where an empty (regular or otherwise) file was mmapped if the error message were something like "empty files cannot be mapped" insted of "offset is greater than file size" since I didn't even set the offset.

----------
components: Library (Lib)
messages: 168314
nosy: Steven.Willis
priority: normal
severity: normal
status: open
title: mmap: add empty file check prior to offset check
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Aug 15 22:35:23 2012
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 15 Aug 2012 20:35:23 +0000
Subject: [New-bugs-announce] [issue15677] Gzip/zlib allows for compression
	level=0
Message-ID: <1345062923.32.0.954619584637.issue15677@psf.upfronthosting.co.za>


New submission from Sandro Tosi:

As reported at http://mail.python.org/pipermail/docs/2012-August/009837.html gzip/zlib allows for a compression level=0 (that's basically no compression) so the documentation should mention that possibility too.

----------
assignee: docs at python
components: Documentation
messages: 168332
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: Gzip/zlib allows for compression level=0
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Aug 16 03:08:12 2012
From: report at bugs.python.org (Ned Deily)
Date: Thu, 16 Aug 2012 01:08:12 +0000
Subject: [New-bugs-announce] [issue15678] IDLE menu customization is broken
	from OS X command lines
Message-ID: <1345079292.52.0.381785713034.issue15678@psf.upfronthosting.co.za>


New submission from Ned Deily:

With 3.3.0b2, when IDLE is started from a command line using
an OS X framework build (such as provided by the python.org
installers), the Aqua Tk menu customization is no longer being
performed, for example, no Preferences menu item, an extra Options
menu, etc.  It was broken as a side effect of the changes to
pythonw.c in b79d276041a8 for #15307.  Since sys.executable no
longer includes 'Python.app' in the path name, the attached patch
tests for a framework build instead.  This should give the previous
behavior in nearly all cases.  Whether the previous behavior is
sensible is left as an issue for later releases.  IDLE.app behavior was
not affected as it does its own manipulation of sys.executable;
that should probably also be changed in the future.

----------
assignee: ned.deily
components: IDLE, Macintosh
files: XXXXX_bin_idle_menus.patch
keywords: patch
messages: 168346
nosy: ned.deily, ronaldoussoren
priority: release blocker
severity: normal
stage: commit review
status: open
title: IDLE menu customization is broken from OS X command lines
versions: Python 3.3
Added file: http://bugs.python.org/file26841/XXXXX_bin_idle_menus.patch

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

From report at bugs.python.org  Thu Aug 16 09:59:42 2012
From: report at bugs.python.org (Julien Palard)
Date: Thu, 16 Aug 2012 07:59:42 +0000
Subject: [New-bugs-announce] [issue15679] HTMLParser can fail on unquoted
	attributes.
Message-ID: <1345103982.29.0.499632264668.issue15679@psf.upfronthosting.co.za>


New submission from Julien Palard:

This is accepted by browsers but raises an exception in HTMLParser :

from HTMLParser import HTMLParser
HTMLParser().feed("<a onclick=foo({bar:42}); class=baz>")

----------
components: Library (Lib)
messages: 168352
nosy: JulienPalard
priority: normal
severity: normal
status: open
title: HTMLParser can fail on unquoted attributes.
type: enhancement
versions: Python 2.6

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

From report at bugs.python.org  Thu Aug 16 10:21:55 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 08:21:55 +0000
Subject: [New-bugs-announce] [issue15680] PEP 3121 refactoring applied to
	audioop module
Message-ID: <1345105315.06.0.844994480517.issue15680@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 have now been applied to the audioop module!

----------
components: Extension Modules
files: audioop_pep3121_v0.patch
keywords: patch
messages: 168353
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121 refactoring applied to audioop module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26842/audioop_pep3121_v0.patch

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

From report at bugs.python.org  Thu Aug 16 10:26:52 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 08:26:52 +0000
Subject: [New-bugs-announce] [issue15681] PEP 3121 refactoring applied to
	binascii module
Message-ID: <1345105612.5.0.663032219905.issue15681@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 have now been applied to the binascii module!

----------
components: Extension Modules
files: binascii_pep3121_v0.patch
keywords: patch
messages: 168354
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121 refactoring applied to binascii module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26843/binascii_pep3121_v0.patch

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

From report at bugs.python.org  Thu Aug 16 10:33:46 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 08:33:46 +0000
Subject: [New-bugs-announce] [issue15682] PEP 3121 refactoring applied to
	fpectl module
Message-ID: <1345106026.62.0.405677878091.issue15682@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 have now been applied to the fpectl module!

----------
components: Extension Modules
files: fpectl_pep3121_v0.patch
keywords: patch
messages: 168355
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121 refactoring applied to fpectl module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26844/fpectl_pep3121_v0.patch

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

From report at bugs.python.org  Thu Aug 16 10:34:40 2012
From: report at bugs.python.org (Arvin Moezzi)
Date: Thu, 16 Aug 2012 08:34:40 +0000
Subject: [New-bugs-announce] [issue15683] add decorator for make functions
	partial applicable
Message-ID: <1345106080.5.0.940498216891.issue15683@psf.upfronthosting.co.za>


New submission from Arvin Moezzi:

I am not sure if this is the right way to do it but IMHO it would be great to
have a function decorator/transformer to make functions partial applicable
using functools.partial. Like


from functools import partial

class partial_applicable():
	def __call__(self, func):
		def __wrapper(*args, **kvargs):
			try:
				return func(*args, **kvargs)
			except TypeError:
				return partial(func, *args, **kvargs)

		return __wrapper

Then you could do like:

@partial_applicable()
def substract(left, right):
	return left - right

substract(10, 100) 
 => -90

rclose = substract(right = 1000)
 => rclose(10) => -990

lclose = substract(1)
 => lclose(10) => -9

What do you think?

----------
components: Library (Lib)
messages: 168356
nosy: Arvin.Moezzi
priority: normal
severity: normal
status: open
title: add decorator for make functions partial applicable
type: enhancement
versions: Python 2.6

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

From report at bugs.python.org  Thu Aug 16 10:39:13 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 08:39:13 +0000
Subject: [New-bugs-announce] [issue15684] PEP 3121 refactoring applied to
	fpetest module
Message-ID: <1345106353.01.0.354070403229.issue15684@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the fpetest module!

----------
components: Extension Modules
files: fpetest_pep3121_v0.patch
keywords: patch
messages: 168357
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121 refactoring applied to fpetest module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26845/fpetest_pep3121_v0.patch

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

From report at bugs.python.org  Thu Aug 16 10:52:10 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 08:52:10 +0000
Subject: [New-bugs-announce] [issue15685] PEP 3121,
	384 Refactoring applied to itertools module
Message-ID: <1345107130.15.0.109791509014.issue15685@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the itertools module!

----------
components: Extension Modules
files: itertools_pep3121-384_v0.patch
keywords: patch
messages: 168359
nosy: Robin.Schreiber, rhettinger
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to itertools module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26846/itertools_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 10:56:34 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 08:56:34 +0000
Subject: [New-bugs-announce] [issue15686] PEP 3121,
	384 Refactoring applied to md5 module
Message-ID: <1345107394.8.0.322253629344.issue15686@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the md5 module!

----------
components: Extension Modules
files: md5_pep3121-384_v0.patch
keywords: patch
messages: 168360
nosy: Robin.Schreiber, gregory.p.smith
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to md5 module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26847/md5_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 11:04:14 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 09:04:14 +0000
Subject: [New-bugs-announce] [issue15687] PEP 3121,
	384 Refactoring applied to mmap module
Message-ID: <1345107854.44.0.304444585248.issue15687@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the mmap module!

----------
components: Extension Modules
files: mmap_pep3121-384_v0.patch
keywords: patch
messages: 168361
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to mmap module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26848/mmap_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 11:07:10 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 09:07:10 +0000
Subject: [New-bugs-announce] [issue15688] PEP 3121 Refactoring applied to
	nis module
Message-ID: <1345108030.82.0.709168426802.issue15688@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the nis module!

----------
components: Extension Modules
files: nis_pep3121_v0.patch
keywords: patch
messages: 168362
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121 Refactoring applied to nis module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26849/nis_pep3121_v0.patch

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

From report at bugs.python.org  Thu Aug 16 11:11:10 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 09:11:10 +0000
Subject: [New-bugs-announce] [issue15689] PEP 3121,
	384 Refactoring applied to operator module
Message-ID: <1345108270.08.0.792336890272.issue15689@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the operator module!

----------
components: Extension Modules
files: operator_pep3121-384_v0.patch
keywords: patch
messages: 168363
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to operator module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26850/operator_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 11:22:47 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 09:22:47 +0000
Subject: [New-bugs-announce] [issue15690] PEP 3121,
	384 Refactoring applied to parser module
Message-ID: <1345108967.12.0.878524641332.issue15690@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the parser module!

----------
components: Extension Modules
files: parser_pep3121-384_v0.patch
keywords: patch
messages: 168364
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to parser module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26851/parser_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 11:48:05 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 09:48:05 +0000
Subject: [New-bugs-announce] [issue15691] PEP 3121,
	384 Refactoring applied to posix module
Message-ID: <1345110485.53.0.856598198463.issue15691@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the posix module!

----------
components: Extension Modules
files: posix_pep3121-384_v0.patch
keywords: patch
messages: 168367
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to posix module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26852/posix_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 17:30:12 2012
From: report at bugs.python.org (=?utf-8?q?Bj=C3=B6rn_Dahlgren?=)
Date: Thu, 16 Aug 2012 15:30:12 +0000
Subject: [New-bugs-announce] [issue15692] Unexpected exponentiation in
	lambda function
Message-ID: <1345131012.45.0.334354772161.issue15692@psf.upfronthosting.co.za>


New submission from Bj?rn Dahlgren:

Hi, I hope this is not a false positive but I cannot help thinking this is a bug, consider:

Python 2.7.3 (default, Aug  1 2012, 05:14:39) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> -3.2**0
-1.0
>>> sign=lambda x: x**0
>>> sign(-3.2)
1.0

Python 3.2.3 (default, May  3 2012, 15:51:42) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> -3.2**0
-1.0
>>> sign=lambda x: x**0
>>> sign(-3.2)
1.0


Or is this expected?

Best regards,
Bj?rn Dahlgren

----------
components: None
messages: 168384
nosy: bjodah
priority: normal
severity: normal
status: open
title: Unexpected exponentiation in lambda function
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Thu Aug 16 17:48:28 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 16 Aug 2012 15:48:28 +0000
Subject: [New-bugs-announce] [issue15693] expose glossary link on hover
Message-ID: <1345132108.78.0.567099034623.issue15693@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

It would be nice if hovering over the right side of the header to a glossary entry would expose a link in the same way that it does for function definitions, etc.

http://docs.python.org/dev/glossary.html#glossary

Otherwise, there doesn't seem to be a convenient way to get a direct link to a glossary entry.

I'm not sure if this issue should also be filed with Sphinx.

----------
assignee: docs at python
components: Documentation
messages: 168388
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: expose glossary link on hover
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Aug 16 18:06:31 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 16 Aug 2012 16:06:31 +0000
Subject: [New-bugs-announce] [issue15694] link to "file object" glossary
	entry in open() and io	docs
Message-ID: <1345133191.76.0.682782918752.issue15694@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

It would be nice if the first sentence of the documentation for the open() built-in function:

"Open file and return a corresponding stream. If the file cannot be opened, an OSError is raised."

http://docs.python.org/dev/library/functions.html#open

linked to the glossary entry for "file object":

http://docs.python.org/dev/glossary.html#term-file-object

Incidentally, this would be similar to what was done 2.7 documentation of open():

http://docs.python.org/library/functions.html#open

Similarly, the introductory overview section of the io module should also link to the glossary entry for "file object":

"Concrete objects belonging to any of these categories will often be called streams; another common term is file-like objects."

(from http://docs.python.org/dev/library/io.html#overview )

----------
assignee: docs at python
components: Documentation
messages: 168392
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: link to "file object" glossary entry in open() and io docs
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Aug 16 21:13:36 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 Aug 2012 19:13:36 +0000
Subject: [New-bugs-announce] [issue15695] Correct __sizeof__ support for
	StgDict
Message-ID: <1345144416.71.0.984691068113.issue15695@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch that implements correct __sizeof__ for StgDict (a dictionary subclass used in ctypes).

There are no tests because I don't know how to create and use StgDict. So I'm not sure that the code works correctly. Please help me with tests.

----------
components: Library (Lib)
files: stgdict_sizeof-3.3.patch
keywords: patch
messages: 168399
nosy: amaury.forgeotdarc, belopolsky, meador.inge, storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Correct __sizeof__ support for StgDict
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26854/stgdict_sizeof-3.3.patch

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

From report at bugs.python.org  Thu Aug 16 21:31:39 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 Aug 2012 19:31:39 +0000
Subject: [New-bugs-announce] [issue15696] Correct __sizeof__ support for mmap
Message-ID: <1345145499.47.0.489635799937.issue15696@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch that implements correct __sizeof__ for mmap under Windows.

I have not tested it because it is Windows-only issue. Please test it.

----------
components: Library (Lib), Windows
files: mmap_sizeof-3.x.patch
keywords: patch
messages: 168402
nosy: storchaka
priority: normal
severity: normal
status: open
title: Correct __sizeof__ support for mmap
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26858/mmap_sizeof-3.x.patch

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

From report at bugs.python.org  Thu Aug 16 21:47:52 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 19:47:52 +0000
Subject: [New-bugs-announce] [issue15697] PEP 3121 refactoring applied to
	pwd module
Message-ID: <1345146472.99.0.450289405214.issue15697@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 have now been applied to the pwd module!

----------
components: Extension Modules
files: pwd_pep3121_v0.patch
keywords: patch
messages: 168403
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121 refactoring applied to pwd module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26860/pwd_pep3121_v0.patch

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

From report at bugs.python.org  Thu Aug 16 21:55:01 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 19:55:01 +0000
Subject: [New-bugs-announce] [issue15698] PEP 3121,
	384 Refactoring applied to pyexpat module
Message-ID: <1345146901.0.0.136939773234.issue15698@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the pyexpat module!

----------
components: Extension Modules
files: pyexpat_pep3121-384_v0.patch
keywords: patch
messages: 168404
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to pyexpat module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26861/pyexpat_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 22:03:01 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 20:03:01 +0000
Subject: [New-bugs-announce] [issue15699] PEP 3121,
	384 Refactoring applied to readline module
Message-ID: <1345147381.91.0.560597639191.issue15699@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the readline module!

----------
components: Extension Modules
files: readline_pep3121-384_v0.patch
keywords: patch
messages: 168405
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to readline module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26862/readline_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 22:07:55 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 20:07:55 +0000
Subject: [New-bugs-announce] [issue15700] PEP 3121,
	384 Refactoring applied to resource module
Message-ID: <1345147675.99.0.556449209112.issue15700@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the resource module!

----------
components: Extension Modules
files: resource_pep3121-384_v0.patch
keywords: patch
messages: 168406
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to resource module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26863/resource_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 22:35:57 2012
From: report at bugs.python.org (Jody McIntyre)
Date: Thu, 16 Aug 2012 20:35:57 +0000
Subject: [New-bugs-announce] [issue15701] AttributeError from HTTPError when
	using digest auth
Message-ID: <1345149357.77.0.903430006119.issue15701@psf.upfronthosting.co.za>


New submission from Jody McIntyre:

I attempted to connect to a site using urllib2 and digest authentication and it raised an HTTPError (due to an incorrect username and password, which is expected).  I attempted to run the info() method of the HTTPError to get more information, but it failed with an AttributeError (this is the bug).

$ ./reproducer.py 
Traceback (most recent call last):
  File "./reproducer.py", line 16, in <module>
    print e.info()
  File "/usr/lib/python2.6/urllib.py", line 987, in info
    return self.headers
AttributeError: 'HTTPError' object has no attribute 'headers'

$ python --version
Python 2.6.6

----------
files: reproducer.py
messages: 168407
nosy: scjody
priority: normal
severity: normal
status: open
title: AttributeError from HTTPError when using digest auth
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file26864/reproducer.py

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

From report at bugs.python.org  Thu Aug 16 22:41:48 2012
From: report at bugs.python.org (James Hutchison)
Date: Thu, 16 Aug 2012 20:41:48 +0000
Subject: [New-bugs-announce] [issue15702] Multiprocessing Pool deadlocks on
	join after empty map	operation
Message-ID: <1345149708.12.0.561360753996.issue15702@psf.upfronthosting.co.za>


New submission from James Hutchison:

Following code deadlocks on Windows 7 64-bit, Python 3.2.3

If you have a pool issue a map operation over an empty iterable then try to join later, it will deadlock. If there is no map operation or blah in the code below isn't empty, it does not deadlock

from multiprocessing import Pool

def main():
    p = Pool();
    blah = [];
    print("Mapping");
    p.map(dummy, blah);
    p.close();
    p.join(); # deadlocks here
    print("Done");

def dummy(x):
    pass;

if __name__ == "__main__":
    main();

----------
components: Library (Lib)
messages: 168408
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: Multiprocessing Pool deadlocks on join after empty map operation
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Aug 16 23:01:09 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 21:01:09 +0000
Subject: [New-bugs-announce] [issue15703] PEP 3121,
	384 Refactoring applied to select module
Message-ID: <1345150869.96.0.605458116599.issue15703@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the select module!

----------
components: Extension Modules
files: select_pep3121-384_v0.patch
keywords: patch
messages: 168410
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to select module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26865/select_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 23:03:54 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 21:03:54 +0000
Subject: [New-bugs-announce] [issue15704] PEP 3121,
	384 Refactoring applied to sha1 module
Message-ID: <1345151034.85.0.141930979711.issue15704@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the sha1 module!

----------
components: Extension Modules
files: sha1_pep3121-384_v0.patch
keywords: patch
messages: 168411
nosy: Robin.Schreiber, gregory.p.smith
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to sha1 module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26866/sha1_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 23:08:59 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 21:08:59 +0000
Subject: [New-bugs-announce] [issue15705] PEP 3121,
	384 Refactoring applied to sha256 module
Message-ID: <1345151339.81.0.44810343177.issue15705@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the sha256 module!

----------
components: Extension Modules
files: sha256_pep3121-384_v0.patch
keywords: patch
messages: 168412
nosy: Robin.Schreiber, gregory.p.smith
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to sha256 module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26867/sha256_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 23:12:53 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 21:12:53 +0000
Subject: [New-bugs-announce] [issue15706] PEP 3121,
	384 Refactoring applied to sha512 module
Message-ID: <1345151573.12.0.0841074756342.issue15706@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the sha512 module!

----------
components: Extension Modules
files: sha512_pep3121-384_v0.patch
keywords: patch
messages: 168413
nosy: Robin.Schreiber, gregory.p.smith
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to sha512 module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26868/sha512_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 23:19:27 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 21:19:27 +0000
Subject: [New-bugs-announce] [issue15707] PEP 3121,
	384 Refactoring applied to signal module
Message-ID: <1345151967.47.0.247832517362.issue15707@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the signal module!

----------
components: Extension Modules
files: signal_pep3121-384_v0.patch
keywords: patch
messages: 168415
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to signal module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26869/signal_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 23:26:28 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 21:26:28 +0000
Subject: [New-bugs-announce] [issue15708] PEP 3121,
	384 Refactoring applied to socket module
Message-ID: <1345152388.23.0.37223742756.issue15708@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the socket module!

----------
components: Extension Modules
files: socket_pep3121-384_v0.patch
keywords: patch
messages: 168416
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to socket module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26870/socket_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 23:32:49 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 21:32:49 +0000
Subject: [New-bugs-announce] [issue15709] PEP 3121,
	384 Refactoring applied to termios module
Message-ID: <1345152769.02.0.418210098076.issue15709@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the termios module!

----------
components: Extension Modules
files: termios_pep3121-384_v0.patch
keywords: patch
messages: 168417
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to termios module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26871/termios_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 23:33:59 2012
From: report at bugs.python.org (Tobin Baker)
Date: Thu, 16 Aug 2012 21:33:59 +0000
Subject: [New-bugs-announce] [issue15710] logging module crashes in Python
	2.7.3 for	handler.setLevel(long)
Message-ID: <1345152839.48.0.661799461902.issue15710@psf.upfronthosting.co.za>


New submission from Tobin Baker:

I'm using a 3rd-party library (ESAPI) which defines a log level as the literal -2**31. This worked fine until I upgraded to Python 2.7.3, which, unlike all previous versions of Python, coerces that literal to long rather than int. The following code in the logging module then throws a TypeError:

def _checkLevel(level):
    if isinstance(level, int):
        rv = level
    elif str(level) == level:
        if level not in _levelNames:
            raise ValueError("Unknown level: %r" % level)
        rv = _levelNames[level]
    else:
        raise TypeError("Level not an integer or a valid string: %r" % level)
    return rv

Although this is certainly an unusual use case, it seems that as just a matter of principle, the module should be using the check isinstance(level, (int, long)) rather than just isinstance(level, int).

Here's the relevant part of the traceback:

  File "/usr/lib/python2.7/logging/__init__.py", line 710, in setLevel
    self.level = _checkLevel(level)
  File "/usr/lib/python2.7/logging/__init__.py", line 190, in _checkLevel
    raise TypeError("Level not an integer or a valid string: %r" % level)
TypeError: Level not an integer or a valid string: -2147483648L

----------
components: Library (Lib)
messages: 168418
nosy: tobin.baker
priority: normal
severity: normal
status: open
title: logging module crashes in Python 2.7.3 for handler.setLevel(long)
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug 16 23:36:08 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 21:36:08 +0000
Subject: [New-bugs-announce] [issue15711] PEP 3121,
	384 Refactoring applied to time module
Message-ID: <1345152968.9.0.714502729899.issue15711@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the time module!

----------
components: Extension Modules
files: time_pep3121-384_v0.patch
keywords: patch
messages: 168419
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to time module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26872/time_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 23:46:20 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 21:46:20 +0000
Subject: [New-bugs-announce] [issue15712] PEP 3121,
	384 Refactoring applied to unicodedata module
Message-ID: <1345153580.3.0.0817770117233.issue15712@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the unicodedata module!

----------
components: Extension Modules
files: unicodedate_pep3121-384_v0.patch
keywords: patch
messages: 168420
nosy: Robin.Schreiber, effbot, lemburg, loewis
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to unicodedata module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26873/unicodedate_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 23:53:55 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 21:53:55 +0000
Subject: [New-bugs-announce] [issue15713] PEP 3121,
	384 Refactoring applied to zipimport module
Message-ID: <1345154035.4.0.564693100383.issue15713@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the zipimport module!

----------
components: Extension Modules
files: zipimport_pep3121-384_v0.patch
keywords: patch
messages: 168421
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to zipimport module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26874/zipimport_pep3121-384_v0.patch

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

From report at bugs.python.org  Thu Aug 16 23:55:58 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Thu, 16 Aug 2012 21:55:58 +0000
Subject: [New-bugs-announce] [issue15714] PEP 3121,
	384 Refactoring applied to grp module
Message-ID: <1345154158.03.0.0313015513164.issue15714@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the grp module!

----------
components: Extension Modules
files: grp_pep3121-384_v0.patch
keywords: patch
messages: 168422
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to grp module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26875/grp_pep3121-384_v0.patch

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

From report at bugs.python.org  Fri Aug 17 00:42:08 2012
From: report at bugs.python.org (Simon Feltman)
Date: Thu, 16 Aug 2012 22:42:08 +0000
Subject: [New-bugs-announce] [issue15715] __import__ now raises with
	non-existing items in	fromlist in 3.3
Message-ID: <1345156928.79.0.203974969225.issue15715@psf.upfronthosting.co.za>


New submission from Simon Feltman:

This came up while trying to build pygobject with Python 3.3. The problem is there are some erroneous imports in the fromlist with these bindings that can easily be fixed. But it is a behavioral change so I just wanted to raise awareness if it is not already known.

$ python3.2 -c "__import__('http', fromlist=['blah'])"
(works)

$ python3.3 -c "__import__('http', fromlist=['blah'])"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named 'http.blah'


Note this is also the case when using the C API: PyImport_ImportModuleEx

----------
components: None
messages: 168423
nosy: sfeltman
priority: normal
severity: normal
status: open
title: __import__ now raises with non-existing items in fromlist in 3.3
versions: Python 3.3

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

From report at bugs.python.org  Fri Aug 17 02:40:27 2012
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 17 Aug 2012 00:40:27 +0000
Subject: [New-bugs-announce] [issue15716] Ability to specify the PYTHONPATH
	via a command line flag
Message-ID: <1345164027.44.0.397805734201.issue15716@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

I'd like a command line flag to override PYTHONPATH.  It could also be used in combination with -E so that you could still set the PYTHONPATH while ignoring everything else from the environment.

----------
messages: 168429
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: Ability to specify the PYTHONPATH via a command line flag

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

From report at bugs.python.org  Fri Aug 17 13:17:59 2012
From: report at bugs.python.org (Rostyslav Dzinko)
Date: Fri, 17 Aug 2012 11:17:59 +0000
Subject: [New-bugs-announce] [issue15718] Possible OverflowError in __len__
	method undocumented	(when called via len() function)
Message-ID: <1345202279.02.0.767068523185.issue15718@psf.upfronthosting.co.za>


New submission from Rostyslav Dzinko:

I've encountered that OverflowError which can happen in __len__ method is still undocumented, though one issue on this problem: http://bugs.python.org/issue12159 ended up with "need to be documented" comment.

Link to documentation: http://docs.python.org/reference/datamodel.html#object.__len__

I think it must be clarified that __len__ return value is constrained to upper boundary (Py_ssize_t c type) when you plan to call it via len() built-in function.

----------
assignee: docs at python
components: Documentation
messages: 168439
nosy: Rostyslav.Dzinko, docs at python
priority: normal
severity: normal
status: open
title: Possible OverflowError in __len__ method undocumented (when called via len() function)
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug 17 22:44:53 2012
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 17 Aug 2012 20:44:53 +0000
Subject: [New-bugs-announce] [issue15719] Sort dict items in urlencode()
Message-ID: <1345236293.12.0.120802358061.issue15719@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

>From http://mail.python.org/pipermail/python-dev/2012-August/121364.html :

"""
I just fixed a unittest for some code used at Google that was
comparing a url generated by urllib.encode() to a fixed string. The
problem was caused by turning on PYTHONHASHSEED=1. Because of this,
the code under test would generate a textually different URL each time
the test was run, but the intention of the test was just to check that
all the query parameters were present and equal to the expected
values.

The solution was somewhat painful, I had to parse the url, split the
query parameters, and compare them to a known dict.

I wonder if it wouldn't make sense to change urlencode() to generate
URLs that don't depend on the hash order, for all versions of Python
that support PYTHONHASHSEED? It seems a one-line fix:

        query = query.items()

with this:

        query = sorted(query.items())

This would not prevent breakage of unit tests, but it would make a
much simpler fix possible: simply sort the parameters in the URL.
"""

MvL's response (http://mail.python.org/pipermail/python-dev/2012-August/121366.html) seems to suggest that this can go in as a bugfix in 3.2 and later if augmented with a check for type(query) is dict and a check for whether dict hashing is enabled.

Does anyone want to turn this idea into a patch?

----------
keywords: easy
messages: 168477
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Sort dict items in urlencode()
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Aug 18 05:38:09 2012
From: report at bugs.python.org (Eric Snow)
Date: Sat, 18 Aug 2012 03:38:09 +0000
Subject: [New-bugs-announce] [issue15720] move __import__() out of the
	default lookup chain
Message-ID: <1345261089.07.0.0712105087978.issue15720@psf.upfronthosting.co.za>


New submission from Eric Snow:

When people want to import modules with "runtime" names, they regrettably turn to __import__(), have done so for many years, and likely will for a while.

If it were less convenient to use __import__(), fewer people would use it.  I'm putting together a patch that removes it from <module>.__builtins__, so that it will not be found during normal name lookup.  However, it will still available for the adventurous spirit via the imp module, following the precedent of reload().

This proposal came up in issue15715.

----------
components: Interpreter Core
messages: 168493
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: move __import__() out of the default lookup chain
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Aug 18 12:53:44 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Sat, 18 Aug 2012 10:53:44 +0000
Subject: [New-bugs-announce] [issue15721] PEP 3121,
	384 Refactoring applied to tkinter module
Message-ID: <1345287224.98.0.204885883161.issue15721@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the tkinter module!
When running the test form inside Python.exe (tkinter._test()), the litte "test-window" is rendered correctly. However there are still some error messages popping up inside the python shell 
(I am running this on OS X 10.8):

>>> tkinter._test()
2012-08-18 12:46:24.775 python.exe[17410:707] speedup (null)
2012-08-18 12:46:24.776 python.exe[17410:707] ERROR: Unable to find method [_NSFullScreenTransition _startFullScreenTransitionForCGWindow:targetFrame:duration:].
2012-08-18 12:46:24.776 python.exe[17410:707] ERROR: Unable to find method [_NSFullScreenTransition _startEnterFullScreenTransitionForCGWindow:targetFrame:duration:].
2012-08-18 12:46:24.778 python.exe[17410:707] ERROR: Unable to find method [_NSFullScreenTransition startExitFullScreenTransitionForCGWindow:targetFrame:duration:].
[87221 refs]
>>> 

I have no Idea how and where these are triggered.

----------
components: Extension Modules
files: _tkinter_pep3121-384_v0.patch
keywords: patch
messages: 168504
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to tkinter module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26887/_tkinter_pep3121-384_v0.patch

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

From report at bugs.python.org  Sat Aug 18 14:31:10 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Sat, 18 Aug 2012 12:31:10 +0000
Subject: [New-bugs-announce] [issue15722] PEP 3121,
	384 Refactoring applied to decimal module
Message-ID: <1345293070.72.0.383930872934.issue15722@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the decimal module!

----------
components: Regular Expressions
files: _decimal_pep3121-384_v0.patch
keywords: patch
messages: 168511
nosy: Robin.Schreiber, ezio.melotti, mrabarnett, skrah
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to decimal module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26888/_decimal_pep3121-384_v0.patch

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

From report at bugs.python.org  Sat Aug 18 22:19:37 2012
From: report at bugs.python.org (Poul-Henning Kamp)
Date: Sat, 18 Aug 2012 20:19:37 +0000
Subject: [New-bugs-announce] [issue15723] Python breaks OS' append guarantee
	on file writes
Message-ID: <1345321177.26.0.0602208919047.issue15723@psf.upfronthosting.co.za>


New submission from Poul-Henning Kamp:

When a file is opened in append mode, the operating system guarantees that all write(2) system calls atomically appended their payload to the file.

At least on FreeBSD, Python breaks this guarantee, by chopping up large writes into multiple write(2) syscalls to the OS.

Try running this program using ktrace/truss/strace or a similar system-call tracing facility:

   fo = open("/tmp/_bogus", "ab", 0)
   fo.write(bytearray(1024*1024))
   fo.close()

Instead of one single megabyte write, I see 1024 kilobyte writes.

(BTW: Why only one kilobyte ? That is an incredible pessimisation these days...)

I leave it to the python community to decide if this should be fixed, or merely pointed out in documentation (os.write() is a workaround)

----------
components: None
messages: 168528
nosy: bsdphk
priority: normal
severity: normal
status: open
title: Python breaks OS' append guarantee on file writes
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Aug 19 13:53:43 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 19 Aug 2012 11:53:43 +0000
Subject: [New-bugs-announce] [issue15724] Add "versionchanged" to memoryview
	docs
Message-ID: <1345377223.09.0.176185074566.issue15724@psf.upfronthosting.co.za>


New submission from Stefan Krah:

There are a couple of places in the memoryview docs that still
need a "versionchanged" tag.

Other places might need explanations what exactly has changed.

----------
assignee: docs at python
components: Documentation
messages: 168563
nosy: docs at python, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Add "versionchanged" to memoryview docs
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sun Aug 19 15:12:47 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Sun, 19 Aug 2012 13:12:47 +0000
Subject: [New-bugs-announce] [issue15725] PyType_FromSpecWithBases bugfix
Message-ID: <1345381967.41.0.932282182002.issue15725@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

This small patch prevents PyType_FromSpecWithBases, from setting the base(s) attribute of the HeapType to NULL-values.

----------
components: Interpreter Core
files: PyType_FromSpecWithBases_bases_fix.patch
keywords: patch
messages: 168570
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PyType_FromSpecWithBases bugfix
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file26895/PyType_FromSpecWithBases_bases_fix.patch

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

From report at bugs.python.org  Sun Aug 19 15:17:12 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Sun, 19 Aug 2012 13:17:12 +0000
Subject: [New-bugs-announce] [issue15726] PyState_FindModule false
	length-comparison fix
Message-ID: <1345382232.77.0.93004938409.issue15726@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Fixed wrong list-length comparison in PyState_FindModule.

----------
components: Interpreter Core
files: PyState_FindModule_LE_fix.patch
keywords: patch
messages: 168572
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PyState_FindModule false length-comparison fix
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file26896/PyState_FindModule_LE_fix.patch

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

From report at bugs.python.org  Sun Aug 19 17:57:46 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Sun, 19 Aug 2012 15:57:46 +0000
Subject: [New-bugs-announce] [issue15727] PyType_FromSpecWithBases tp_new
	bugfix
Message-ID: <1345391866.4.0.54341725267.issue15727@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

As with every type, that has been created and initialized, HeapTypes created form PyType_FromSpecWithBases() have to pass through PyType_Ready(). Here the function inherit_special might be called, which, among other things, does the following:
....
3892         if (base != &PyBaseObject_Type ||                                                                                                                
3893             (type->tp_flags & Py_TPFLAGS_HEAPTYPE)) {
3894             if (type->tp_new == NULL)
3895                 type->tp_new = base->tp_new;
3896         }
....
The code does not know of Heaptypes that have been created from extension-types by the PEP 384 refactorings. This includes extension-types that do not specify a tp_new method but instead have seperate factory methods, that are only used within the extension module. inherit_special() might consequently assign inappropriate new-methods to these type objects.

To circumvent this issue, I propose to enhance PyType_FromSpecWithBases in the following way: If no tp_new has been specified, we assign the newly defined PySpec_New() method to tp_new which simply denies the user to create an instance of this type. This also prohibits inherit_special to falsely inherit inappropriate new-methods.

----------
components: Interpreter Core
files: PyType_FromSpecWithBases_tp_new_fix.patch
keywords: patch
messages: 168579
nosy: Robin.Schreiber, loewis
priority: normal
severity: normal
status: open
title: PyType_FromSpecWithBases tp_new bugfix
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file26897/PyType_FromSpecWithBases_tp_new_fix.patch

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

From report at bugs.python.org  Sun Aug 19 19:50:05 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 19 Aug 2012 17:50:05 +0000
Subject: [New-bugs-announce] [issue15728] Leak in
	PyUnicode_AsWideCharString()
Message-ID: <1345398605.54.0.540570089061.issue15728@psf.upfronthosting.co.za>


New submission from Stefan Krah:

Coverity found a leak in PyUnicode_AsWideCharString(). Patch attached.

----------
components: Interpreter Core
files: aswidechar-leak.diff
keywords: patch
messages: 168584
nosy: haypo, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Leak in PyUnicode_AsWideCharString()
type: resource usage
versions: Python 3.3
Added file: http://bugs.python.org/file26898/aswidechar-leak.diff

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

From report at bugs.python.org  Sun Aug 19 22:16:18 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Sun, 19 Aug 2012 20:16:18 +0000
Subject: [New-bugs-announce] [issue15729] PyStructSequence_NewType
	enhancement
Message-ID: <1345407378.13.0.964225258094.issue15729@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

To create a HeapType from Structseq description, there is the helpful, yet undocumented PyStructSequence_NewType Method, which can do just that.
Until now, this method solely allocates some generic TypeObject on which it then performs PyStructSequence_InitType().

I have found that this is far from enough, as for one the flags of the type are not set appropriately and neither ht_name nor ht_qualname are set (which is as far as I know required of a proper Heaptype).
I have now added this missing initialization of the fields to PyStructSequence_NewType(). 

I have also changed the previous definition of PyStructSequence_InitType, by extracting a new Method _PyStructSequence_InitTypeWithFlags. This initializes the given type with the flags variable passed to the function.
This method extraction is needed, as we can not alter the semantics of InitType itself, yet need some way to initialize a SequenceType with Heaptype-flags, without having too much duplicate code.

----------
components: Interpreter Core
files: structseq_newtype_fix.patch
keywords: patch
messages: 168595
nosy: Robin.Schreiber, loewis
priority: normal
severity: normal
status: open
title: PyStructSequence_NewType enhancement
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26901/structseq_newtype_fix.patch

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

From report at bugs.python.org  Mon Aug 20 02:46:33 2012
From: report at bugs.python.org (Benno Rice)
Date: Mon, 20 Aug 2012 00:46:33 +0000
Subject: [New-bugs-announce] [issue15730] Silence unused value warnings
	under Mac OS X 10.8/clang
Message-ID: <1345423593.46.0.41871412241.issue15730@psf.upfronthosting.co.za>


New submission from Benno Rice:

This patch silences a bunch of unused value warnings emitted by clang when building on Mac OS X 10.8.

----------
assignee: ronaldoussoren
components: Interpreter Core, Macintosh
files: warning-silencing.patch
keywords: patch
messages: 168609
nosy: Benno.Rice, ronaldoussoren
priority: normal
severity: normal
status: open
title: Silence unused value warnings under Mac OS X 10.8/clang
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26906/warning-silencing.patch

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

From report at bugs.python.org  Mon Aug 20 06:37:32 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 20 Aug 2012 04:37:32 +0000
Subject: [New-bugs-announce] [issue15731] Mechanism for inheriting
	docstrings and signatures
Message-ID: <1345437452.28.0.514901819881.issue15731@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

While working on #8810, I was reminded of the problem of wanting to inherit docstrings while replacing a method implementation.

The abstract base class method docstrings for tzinfo.utcoffset and tzinfo.dst are also correct for the concrete subclasses in the pure Python and the C versions. However, the docstrings currently need to be duplicated in all 3 places manually.

functools.wraps already plays in this space, but arguably asserts *too much* about the relationship between components

A couple of descriptors on bound and unbound methods (for __doc__ and __signature__) could have dealt with this fairly easily, but we don't have unbound methods any more :(

----------
components: Library (Lib)
messages: 168618
nosy: eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: Mechanism for inheriting docstrings and signatures
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug 20 09:43:41 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 20 Aug 2012 07:43:41 +0000
Subject: [New-bugs-announce] [issue15732] Crash (constructed) in
	_PySequence_BytesToCharpArray()
Message-ID: <1345448621.33.0.149221824706.issue15732@psf.upfronthosting.co.za>


New submission from Stefan Krah:

Coverity found an unchecked return value in _PySequence_BytesToCharpArray().
Patch attached.


A demonstration:

import _posixsubprocess
class Z(object):
    def __len__(self):
        return 1

_posixsubprocess.fork_exec(1,Z(),3,[1, 2],5,6,7,8,9,10,11,12,13,14,15,16,17)

----------
components: Interpreter Core
files: bytes_to_charp_array.diff
keywords: patch
messages: 168633
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Crash (constructed) in _PySequence_BytesToCharpArray()
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file26919/bytes_to_charp_array.diff

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

From report at bugs.python.org  Mon Aug 20 11:39:51 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Mon, 20 Aug 2012 09:39:51 +0000
Subject: [New-bugs-announce] [issue15733] PEP 3121,
	384 Refactoring applied to winapi module
Message-ID: <1345455591.0.0.532625871045.issue15733@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the winapi module!

----------
components: Extension Modules
files: _winapi_pep3121-384_v0.patch
keywords: patch
messages: 168639
nosy: Robin.Schreiber, astrand, effbot, loewis
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to winapi module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26921/_winapi_pep3121-384_v0.patch

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

From report at bugs.python.org  Mon Aug 20 11:52:31 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Mon, 20 Aug 2012 09:52:31 +0000
Subject: [New-bugs-announce] [issue15734] PEP 3121,
	384 Refactoring applied to spwd module
Message-ID: <1345456351.91.0.162191182976.issue15734@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the spwd module!

----------
components: Extension Modules
files: spwd_pep3121-384_v0.patch
keywords: patch
messages: 168641
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to spwd module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26923/spwd_pep3121-384_v0.patch

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

From report at bugs.python.org  Mon Aug 20 11:55:22 2012
From: report at bugs.python.org (Robin Schreiber)
Date: Mon, 20 Aug 2012 09:55:22 +0000
Subject: [New-bugs-announce] [issue15735] PEP 3121,
	384 Refactoring applied to ossaudio module
Message-ID: <1345456522.27.0.354179103538.issue15735@psf.upfronthosting.co.za>


New submission from Robin Schreiber:

Changes proposed in PEP3121 and PEP384 have now been applied to the ossaudio module!

----------
components: Extension Modules
files: ossaudiodev_pep3121-384_v0.patch
keywords: patch
messages: 168642
nosy: Robin.Schreiber
priority: normal
severity: normal
status: open
title: PEP 3121, 384 Refactoring applied to ossaudio module
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file26924/ossaudiodev_pep3121-384_v0.patch

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

From report at bugs.python.org  Mon Aug 20 11:55:30 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 20 Aug 2012 09:55:30 +0000
Subject: [New-bugs-announce] [issue15736] Crash #2 (constructed overflow)
	in	_PySequence_BytesToCharpArray()
Message-ID: <1345456530.94.0.929465650961.issue15736@psf.upfronthosting.co.za>


New submission from Stefan Krah:

A Py_ssize_t overflow can be constructed in _PySequence_BytesToCharpArray().
Patch attached.


Demonstration (requires revision >= 2af78f8a98e1):

Python 3.3.0b2+ (default:2af78f8a98e1, Aug 20 2012, 11:38:54)
[GCC 4.4.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, _posixsubprocess
[65851 refs]
>>> class Z(object):
...     def __len__(self):
...         return sys.maxsize
...     def __getitem__(self, i):
...         return b'x'
...
[65923 refs]
>>> _posixsubprocess.fork_exec(1,Z(),3,[1, 2],5,6,7,8,9,10,11,12,13,14,15,16,17)
Segmentation fault

----------
components: Interpreter Core
files: bytes_to_charp_array_overflow.diff
keywords: patch
messages: 168643
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Crash #2 (constructed overflow) in  _PySequence_BytesToCharpArray()
type: crash
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26925/bytes_to_charp_array_overflow.diff

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

From report at bugs.python.org  Mon Aug 20 12:41:38 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 20 Aug 2012 10:41:38 +0000
Subject: [New-bugs-announce] [issue15737] NULL dereference in zipimport.c
Message-ID: <1345459298.63.0.0891873759151.issue15737@psf.upfronthosting.co.za>


New submission from Stefan Krah:

There's a use of an unchecked return value in zipimport.c. Patch attached.

----------
components: Extension Modules
files: zipimport_null_dereference.diff
keywords: patch
messages: 168644
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: NULL dereference in zipimport.c
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file26926/zipimport_null_dereference.diff

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

From report at bugs.python.org  Mon Aug 20 13:32:20 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 20 Aug 2012 11:32:20 +0000
Subject: [New-bugs-announce] [issue15738] Crash (constructed) in
	subprocess_fork_exec()
Message-ID: <1345462340.12.0.207013540635.issue15738@psf.upfronthosting.co.za>


New submission from Stefan Krah:

Coverity found a missing NULL check in subprocess_fork_exec(). Patch attached.


Demonstration:

import _posixsubprocess
class Z(object):
    def __len__(self):
        return 1

_posixsubprocess.fork_exec(Z(),[b'1'],3,[1, 2],5,6,7,8,9,10,11,12,13,14,15,16,17)


[Segmentation fault]

----------
components: Extension Modules
files: subprocess_fork_exec.diff
keywords: patch
messages: 168645
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Crash (constructed) in subprocess_fork_exec()
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file26927/subprocess_fork_exec.diff

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

From report at bugs.python.org  Mon Aug 20 15:47:14 2012
From: report at bugs.python.org (Apple Grew)
Date: Mon, 20 Aug 2012 13:47:14 +0000
Subject: [New-bugs-announce] [issue15739] Python crashes with "Bus error: 10"
Message-ID: <1345470434.58.0.741490128779.issue15739@psf.upfronthosting.co.za>


New submission from Apple Grew:

Python crashes when I try to access (by sending http request from borwser) my Django application.

OS: Mac OSX Lion
Python version: 2.7.1 (This was pre-bundled with OS and not a MacPort).

There isn't a simple test case but I do have an open source app which where I am able to replicate this always on my system.

0. Make sure you have Django 1.4 installed.
1. Download the code at https://github.com/applegrew/django-select2/tree/v1.1-PythonCrasher
2. cd to django-select2/testapp folder.
3. Use python manage.py runserver & to run the server.
4. Now try accessing http://127.0.0.1:8000/ . It should crash immediately.

Lines which seem to cause the crash. Follow the following instructions and the application won't crash again.
1. Open django_select2/fields.py.
2. Comment line 128, uncomment line 129.
3. Uncomment line 156 and comment lines 158 and 159.
4. Now run the app again. This time it should work.

----------
components: Interpreter Core
files: Process         Python.txt
messages: 168660
nosy: Apple Grew
priority: normal
severity: normal
status: open
title: Python crashes with "Bus error: 10"
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file26929/Process         Python.txt

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

From report at bugs.python.org  Mon Aug 20 16:24:59 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 20 Aug 2012 14:24:59 +0000
Subject: [New-bugs-announce] [issue15740] test_ssl failure when cacert.org
	CA cert in system	keychain on OSX
Message-ID: <1345472699.98.0.29406283833.issue15740@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

On my laptop (running OSX 10.8, but I have noticed the same on earlier OSX releases) test_ssl fails:


======================================================================
FAIL: test_connect (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/ronald/Projects/python/rw/default/Lib/test/test_ssl.py", line 650, in test_connect
    s.connect, ("svn.python.org", 443))
AssertionError: SSLError not raised by connect

======================================================================
FAIL: test_connect_with_context (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/ronald/Projects/python/rw/default/Lib/test/test_ssl.py", line 743, in test_connect_with_context
    s.connect, ("svn.python.org", 443))
AssertionError: SSLError not raised by connect

======================================================================
FAIL: test_get_server_certificate (test.test_ssl.NetworkedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/ronald/Projects/python/rw/default/Lib/test/test_ssl.py", line 848, in test_get_server_certificate
    _test_get_server_certificate('svn.python.org', 443, SVN_PYTHON_ORG_ROOT_CERT)
  File "/Users/ronald/Projects/python/rw/default/Lib/test/test_ssl.py", line 840, in _test_get_server_certificate
    self.fail("Got server certificate %s for %s:%s!" % (pem, host, port))
AssertionError: Got server certificate -----BEGIN CERTIFICATE-----
MIIEmTCCAoGgAwIBAgIDCyOkMA0GCSqGSIb3DQEBBQUAMHkxEDAOBgNVBAoTB1Jv
b3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9y
dEBjYWNlcnQub3JnMB4XDTExMTIyNTIxMzIxNVoXDTEzMTIyNDIxMzIxNVowGTEX
MBUGA1UEAxMOc3ZuLnB5dGhvbi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDM6un3wTW9+HVJ7KC+/GwL0KAxehug0tw2YoSSX+TGxLyr9AUtBHQk
hCNWhRLewa0WMOY6hxIIQY1Hp6vreDiCbBehjVkEAydlKBzaAsgYCEbCC/ZaMzhv
aaFAiLVeaxAKJsBGUJNz5hGgzd67A6SGz+XK7qDWig4NR5eFrsr3DvjyEM7txMiG
gftGWLkadOuqUQsI20AykBGi+RxmrQIwqO2svGmje89DsWVILdP37PssM2zqRonh
4fUKooei3L43tXbTdHayXc9NtFS7q8T4eUlyWaD+BtP80QQOQFFvi+qZpme9bmYI
7YPX+e86lZtxAKM9nWrP93qc+2nS0MsHAgMBAAGjgYkwgYYwDAYDVR0TAQH/BAIw
ADA0BgNVHSUELTArBggrBgEFBQcDAgYIKwYBBQUHAwEGCWCGSAGG+EIEAQYKKwYB
BAGCNwoDAzALBgNVHQ8EBAMCBaAwMwYIKwYBBQUHAQEEJzAlMCMGCCsGAQUFBzAB
hhdodHRwOi8vb2NzcC5jYWNlcnQub3JnLzANBgkqhkiG9w0BAQUFAAOCAgEAEsw6
TMEXRn8ex1feaSNB5r2/aCLKE33ssGTp5HAyFo04YF2WaGK8HgjEg/fqrGUaSORw
P1ikBNTAUiaKbRQtcIvQPg8Zk4lSiQZ7m6ePs4hKdFVKeOpykwQyTsm+NaGk4xtM
Zk0XsWkzFntG676MT2FGvDCn0XhtdpAGJy59FXQ1mto9j99AvXpcl9Ja7tRYI/mI
goq3Gu6lwIoYSnslOtIWgsj9Wog1Kug7zoGscxY6z2lk15wbQlQbXbdAbVW7RZry
07eGwROLpE8tydRvvCbJp3P7FE+aAk1D3fQi09G0dUJWRmvBoFOVZCfHmGx23Mpz
YTVgGP1bydjjzzhNAqaKctLf6g3UuUwsOJ1pso4Cr/00EDWG1JsRb4wtlpAEPSnb
vjr/TqHMfefeQf4DmgWo1DutKhUBur5t+VukVCN1z44VtKeu8zaNaA3vR2Q+jArl
YxIFGUTuBcDHBx5Zl0Wcauoe3IbIBckBk2+WOBXVAdj00a46XJ4OHesft63HVOLn
vsKqAhwHPgsH0iTrgbO6ky0Xk573aJWz5wrlYin2FzHXsfJkA7U0wesrG4AFdeAm
zICOAFz9bOhyi6t5c0whF6L0W6Gt4cW+tERG+CD++2svdh8JP9QgozoSKd9N33bg
q5qGifkRs3lTJQGn2wDkgepX1vtshWgRXR9QTRw=
-----END CERTIFICATE-----
 for svn.python.org:443!


This machine has the cacert root certificate as a trusted key in the system keychain.

This is using Apple's copy of OpenSSL, I haven't tested yet if the test failure is also present with the upstream edition of OpenSSL.

The failure seems to occur because the test assumes that the OpenSSL library either won't load a CA list at all when ca_cert is not specified, or that the default CA list doesn't contain the cacert.org one.

I can avoid the test failures by always specifying ca_certs in these tests, but point the argument to an empty file. That's probably not the right solution though, hence I haven't included this as a patch.

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh, Tests
messages: 168661
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: test_ssl failure when cacert.org CA cert in system keychain on OSX
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Aug 20 16:46:13 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 20 Aug 2012 14:46:13 +0000
Subject: [New-bugs-announce] [issue15741] NULL dereference in
	builtin_compile()
Message-ID: <1345473973.6.0.856256957918.issue15741@psf.upfronthosting.co.za>


New submission from Stefan Krah:

Coverity found a missing NULL check in builtin_compile(). Patch attached.

----------
components: Interpreter Core
files: builtin-compile-check-null.diff
keywords: patch
messages: 168664
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: NULL dereference in builtin_compile()
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26930/builtin-compile-check-null.diff

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

From report at bugs.python.org  Mon Aug 20 19:11:56 2012
From: report at bugs.python.org (Mike Hoy)
Date: Mon, 20 Aug 2012 17:11:56 +0000
Subject: [New-bugs-announce] [issue15742] SQLite3 documentation changes
Message-ID: <1345482716.74.0.73441059198.issue15742@psf.upfronthosting.co.za>


New submission from Mike Hoy:

In Core-Mentorship we discussed this and decided on the following patch.

----------
assignee: docs at python
components: Documentation
files: sqlite3-docs-changes.diff
keywords: patch
messages: 168681
nosy: docs at python, mikehoy, r.david.murray
priority: normal
severity: normal
status: open
title: SQLite3 documentation changes
versions: Python 3.3
Added file: http://bugs.python.org/file26933/sqlite3-docs-changes.diff

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

From report at bugs.python.org  Mon Aug 20 21:58:39 2012
From: report at bugs.python.org (Jeff Knupp)
Date: Mon, 20 Aug 2012 19:58:39 +0000
Subject: [New-bugs-announce] [issue15743] test_urllib2/test_urllib use
	deprecated urllib.Request	methods
Message-ID: <1345492719.87.0.291856407657.issue15743@psf.upfronthosting.co.za>


New submission from Jeff Knupp:

urllib was updated to deprecate a number of Request methods for 3.3. The test_urllib2 and test_urllib tests still use some of the deprecated methods.

----------
components: Tests
messages: 168692
nosy: Jeff.Knupp
priority: normal
severity: normal
status: open
title: test_urllib2/test_urllib use deprecated urllib.Request methods
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Aug 21 00:05:57 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 20 Aug 2012 22:05:57 +0000
Subject: [New-bugs-announce] [issue15744] missing tests for {RawIO,
	BufferedIO, TextIO}.writelines
Message-ID: <1345500357.29.0.226025015503.issue15744@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The writelines() method of I/O objects has almost no tests in test_fileio / test_io (and a couple of them in test_file).

----------
components: IO, Tests
messages: 168709
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: missing tests for {RawIO,BufferedIO,TextIO}.writelines
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug 21 04:15:55 2012
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 21 Aug 2012 02:15:55 +0000
Subject: [New-bugs-announce] [issue15745] Numerous utime ns tests fail on
	FreeBSD w/ ZFS
Message-ID: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za>


New submission from Trent Nelson:

I've got two FreeBSD buildslaves running on ZFS (8.2 and 9.1) experiencing this:

======================================================================
FAIL: test_futimes_ns (test.test_os.StatAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 369, in test_futimes_ns
    self._test_utime_ns(futimes_ns, test_dir=False)
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 339, in _test_utime_ns
    self._test_utime(self.fname, getattr_ns, set_times_ns, ten_s)
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 318, in _test_utime
    self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime"))
AssertionError: 1345497270884503433 != 1345497270884503000

======================================================================
FAIL: test_lutimes_ns (test.test_os.StatAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 362, in test_lutimes_ns
    self._test_utime_ns(lutimes_ns)
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 339, in _test_utime_ns
    self._test_utime(self.fname, getattr_ns, set_times_ns, ten_s)
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 318, in _test_utime
    self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime"))
AssertionError: 1345497270888847634 != 1345497270888847000

======================================================================
FAIL: test_utime (test.test_os.StatAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 331, in test_utime
    self._test_utime(self.fname, getattr, utime, 10)
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 318, in _test_utime
    self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime"))
AssertionError: 1345497270.8923829 != 1345497270.892382

======================================================================
FAIL: test_utime_ns (test.test_os.StatAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 346, in test_utime_ns
    self._test_utime_ns(utime_ns)
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 339, in _test_utime_ns
    self._test_utime(self.fname, getattr_ns, set_times_ns, ten_s)
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_os.py", line 318, in _test_utime
    self.assertEqual(attr(st0, "st_mtime"), attr(st1, "st_mtime"))
AssertionError: 1345497270894558518 != 1345497270894558000


I briefly stepped through the test on one of the affected slaves.  There's a rounding issue somewhere... I personally think this method is involved:

    def _test_utime_ns(self, set_times_ns, test_dir=True):
        def getattr_ns(o, attr):
            return getattr(o, attr + "_ns")
        ten_s = 10 * 1000 * 1000 * 1000
        self._test_utime(self.fname, getattr_ns, set_times_ns, ten_s)
        if test_dir:
            self._test_utime(support.TESTFN, getattr_ns, set_times_ns, ten_s)

I didn't have enough time to keep debugging, so I'm raising this as a placeholder until I can pick it back up again.

----------
assignee: trent
messages: 168728
nosy: trent
priority: normal
severity: normal
stage: needs patch
status: open
title: Numerous utime ns tests fail on FreeBSD w/ ZFS
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug 21 04:17:52 2012
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 21 Aug 2012 02:17:52 +0000
Subject: [New-bugs-announce] [issue15746] test_winsound bombing out on 2003
	buildslave
Message-ID: <1345515472.32.0.153802141999.issue15746@psf.upfronthosting.co.za>


New submission from Trent Nelson:

The 'Windows Server 2003 R2 SP1' build slave I set up keeps bombing out on test_winsound:


======================================================================
FAIL: test_alias_nofallback (test.test_winsound.PlaySoundTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\Data\buildslave\cpython\2.7.snakebite-win2k3r2sp2-x86\build\lib\test\test_winsound.py", line 199, in test_alias_nofallback
    '!"$%&/(#+*', winsound.SND_ALIAS | winsound.SND_NODEFAULT
AssertionError: RuntimeError not raised


Raising this as a placeholder until I can look into it in more detail.

----------
assignee: trent
messages: 168729
nosy: trent
priority: normal
severity: normal
status: open
title: test_winsound bombing out on 2003 buildslave
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Aug 21 04:24:16 2012
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 21 Aug 2012 02:24:16 +0000
Subject: [New-bugs-announce] [issue15747] Various chflags tests failing on
	FreeBSD/ZFS
Message-ID: <1345515856.04.0.888770182553.issue15747@psf.upfronthosting.co.za>


New submission from Trent Nelson:

Both of my FreeBSD ZFS slaves (8.2 and 9.1) have chflags tests failing as follows:

======================================================================
ERROR: test_chflags (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildslave/cpython/3.2.snakebite-freebsd91-amd64/build/Lib/test/test_posix.py", line 350, in test_chflags
    self._test_chflags_regular_file(posix.chflags, support.TESTFN)
  File "/home/buildslave/cpython/3.2.snakebite-freebsd91-amd64/build/Lib/test/test_posix.py", line 337, in _test_chflags_regular_file
    chflags_func(target_file, st.st_flags | stat.UF_IMMUTABLE)
OSError: [Errno 45] Operation not supported: '@test_48794_tmp'

======================================================================
ERROR: test_lchflags_regular_file (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildslave/cpython/3.2.snakebite-freebsd91-amd64/build/Lib/test/test_posix.py", line 354, in test_lchflags_regular_file
    self._test_chflags_regular_file(posix.lchflags, support.TESTFN)
  File "/home/buildslave/cpython/3.2.snakebite-freebsd91-amd64/build/Lib/test/test_posix.py", line 337, in _test_chflags_regular_file
    chflags_func(target_file, st.st_flags | stat.UF_IMMUTABLE)
OSError: [Errno 45] Operation not supported: '@test_48794_tmp'

======================================================================
ERROR: test_lchflags_symlink (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildslave/cpython/3.2.snakebite-freebsd91-amd64/build/Lib/test/test_posix.py", line 367, in test_lchflags_symlink
    dummy_symlink_st.st_flags | stat.UF_IMMUTABLE)
OSError: [Errno 45] Operation not supported: '/tmp/@test_48794_tmp-dummy-symlink'

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

>From the FreeBSD chflags(1) manual page:


     The flags are specified as an octal number or a comma separated list of
     keywords.  The following keywords are currently defined:

           arch, archived
                   set the archived flag (super-user only)

           opaque  set the opaque flag (owner or super-user only)

           nodump  set the nodump flag (owner or super-user only)

           sappnd, sappend
                   set the system append-only flag (super-user only)

           schg, schange, simmutable
                   set the system immutable flag (super-user only)

           sunlnk, sunlink
                   set the system undeletable flag (super-user only)

           uappnd, uappend
                   set the user append-only flag (owner or super-user only)

           uchg, uchange, uimmutable
                   set the user immutable flag (owner or super-user only)

           uunlnk, uunlink
                   set the user undeletable flag (owner or super-user only)


That indicates only root can set the immutable flag -- but if this were the case, I wonder why none of the other FreeBSD build slaves have run into it?

Either way, placeholder issue until I can spend some more time on it.

----------
assignee: trent
components: Tests
messages: 168730
nosy: trent
priority: normal
severity: normal
status: open
title: Various chflags tests failing on FreeBSD/ZFS
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug 21 04:27:18 2012
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 21 Aug 2012 02:27:18 +0000
Subject: [New-bugs-announce] [issue15748] Various symlink test failures in
	test_shutil on FreeBSD
Message-ID: <1345516038.44.0.114148239105.issue15748@psf.upfronthosting.co.za>


New submission from Trent Nelson:

FreeBSD slaves are running into this:


======================================================================
ERROR: test_copy2_symlinks (test.test_shutil.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_shutil.py", line 490, in test_copy2_symlinks
    shutil.copy2(src_link, dst, follow_symlinks=False)
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/shutil.py", line 237, in copy2
    copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/shutil.py", line 107, in copyfile
    os.symlink(os.readlink(src), dst)
TypeError: embedded NUL character

======================================================================
ERROR: test_copy_symlinks (test.test_shutil.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_shutil.py", line 463, in test_copy_symlinks
    shutil.copy(src_link, dst, follow_symlinks=False)
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/shutil.py", line 221, in copy
    copyfile(src, dst, follow_symlinks=follow_symlinks)
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/shutil.py", line 107, in copyfile
    os.symlink(os.readlink(src), dst)
TypeError: embedded NUL character

======================================================================
FAIL: test_copytree_symlinks (test.test_shutil.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildslave/cpython/3.x.snakebite-freebsd91-amd64/build/Lib/test/test_shutil.py", line 606, in test_copytree_symlinks
    os.path.join(src_dir, 'file.txt'))
AssertionError: '/tmp/tmpqlihz5/src/file.' != '/tmp/tmpqlihz5/src/file.txt'
- /tmp/tmpqlihz5/src/file.
+ /tmp/tmpqlihz5/src/file.txt
?                         +++


Haven't had time to debug it any further yet.  Have no clue what's going on either just from a cursory look at the error messages.  Not sure if it's ZFS related like the other FreeBSD issues.

----------
assignee: trent
components: Tests
messages: 168731
nosy: trent
priority: normal
severity: normal
status: open
title: Various symlink test failures in test_shutil on FreeBSD
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Aug 21 06:36:35 2012
From: report at bugs.python.org (aliles)
Date: Tue, 21 Aug 2012 04:36:35 +0000
Subject: [New-bugs-announce] [issue15749] cgitb prints html for text when
	display disabled.
Message-ID: <1345523795.76.0.397222969623.issue15749@psf.upfronthosting.co.za>


New submission from aliles:

If cgitb has been enabled to format as text but suppress the display, the output is formated as html. (Prefixed with <p>)

 >>> gitb.enable(display=0, format='txt')
 >>> raise ValueError('Oops!')
 <p>A problem occurred in a Python script.

The patch changes the prefix used when display is suppressed based on whether output is formatted as html or text. Includes unit tests and documentation updates.

----------
components: Library (Lib)
files: p1345523495.diff
keywords: patch
messages: 168735
nosy: aliles, ncoghlan
priority: normal
severity: normal
status: open
title: cgitb prints html for text when display disabled.
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file26941/p1345523495.diff

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

From report at bugs.python.org  Tue Aug 21 07:15:36 2012
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 21 Aug 2012 05:15:36 +0000
Subject: [New-bugs-announce] [issue15750]
	test_localtime_daylight_false_dst_true raises	OverflowError:
	mktime argument out of range
Message-ID: <1345526136.06.0.661867821529.issue15750@psf.upfronthosting.co.za>


New submission from Trent Nelson:

On the FreeBSD 8.2 build slave:

======================================================================
ERROR: test_localtime_daylight_false_dst_true (test_utils.LocaltimeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildslave/python/3.x.snakebite-freebsd82-amd64/build/Lib/test/test_email/test_utils.py", line 86, in test_localtime_daylight_false_dst_true
    t1 = utils.localtime(t0, isdst=1)
  File "/home/buildslave/python/3.x.snakebite-freebsd82-amd64/build/Lib/email/utils.py", line 397, in localtime
    seconds = time.mktime(tm)
OverflowError: mktime argument out of range

======================================================================
ERROR: test_localtime_daylight_true_dst_true (test_utils.LocaltimeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildslave/python/3.x.snakebite-freebsd82-amd64/build/Lib/test/test_email/test_utils.py", line 79, in test_localtime_daylight_true_dst_true
    t1 = utils.localtime(t0, isdst=1)
  File "/home/buildslave/python/3.x.snakebite-freebsd82-amd64/build/Lib/email/utils.py", line 397, in localtime
    seconds = time.mktime(tm)
OverflowError: mktime argument out of range

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


Placeholder issue, haven't looked into it in detail yet.

----------
components: Tests
messages: 168741
nosy: trent
priority: normal
severity: normal
stage: needs patch
status: open
title: test_localtime_daylight_false_dst_true raises OverflowError: mktime argument out of range
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug 21 07:18:21 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 21 Aug 2012 05:18:21 +0000
Subject: [New-bugs-announce] [issue15751] Add PyGILState_SwitchInterpreter
Message-ID: <1345526301.75.0.455071650321.issue15751@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Currently, modules that use the PyGILState* APIs cannot be used with mod_wsgi, as mod_wsgi uses the subinterpreter support.

Graham Dumpleton and I spent some time discussing this at PyCon AU 2012, and we believe that the incompatibility can be resolved with a single API in the core: a function that mod_wsgi can call to set the interpreter used by the GIL state APIs to implicitly create new thread states.

This is still only a seed of an idea (and it's entirely possible we've missed something), but it's a place to start in resolving this longstanding incompatibility.

----------
messages: 168742
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add PyGILState_SwitchInterpreter
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Aug 21 10:32:47 2012
From: report at bugs.python.org (Jeff Knupp)
Date: Tue, 21 Aug 2012 08:32:47 +0000
Subject: [New-bugs-announce] [issue15752] change test_json's use of
	deprecated unittest function
Message-ID: <1345537967.19.0.778134017296.issue15752@psf.upfronthosting.co.za>


New submission from Jeff Knupp:

patch to test_json to not use assert(Raises)Regexp, which has been deprecated in favor of assert(Raises)Regex.

----------
components: Tests
files: json_deprecated.patch
keywords: patch
messages: 168750
nosy: Jeff.Knupp
priority: normal
severity: normal
status: open
title: change test_json's use of deprecated unittest function
versions: Python 3.3
Added file: http://bugs.python.org/file26944/json_deprecated.patch

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

From report at bugs.python.org  Tue Aug 21 13:52:40 2012
From: report at bugs.python.org (James)
Date: Tue, 21 Aug 2012 11:52:40 +0000
Subject: [New-bugs-announce] [issue15753] No-argument super in method with
	variable arguments	raises SystemError
Message-ID: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za>


New submission from James:

For example:

Python 3.2.2 (default, Feb 10 2012, 09:23:17) 
[GCC 4.4.5 20110214 (Red Hat 4.4.5-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
...     def f(*args):
...             print(super().__repr__())
... 
>>> A().f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in f
SystemError: super(): no arguments

(There is no change in the current development version 3.3.0b2+)

I guess that the problem here is related to the fact that the super call makes sense if we call A().f() but not if we call A.f() (which is allowed by the method signature)?  I understand that not including self in the signature is almost always bad style, but occasionally it is necessary, for example if you want to allow arbitrary keyword arguments as dict.update does.

Also, how come using the no-argument form of super outside a method raises SystemError - isn't that supposed to be for internal errors?

----------
components: Interpreter Core
messages: 168757
nosy: james.sanders
priority: normal
severity: normal
status: open
title: No-argument super in method with variable arguments raises SystemError
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug 21 16:36:27 2012
From: report at bugs.python.org (John Taylor)
Date: Tue, 21 Aug 2012 14:36:27 +0000
Subject: [New-bugs-announce] [issue15754] Traceback message not returning
	SQLite check constraint	details
Message-ID: <1345559787.18.0.3645038202.issue15754@psf.upfronthosting.co.za>


New submission from John Taylor:

According to:
http://www.sqlite.org/releaselog/3_7_12.html

SQLite has the ability to, "Report the name of specific CHECK constraints that fail."

CPython 3.3.0b2 which uses SQLite version 3.7.12 does not report which constraint failed.
--
import platform, sqlite3

print("Platform : %s %s" % (platform.python_implementation(),platform.python_version()))
print("SQLite   : %s" % (sqlite3.sqlite_version))
print()

tbl="""\
create table test1 (
        db_insert_date       timestamp,
        check( cast(substr(db_insert_date,1,4) as integer) >= 2000 and cast(substr(db_insert_date,1,4) as integer) <= 2025),
        check( cast(substr(db_insert_date,6,2) as integer) >= 1    and cast(substr(db_insert_date,6,2) as integer) <= 12),
        check( cast(substr(db_insert_date,9,2) as integer) >= 1    and cast(substr(db_insert_date,9,2) as integer) <= 31)
)
"""

conn = sqlite3.connect(":memory:")
c = conn.cursor()
c.execute(tbl)

query = "insert into test1 values( ? )"
c.execute(query, ("2012-08-20", ) )
conn.commit() # this works

c.execute(query, ("2012-18-20", ) )
conn.commit() # returns: sqlite3.IntegrityError: constraint failed (but which constraint?)

"""
Traceback (most recent call last):
  File "C:bug.py", line 34, in <module>
    c.execute(query, ("2012-18-20", ) )
sqlite3.IntegrityError: constraint failed
"""

----------
components: Extension Modules
messages: 168777
nosy: ghaering, jftuga
priority: normal
severity: normal
status: open
title: Traceback message not returning SQLite check constraint details
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Aug 21 21:07:25 2012
From: report at bugs.python.org (Todd Whiteman)
Date: Tue, 21 Aug 2012 19:07:25 +0000
Subject: [New-bugs-announce] [issue15755] subprocess.poll() does not handle
	errno.ECHILD "No child	processes"
Message-ID: <1345576044.94.0.209719026711.issue15755@psf.upfronthosting.co.za>


New submission from Todd Whiteman:

In the case of a "errno.ECHILD" exception - Python's subprocess module misses the fact that the process has already ended.

The following code will wait indefinitely, even though the launched process is quickly ended:

import subprocess, signal
signal.signal(signal.SIGCLD, signal.SIG_IGN)
p = subprocess.Popen(['echo','foo'])
while p.poll() is None:
   pass # wait for the process to exit

Note: This is the exact same issue as issue1731717, but applying to the subprocess.poll() method instead of the subprocess.wait() method.

----------
components: Library (Lib)
messages: 168797
nosy: gregory.p.smith, twhitema
priority: normal
severity: normal
status: open
title: subprocess.poll() does not handle errno.ECHILD "No child processes"
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug 21 21:15:17 2012
From: report at bugs.python.org (Todd Whiteman)
Date: Tue, 21 Aug 2012 19:15:17 +0000
Subject: [New-bugs-announce] [issue15756] subprocess.poll() does not handle
	errno.ECHILD "No child	processes"
Message-ID: <1345576517.75.0.906463701582.issue15756@psf.upfronthosting.co.za>


New submission from Todd Whiteman:

In the case of a "errno.ECHILD" exception - Python's subprocess module misses the fact that the process has already ended.

The following code will wait indefinitely, even though the launched process is quickly ended:

import subprocess, signal
signal.signal(signal.SIGCLD, signal.SIG_IGN)
p = subprocess.Popen(['echo','foo'])
while p.poll() is None:
   pass # wait for the process to exit

Note: This is the exact same issue as issue1731717, but applying to the subprocess.poll() method instead of the subprocess.wait() method.

----------
components: Library (Lib)
messages: 168798
nosy: twhitema
priority: normal
severity: normal
status: open
title: subprocess.poll() does not handle errno.ECHILD "No child processes"
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Aug 21 23:29:41 2012
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 21 Aug 2012 21:29:41 +0000
Subject: [New-bugs-announce] [issue15757] ./configure --with-pydebug on
	FreeBSD results in -O2	-pipe eventually ending up in CFLAGS.
Message-ID: <1345584581.07.0.102502771699.issue15757@psf.upfronthosting.co.za>


New submission from Trent Nelson:

All the FreeBSD build slaves seem to be experiencing the same symptom: ./configure --with-pydebug eventually results in this:

    gcc -pthread -c -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes  -O2 -pipe -fno-strict-aliasing -Wall -march=native   -I. -I./Include    -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c

What I find odd:

  % grep -e '-O2' Makefile | wc -l
         0

There are references to -O2 elsewhere, like in configure.ac|configure, but, the Makefile doesn't source any of those.  (Right?)

This is occurring on all of my slaves as well as others, so I'm pretty sure it's not just specific to my environment.

----------
assignee: trent
messages: 168805
nosy: koobs, skrah, trent
priority: normal
severity: normal
status: open
title: ./configure --with-pydebug on FreeBSD results in -O2 -pipe eventually ending up in CFLAGS.
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Aug 22 00:25:10 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Tue, 21 Aug 2012 22:25:10 +0000
Subject: [New-bugs-announce] [issue15758] 500x speed up for
	Popen.communicate() on Windows
Message-ID: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za>


New submission from Richard Oudkerk:

Piping significant amounts of data through a subprocess using Popen.communicate() is crazily slow on Windows.

The attached program just pushes data through mingw's cat.exe.

Python 3.3:
amount = 1 MB; time taken = 0.07 secs; rate = 13.51 MB/s
amount = 2 MB; time taken = 0.31 secs; rate = 6.51 MB/s
amount = 4 MB; time taken = 1.30 secs; rate = 3.08 MB/s
amount = 8 MB; time taken = 5.43 secs; rate = 1.47 MB/s
amount = 16 MB; time taken = 21.64 secs; rate = 0.74 MB/s
amount = 32 MB; time taken = 87.36 secs; rate = 0.37 MB/s

Python 2.7:
amount = 1 MB; time taken = 0.02 secs; rate = 66.67 MB/s
amount = 2 MB; time taken = 0.03 secs; rate = 68.97 MB/s
amount = 4 MB; time taken = 0.05 secs; rate = 76.92 MB/s
amount = 8 MB; time taken = 0.10 secs; rate = 82.47 MB/s
amount = 16 MB; time taken = 0.27 secs; rate = 60.38 MB/s
amount = 32 MB; time taken = 0.88 secs; rate = 36.36 MB/s
amount = 64 MB; time taken = 3.20 secs; rate = 20.03 MB/s
amount = 128 MB; time taken = 12.36 secs; rate = 10.35 MB/s

For Python 3.3 this looks like O(n^2) complexity to me.  2.7 is better but still struggles for large amounts.

Changing Popen._readerthread() to read in chunks rather than using FileIO.readall() produces a huge speed up:

Python 3.3 with patch:
amount = 1 MB; time taken = 0.01 secs; rate = 76.92 MB/s
amount = 2 MB; time taken = 0.03 secs; rate = 76.92 MB/s
amount = 4 MB; time taken = 0.04 secs; rate = 111.10 MB/s
amount = 8 MB; time taken = 0.05 secs; rate = 148.14 MB/s
amount = 16 MB; time taken = 0.10 secs; rate = 156.85 MB/s
amount = 32 MB; time taken = 0.16 secs; rate = 198.75 MB/s
amount = 64 MB; time taken = 0.31 secs; rate = 205.78 MB/s
amount = 128 MB; time taken = 0.61 secs; rate = 209.82 MB/s

Maybe FileIO.readall() should do something similar for files whose size cannot be determined by stat().

----------
components: Library (Lib)
files: push-thru-cat.py
messages: 168813
nosy: sbt
priority: normal
severity: normal
stage: patch review
status: open
title: 500x speed up for Popen.communicate() on Windows
type: performance
Added file: http://bugs.python.org/file26952/push-thru-cat.py

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

From report at bugs.python.org  Wed Aug 22 07:34:23 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 22 Aug 2012 05:34:23 +0000
Subject: [New-bugs-announce] [issue15759] "make suspicious" doesn't display
	instructions in case	of failure
Message-ID: <1345613663.78.0.519613331574.issue15759@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

I was running "make suspicious" in Doc/ and this was the output after finding 3 suspicious markups:

 writing output... [ 52%] library/inspect
 WARNING: [library/inspect:437] ":int" found in ">>> def foo(a, *, b:int, **kwargs):"
 WARNING: [library/inspect:437] ":int" found in "'(a, *, b:int, **kwargs)'"
 WARNING: [library/inspect:437] ":int" found in "'b:int'"
 writing output... [100%] whatsnew/index
 build finished with problems, 3 warnings.
 make: *** [build] Error 1

After figuring out how to mark these as false positives and adding the relevant entries to susp-ignored.csv, I ran "make suspicious" again, and got this useful message at the end:

 writing output... [100%] whatsnew/index
 build succeeded.

 Suspicious check complete; look for any errors in the above output or in build/suspicious /suspicious.csv.  If all issues are false positives, append that file to tools/sphinxext/susp-ignored.csv.

The problem is that this message should be displayed when there are failures, but it's not.

Attached an attempt to fix the Makefile to avoid exiting in case of failures when the builder is "suspicious".  Given that I'm not really familiar with makefiles, it probably doesn't make much sense.

----------
assignee: docs at python
components: Documentation
files: issue15759.diff
keywords: patch
messages: 168842
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
stage: patch review
status: open
title: "make suspicious" doesn't display instructions in case of failure
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file26956/issue15759.diff

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

From report at bugs.python.org  Wed Aug 22 10:15:56 2012
From: report at bugs.python.org (Lennart Regebro)
Date: Wed, 22 Aug 2012 08:15:56 +0000
Subject: [New-bugs-announce] [issue15760] make install should generate
	grammar file
Message-ID: <1345623356.64.0.534348274406.issue15760@psf.upfronthosting.co.za>


New submission from Lennart Regebro:

If you install Python 3.3b2 with "sudo make install", a standard way of installing it so that users don't have rights to install global modules, then everytime lib2to3.pgen2.driver.load_grammar() is called, it aims to generate a a grammar table and write it as a pickle to a cache file.

However, unless you are superuser when doing this, writing the file will of course fail, with a message similar to this:

INFO:root:Generating grammar tables from /opt/python33/lib/python3.3/lib2to3/PatternGrammar.txt
INFO:root:Writing grammar tables to /opt/python33/lib/python3.3/lib2to3/PatternGrammar3.3.0.beta.2.pickle
INFO:root:Writing failed:[Errno 13] Permission denied: '/opt/python33/lib/python3.3/lib2to3/PatternGrammar3.3.0.beta.2.pickle'

A workaround is to run the script that creates the above errors as superuser once, and the message goes away.

I think the correct thing to do here is for make install to Generate these grammar tables and write the pickle. 

Steps to reproduce:

1. Install Python 3.3.b2 with "./configure;make;sudo make install"
2. Check out the Distribute sources: "hg clone https://bitbucket.org/stefanholek/distribute"
3. Run the Distribute tests: "python3.3 setup.py test"

----------
messages: 168854
nosy: lregebro
priority: normal
severity: normal
status: open
title: make install should generate grammar file
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Aug 22 10:21:47 2012
From: report at bugs.python.org (Ned Deily)
Date: Wed, 22 Aug 2012 08:21:47 +0000
Subject: [New-bugs-announce] [issue15761] Setting PYTHONEXECUTABLE can cause
	segfaults on OS X
Message-ID: <1345623707.33.0.86377230375.issue15761@psf.upfronthosting.co.za>


New submission from Ned Deily:

Setting the environment variable PYTHONEXECUTABLE can cause the interpreter to crash with a segfault or to otherwise fail during initialization.  Another manifestation is the failure of test test_osx_env with:

AssertionError: -10 != 2 : expected PYTHONEXECUTABLE == sys.executable

(-10 means the interpreter subprocess under test segfaulted)

I have not yet been able to identify the root cause or the minimum set of conditions to produce a crash.  So far it seems that the interpreter must be 32-bit and running on 10.6 or later.  In all of the failures I've seen, PYTHONEXECUTABLE was set to an absolute path, not necessarily a valid path.  When running a debug build, I've seen two failure modes:

Assertion failed: (value), function PyDict_SetItem, file 
Objects/dictobject.c, line 1197.

#0  0x942a9332 in __kill ()
#1  0x942a8932 in kill$UNIX2003 ()
#2  0x98563c0c in abort ()
#3  0x9859820b in __assert_rtn ()
#4  0x00091b0f in PyDict_SetItem (op=0x48f438, key=0x487610, value=0x0) at Objects/dictobject.c:1197
#5  0x0009669d in PyDict_SetItemString (v=0x48f438, key=0x30ccfd "version", item=0x0) at Objects/dictobject.c:2695
#6  0x00245616 in make_impl_info (version_info=0x0) at ./Python/sysmodule.c:1525
#7  0x00244a00 in _PySys_Init () at ./Python/sysmodule.c:1690
#8  0x0022fdc1 in _Py_InitializeEx_Private (install_sigs=1, install_importlib=1) at Python/pythonrun.c:334
#9  0x00231577 in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:401
#10 0x0023159a in Py_Initialize () at Python/pythonrun.c:407
#11 0x00269138 in Py_Main (argc=3, argv=0x446028) at Modules/main.c:646


Also:
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: unable to load the file system codec
ImportError: No module named 'encodings'

#0  0x942a9332 in __kill ()
#1  0x942a8932 in kill$UNIX2003 ()
#2  0x98563c0c in abort ()
#3  0x001a8d09 in Py_FatalError (
    msg=0x2506d4 "Py_Initialize: unable to load the file system codec")
    at Python/pythonrun.c:2358
#4  0x001a3320 in _Py_InitializeEx_Private (install_sigs=1, install_importlib=1)
    at Python/pythonrun.c:374
#5  0x001a3442 in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:401
#6  0x001a3456 in Py_Initialize () at Python/pythonrun.c:407
#7  0x001cd0f2 in Py_Main (argc=1, argv=0x394028) at Modules/main.c:646
#8  0x000025e7 in main (argc=1, argv=0xbffff994) at python.c:66

Inspecting and gdb stepping through main.c, getpath.c, and pythonrun.c has not uncovered anything obvious yet.  Note, there have been changes in these areas for 3.3 in support of venv and bug fixes.

PYTHONEXECUTABLE is a somewhat vestigial environment variable supported only on OS X.  AFAIK, it was only intended for used with the deprecated bundlebuilder.py tool but it is externally documented; it's also still used by IDLE.app initialization which is based on bundlebuilder.  So it might not be a release blocker to fix immediately but it is disquieting.  As there are other higher priority issues at the moment, I probably won't be able to get back to this until after rc1.

----------
assignee: ronaldoussoren
components: Macintosh
messages: 168856
nosy: ned.deily, ronaldoussoren
priority: high
severity: normal
status: open
title: Setting PYTHONEXECUTABLE can cause segfaults on OS X
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Wed Aug 22 10:53:25 2012
From: report at bugs.python.org (Aaron Galea)
Date: Wed, 22 Aug 2012 08:53:25 +0000
Subject: [New-bugs-announce] [issue15762] Windows 8 certification
Message-ID: <1345625605.38.0.633732854192.issue15762@psf.upfronthosting.co.za>


New submission from Aaron Galea:

Hi

We have an application created with python2.7 and created into an executable using py2exe. However we are getting an issue with Windows 8 certification due to compiler parameters. We would like to have this application Windows 8 certified but we can't get pass the following warning:
===============================================
Windows security features test 


WARNING 
Binary analyzer
?
Warning: The binary analyzer test detected the following errors: 
?File C:\Program Files (x86)\TestApp\test.exe has failed the DBCheck check.
?File C:\Program Files (x86)\TestApp\test.exe has failed the NXCheck check.

?
Impact if not fixed: If the app doesn?t use the available Windows protections, it can increase the vulnerability of customer's computer to malware. 

?
How to fix: Apply the SAFESEH, DYNAMICBASE, and NXCOMPAT options when you link the app. See link below for more information:
Fixing Binary Analyzer Errors 

========================================================================

In order to fix this issue I had to modify the file msvc9compiler.py by changing the following line from:

self.ldflags_shared = ['/DLL', '/nologo', '/INCREMENTAL:NO']

to

self.ldflags_shared = ['/DLL', '/nologo', '/INCREMENTAL:NO', '/DYNAMICBASE', '/SAFESEH', '/NXCOMPAT']

and rebuild py2exe. Once I have done this the test passed.

I could go about it by having local patch available to my team but preferably I try to avoid patching the standard python modules.

My question is if there is another way to do this? and whether it would be a good idea to include these flags in future distutils?

----------
assignee: eric.araujo
components: Distutils
messages: 168859
nosy: agale031176, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Windows 8 certification
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug 22 13:28:08 2012
From: report at bugs.python.org (Helmut Jarausch)
Date: Wed, 22 Aug 2012 11:28:08 +0000
Subject: [New-bugs-announce] [issue15763] email non-ASCII characters in TO
	or FROM field doesn't	work
Message-ID: <1345634888.16.0.670176453288.issue15763@psf.upfronthosting.co.za>


New submission from Helmut Jarausch:

Trying to generate an email with Latin-1 characters in the TO or FROM
field either produces an exception or produces strange values in the generated email:

Using  Python 3.2.3+ (3.2:481f5d9ef577+, Aug  8 2012, 10:00:28) 


#!/usr/bin/python3
#-*- coding: latin1 -*-

import smtplib
from email.message import Message
import datetime
import sys

msg= Message()
msg.set_charset('latin-1')
msg['Subject'] = "*** Email Test ***"

# the following gives a  UnicodeDecodeError: 'ascii' codec can't decode byte 0xfc ..
# in File "/usr/lib64/python3.2/email/header.py", line 281, in append
# msg['From'] = FromAddr = "G?nter Gro? <Email_Tester at numa-sv.igpm.rwth-aachen.de>".encode('iso-8859-1')


# The following doesn't crash Python but generates a strange "From" string :
# =?utf-8?b?R8O8bnRlciBHcm/DnyA8RW1haWxfVGVzdGVyQG51bWEtc3YuaWdwbS5yd3RoLWFhY2hlbi5kZT4=?=

msg['From'] = FromAddr = "G?nter Gro? <Email_Tester at numa-sv.igpm.rwth-aachen.de>"


# The same with this one
msg['To']   = ToAddr   = "G?nter Wei?e <jarausch at igpm.rwth-aachen.de>"

DATE = datetime.datetime.utcnow().strftime('%m/%d/%Y %I:%M:%S %p')
msg['Date'] = datetime.datetime.utcnow().strftime('%m/%d/%Y %I:%M:%S %p')

server= smtplib.SMTP("igpm.igpm.rwth-aachen.de")
# server= smtplib.SMTP('relay.skynet.be')
server.set_debuglevel(9)

msg.set_payload("Gedanken ?ber einen Test","iso-8859-1")
# server.send_message(msg)
server.sendmail(FromAddr,ToAddr,msg.as_string().encode("iso-8859-1"))
server.quit()

----------
components: email
messages: 168869
nosy: HWJ, barry, r.david.murray
priority: normal
severity: normal
status: open
title: email  non-ASCII characters in TO or FROM field doesn't work
versions: Python 3.2

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

From report at bugs.python.org  Wed Aug 22 14:51:12 2012
From: report at bugs.python.org (Jens Henrik Leonhard Jensen)
Date: Wed, 22 Aug 2012 12:51:12 +0000
Subject: [New-bugs-announce] [issue15764] Sqlite3 performance
Message-ID: <1345639872.28.0.424388144832.issue15764@psf.upfronthosting.co.za>


New submission from Jens Henrik Leonhard Jensen:

The _sqlite modules uses sqlite3_prepare and not sqlite3_prepare_v2.
With sqlite3_prepare_v2 enables more optiomation.

Workaround:
Do not use parameters as the right hand argument to GLOB or LIKE.

For more documentation see http://www.sqlite.org/optoverview.html.

----------
components: Extension Modules
files: db-test.py
messages: 168881
nosy: jhlj
priority: normal
severity: normal
status: open
title: Sqlite3 performance
type: performance
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26964/db-test.py

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

From report at bugs.python.org  Wed Aug 22 16:12:15 2012
From: report at bugs.python.org (Trent Nelson)
Date: Wed, 22 Aug 2012 14:12:15 +0000
Subject: [New-bugs-announce] [issue15765] test_getcwd_long_pathnames (in
	test_posix) kills NetBSD
Message-ID: <1345644735.97.0.561553846154.issue15765@psf.upfronthosting.co.za>


New submission from Trent Nelson:

The 2.7 builds of both my NetBSD slaves keep hanging on test_posix (and eventually time out after an hour).  Running the test manually:


netbsd51-x86-1$ pwd                       
/home/cpython/2.7
netbsd51-x86-1$ b/test/regrtest.py -uall -rwW -v test_posix                   <
== CPython 2.7.3+ (2.7:c1c45755397b, Aug 22 2012, 14:05:02) [GCC 4.1.3 20080704 prerelease (NetBSD nb2 20081120)]
==   NetBSD-5.1.2-i386-32bit-ELF little-endian
==   /home/cpython/2.7/build/test_python_10630
Testing with flags: sys.flags(debug=0, py3k_warning=1, division_warning=1, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, tabcheck=2, verbose=0, unicode=0, bytes_warning=0, hash_randomization=1)
Using random seed 2040018
test_posix
testNoArgFunctions (test.test_posix.PosixTester) ... ok
test_access (test.test_posix.PosixTester) ... ok
test_chdir (test.test_posix.PosixTester) ... ok
test_chflags (test.test_posix.PosixTester) ... ok
test_chown (test.test_posix.PosixTester) ... ok
test_confstr (test.test_posix.PosixTester) ... ok
test_dup (test.test_posix.PosixTester) ... ok
test_dup2 (test.test_posix.PosixTester) ... ok
test_fchown (test.test_posix.PosixTester) ... ok
test_fdopen (test.test_posix.PosixTester) ... ok
test_fstat (test.test_posix.PosixTester) ... ok
test_fstatvfs (test.test_posix.PosixTester) ... ok
test_ftruncate (test.test_posix.PosixTester) ... ok
test_getcwd_long_pathnames (test.test_posix.PosixTester) ... load: 0.50  cmd: python 10630 [runnable] 0.27u 13.07s 46% 10976k
load: 0.87  cmd: python 10630 [runnable] 0.27u 94.24s 98% 10976k
^C^C

Placeholder issue at the moment.

....although this looks pretty dodgy:


                    os.chdir(dirname)
                    try:
                        os.getcwd()
                        if current_path_length < 4099:
                            _create_and_do_getcwd(dirname, current_path_length + len(dirname) + 1)

----------
assignee: trent
messages: 168885
nosy: trent
priority: normal
severity: normal
status: open
title: test_getcwd_long_pathnames (in test_posix) kills NetBSD
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug 22 17:41:23 2012
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Aug 2012 15:41:23 +0000
Subject: [New-bugs-announce] [issue15766] _imp.load_dynamic() does crash
	with non-ASCII path and	uses the wrong encoding
Message-ID: <1345650083.26.0.403963695134.issue15766@psf.upfronthosting.co.za>


New submission from STINNER Victor:

_imp.load_dynamic() use UTF-8 (PyUnicode_FromString) to decode the error message from dlerror(), whereas the locale encoding should be used. The path is decoded from UTF-8, whereas the filesystem encoding should be used.

As a result, error_ob and path can be NULL, whereas Py_DECREF() is used and so Python does crash (SIGSEGV).

Attached patch should avoid a crash, but I'm not sure that it is enough to support non-ASCII path: pathname is "./" is the path is not an absolute path.

PyOS_snprintf(pathbuf, sizeof(pathbuf), "./%-.255s", pathname);
  should maybe be replaced with
pathbytes = PyBytes_FromFormat("./%s", pathname);

----------
components: Tkinter
files: imp.patch
keywords: patch
messages: 168892
nosy: brett.cannon, haypo
priority: normal
severity: normal
status: open
title: _imp.load_dynamic() does crash with non-ASCII path and uses the wrong encoding
type: crash
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26965/imp.patch

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

From report at bugs.python.org  Wed Aug 22 21:45:18 2012
From: report at bugs.python.org (Eric Snow)
Date: Wed, 22 Aug 2012 19:45:18 +0000
Subject: [New-bugs-announce] [issue15767] add ModuleNotFoundError
Message-ID: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za>


New submission from Eric Snow:

In issue 15316 (msg168896, Brett Cannon):

  Create a ModuleNotFoundError exception that subclasses ImportError
  and catch that (breaks doctests and introduces a new exception that
  people will need to be aware of, plus the question of whether it
  should just exist in importlib or be a builtin)

While it's too late to go into 3.3, this is a reasonable addition for 3.4.  Perhaps other ImportError subclasses are warranted, but they can be addressed separately.

----------
components: Interpreter Core
messages: 168906
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: add ModuleNotFoundError
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Aug 23 02:03:05 2012
From: report at bugs.python.org (Eric Cousineau)
Date: Thu, 23 Aug 2012 00:03:05 +0000
Subject: [New-bugs-announce] [issue15768] re.sub() with re.MULTILINE not
	replacing all occurrences
Message-ID: <1345680185.37.0.726682909185.issue15768@psf.upfronthosting.co.za>


New submission from Eric Cousineau:

[Copying post I made here: http://stackoverflow.com/questions/12082886/bug-in-python-regex-re-sub-with-re-multiline]

I'm noticing some odd behavior in Python's Regex library, and I'm not sure if I'm doing something wrong.

If I run a regex on it using re.sub(), with re.MULTILINE. It seems to only replace the first few occurrences. It replaces all occurrences if I turn off re.MULTILINE, use re.subn(..., count = 0, flags = re.MULTILINE), or compile the regex using re.compile(..., re.MULTILINE).

I am running Python 2.7 on Ubuntu 12.04.

I've posted a random example on:

http://pastebin.com/49SU8Mm2 - Output from terminal
http://codepad.org/2RO2iS4O - Script, confirming behavior (except for re.subn(), which is different on 2.5)

----------
components: Regular Expressions
messages: 168909
nosy: eacousineau, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.sub() with re.MULTILINE not replacing all occurrences
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug 23 03:35:09 2012
From: report at bugs.python.org (Brian Turek)
Date: Thu, 23 Aug 2012 01:35:09 +0000
Subject: [New-bugs-announce] [issue15769] urllib.request.urlopen with cafile
	or capath set	overrides any previous Handlers
Message-ID: <1345685709.12.0.30740709281.issue15769@psf.upfronthosting.co.za>


New submission from Brian Turek:

Using the code snippet below:

cj = http.cookiejar.CookieJar()
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor())
urllib.request.install_opener(opener)
request = urllib.request.Request(url, data, headers) # url is https://something
sock = urllib.request.urlopen(request, cafile = 'cacert.pem')

One would expect to establish a verified HTTPS connection to the host and the cookies stored in the cookie jar.  Unfortunately urllib.request.urlopen, when called with cafile or capath set, calls urllib.request.build_opener without HTTPCookieProcessor included in the chain.  This results in never being able to support cookies in a "verified" HTTPS connection.

----------
components: Library (Lib)
messages: 168915
nosy: caligatio
priority: normal
severity: normal
status: open
title: urllib.request.urlopen with cafile or capath set overrides any previous Handlers
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Aug 23 10:07:37 2012
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Aug 2012 08:07:37 +0000
Subject: [New-bugs-announce] [issue15770] _testbuffer.get_contiguous()
	doesn't check input	arguments
Message-ID: <1345709257.81.0.874456644745.issue15770@psf.upfronthosting.co.za>


New submission from STINNER Victor:

_testbuffer.get_contiguous() abort with an assertion error if it gets invalid arguments. Attached patch adds tests for valid values.

I found this bug using my fuzzer (fusil).

----------
components: Library (Lib)
files: _testbuffer.patch
keywords: patch
messages: 168928
nosy: haypo, skrah
priority: normal
severity: normal
status: open
title: _testbuffer.get_contiguous() doesn't check input arguments
versions: Python 3.3
Added file: http://bugs.python.org/file26968/_testbuffer.patch

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

From report at bugs.python.org  Thu Aug 23 10:27:22 2012
From: report at bugs.python.org (zhuojun)
Date: Thu, 23 Aug 2012 08:27:22 +0000
Subject: [New-bugs-announce] [issue15771] Tunple Bug?
Message-ID: <1345710442.93.0.654191105563.issue15771@psf.upfronthosting.co.za>


New submission from zhuojun:

>>> def f(*agrs):
	print(agrs)

>>> f(1,2)
(1, 2)
>>> f(1) #Is the output wrong? It should be without ','.
(1,)

----------
components: None
messages: 168929
nosy: zhuojun
priority: normal
severity: normal
status: open
title: Tunple Bug?
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Aug 23 22:38:58 2012
From: report at bugs.python.org (Saul Spatz)
Date: Thu, 23 Aug 2012 20:38:58 +0000
Subject: [New-bugs-announce] [issue15772] Unresolved symbols in Windows
	64-bit python
Message-ID: <1345754338.96.0.805254982219.issue15772@psf.upfronthosting.co.za>


New submission from Saul Spatz:

In trying to build a SWING module on Windows with 64-bit python, I get the linker errors listed at the bottom of this message.

I have this problem with both python 2.7 and 3.2.  I have built the project without problems on Windows with 32-bit python, and a correspondent informs me that it cam be built on linux with 64-bit python.

I have listed the exports from python32.lib with dumpbin, and in every case, the symbol after the __imp__ appears in the library without a leading underscore. For example, for the first unresolved symbol, __imp__PyBytes_AsStringAndSize, I find that PyBytes_AsStringAndSize appears in the library.  Of 1074 exports in the library, 891 do not have leading underscores, and the remainder do.  In the 32-bit library, every export starts with an underscore.   

This is obviously related to issues 15165 and 14286, but I hope this additional information will help locate the trouble.  I am running windows 7 professional, and I installed python by downloading and running the installer with all the defaults.

1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyBytes_AsStringAndSize referenced in function _SWIG_Python_str_AsChar
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyUnicodeUCS2_AsUTF8String referenced in function _SWIG_Python_str_AsChar
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyUnicodeUCS2_FromString referenced in function _SWIG_Python_str_FromChar
1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_RuntimeError
1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_AttributeError
1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_SystemError
1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_ValueError
1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_SyntaxError
1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_OverflowError
1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_ZeroDivisionError
1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_TypeError
1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_IndexError
1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_IOError
1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_MemoryError
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyInstanceMethod_New referenced in function _SWIG_PyInstanceMethod_New
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyErr_SetString referenced in function _SWIG_Python_SetErrorMsg
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__Py_BuildValue referenced in function __SWIG_Py_None
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyLong_FromVoidPtr referenced in function _SwigPyObject_long
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__Py_DecRef referenced in function _SwigPyObject_repr
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyUnicodeUCS2_Concat referenced in function _SwigPyObject_repr
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyUnicodeUCS2_FromFormat referenced in function _SwigPyObject_repr
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyBool_FromLong referenced in function _SwigPyObject_richcompare
1>example_wrap.obj : error LNK2001: unresolved external symbol __imp___Py_NotImplementedStruct
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyObject_Free referenced in function _SwigPyObject_dealloc
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyObject_CallFunctionObjArgs referenced in function _SwigPyObject_dealloc
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyObject_IsTrue referenced in function _SwigPyObject_own
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyArg_UnpackTuple referenced in function _SwigPyObject_own
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyType_Ready referenced in function _SwigPyObject_TypeOnce
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyObject_GenericGetAttr referenced in function _SwigPyObject_TypeOnce
1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyBaseObject_Type
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyObject_SetAttr referenced in function _SWIG_Python_NewShadowInstance
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyObject_Call referenced in function _SWIG_Python_NewShadowInstance
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyErr_Clear referenced in function _SWIG_Python_GetModule
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyErr_Occurred referenced in function _SWIG_Python_GetModule
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyCapsule_Import referenced in function _SWIG_Python_GetModule
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyCapsule_GetPointer referenced in function _SWIG_Python_DestroyModule
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyModule_AddObject referenced in function _SWIG_Python_SetModule
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyCapsule_New referenced in function _SWIG_Python_SetModule
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyImport_AddModule referenced in function _SWIG_Python_SetModule
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyFloat_AsDouble referenced in function _SWIG_AsVal_double
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyLong_AsLong referenced in function _SWIG_AsVal_double
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyType_IsSubtype referenced in function _SWIG_AsVal_double
1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyFloat_Type
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyLong_FromLong referenced in function _SWIG_From_int
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyArg_ParseTuple referenced in function __wrap_gcd
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyFloat_FromDouble referenced in function _Swig_var_Foo_get
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyUnicode_InternFromString referenced in function _swig_varlink_repr
1>example_wrap.obj : error LNK2001: unresolved external symbol __imp__PyExc_NameError
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyObject_Init referenced in function _SWIG_Python_newvarlink
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyObject_Malloc referenced in function _SWIG_Python_newvarlink
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp___PyObject_New referenced in function _SWIG_Python_NewPointerObj
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyDict_SetItemString referenced in function _SWIG_Python_InstallConstants
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyModule_GetDict referenced in function _PyInit__example
1>example_wrap.obj : error LNK2019: unresolved external symbol __imp__PyModule_Create2 referenced in function _PyInit__example

----------
components: Windows
messages: 168964
nosy: spatz123
priority: normal
severity: normal
status: open
title: Unresolved symbols in Windows 64-bit python
type: compile error
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Aug 24 01:35:07 2012
From: report at bugs.python.org (Stefan Mihaila)
Date: Thu, 23 Aug 2012 23:35:07 +0000
Subject: [New-bugs-announce] [issue15773] `is' operator returns False on
	classmethods
Message-ID: <1345764907.85.0.74641370486.issue15773@psf.upfronthosting.co.za>


New submission from Stefan Mihaila:

Here are a few counter-intuitive outputs:

    >>> dict.fromkeys is dict.fromkeys
    False

    >>> id(dict.fromkeys) == id(dict.fromkeys)
    True

    >>> x=dict.fromkeys; id(x) == id(x)
    True

    >>> x=dict.fromkeys; id(x) == id(dict.fromkeys)
    False
    
    >>> x=dict.fromkeys; y=dict.fromkeys; id(x),id(y),id(dict.fromkeys)
    (39888824, 39064632, 39065144)

    >>> a=id(dict.fromkeys); x=dict.fromkeys; b=id(dict.fromkeys); a,b
    (39888824, 39480568)

Attached is a failing test.

----------
files: is_on_classmethods.py
messages: 168967
nosy: mstefanro
priority: normal
severity: normal
status: open
title: `is' operator returns False on classmethods
versions: Python 3.3
Added file: http://bugs.python.org/file26978/is_on_classmethods.py

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

From report at bugs.python.org  Fri Aug 24 02:52:19 2012
From: report at bugs.python.org (mesheb82)
Date: Fri, 24 Aug 2012 00:52:19 +0000
Subject: [New-bugs-announce] [issue15774] String method title() produces
	incorrect resutls
Message-ID: <1345769539.02.0.287191314572.issue15774@psf.upfronthosting.co.za>


New submission from mesheb82:

I got unexpected results when working with a string that has an apostrophe in it.
"Joe's".title()
>> "Joe'S"

'Joe"s'.title()
>> 'Joe"S'

----------
components: Interpreter Core
messages: 168969
nosy: mesheb82
priority: normal
severity: normal
status: open
title: String method title() produces incorrect resutls
versions: Python 2.6

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

From report at bugs.python.org  Fri Aug 24 10:18:17 2012
From: report at bugs.python.org (=?utf-8?q?Nemeskey_D=C3=A1vid?=)
Date: Fri, 24 Aug 2012 08:18:17 +0000
Subject: [New-bugs-announce] [issue15775] Add StopParser() to expat
Message-ID: <1345796297.89.0.127411549702.issue15775@psf.upfronthosting.co.za>


New submission from Nemeskey D?vid:

The C expat library provides XML_StopParser() method that allows the parsing to be stopped from the handler functions. It would be nice to have this option in Python as well, maybe by adding StopParser() method to the XMLParser class.

----------
components: XML
messages: 168980
nosy: nemeskeyd
priority: normal
severity: normal
status: open
title: Add StopParser() to expat
type: enhancement

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

From report at bugs.python.org  Fri Aug 24 11:15:46 2012
From: report at bugs.python.org (Stefan Holek)
Date: Fri, 24 Aug 2012 09:15:46 +0000
Subject: [New-bugs-announce] [issue15776] Allow pyvenv to work in existing
	directory
Message-ID: <1345799746.88.0.728928529816.issue15776@psf.upfronthosting.co.za>


New submission from Stefan Holek:

With virtualenv I can do

    $ virtualenv .

but with pyvenv I get

    $pyvenv .
    Error: Directory exists: /Users/stefan/sandbox/foo

Please allow pyvenv to apply to existing directories.

----------
components: None
messages: 168990
nosy: stefanholek
priority: normal
severity: normal
status: open
title: Allow pyvenv to work in existing directory
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Aug 24 12:13:15 2012
From: report at bugs.python.org (Ross Lagerwall)
Date: Fri, 24 Aug 2012 10:13:15 +0000
Subject: [New-bugs-announce] [issue15777] test_capi refleak
Message-ID: <1345803195.05.0.615891441008.issue15777@psf.upfronthosting.co.za>


New submission from Ross Lagerwall:

results for fa745ed89b7a on branch "default"
--------------------------------------------

test_capi leaked [2, 2, 2] references, sum=6


Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R', '3:3:/home/antoine/cpython/refleaks/reflogEr4Oyp', '-x']


A fix is in progress...

----------
assignee: rosslagerwall
messages: 168993
nosy: rosslagerwall
priority: normal
severity: normal
stage: needs patch
status: open
title: test_capi refleak
type: resource usage
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Aug 24 18:38:45 2012
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 24 Aug 2012 16:38:45 +0000
Subject: [New-bugs-announce] [issue15778] str(ImportError(b'foo')) fails
Message-ID: <1345826325.41.0.0972765515738.issue15778@psf.upfronthosting.co.za>


New submission from Dave Malcolm:

In Python 3.2 and earlier:
>>> str(ImportError(b'foo'))
"b'foo'"

In Python 3.3:
>>> str(ImportError(b'foo'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __str__ returned non-string (type bytes)

This appears to be due to commit 76272.

I'm attaching a patch which fixes it, though perhaps ImportError should type-check the arguments

Motivation:
This leads to a failure of the test suite for "docutils" when run under Python 3.3 betas, specifically:

======================================================================
ERROR: test_unicode (test_error_reporting.ErrorStringTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/david/coding/python3.3/docutils/trunk/docutils/test3/test_error_reporting.py", line 154, in test_unicode
str(ErrorString(ImportError(self.bs))))
File "/home/david/coding/python3.3/docutils/trunk/docutils/build/lib/docutils/utils/error_reporting.py", line 124, in __str__
super(ErrorString, self).__str__())
File "/home/david/coding/python3.3/docutils/trunk/docutils/build/lib/docutils/utils/error_reporting.py", line 74, in __str__
return str(self.data)
TypeError: __str__ returned non-string (type bytes)

See http://docutils.svn.sourceforge.net/viewvc/docutils/trunk/docutils/test/test_error_reporting.py?revision=7464&view=markup for the test code.  Arguably docutils could just pick a different exception subclass.

----------
messages: 169042
nosy: brett.cannon, dmalcolm
priority: normal
severity: normal
status: open
title: str(ImportError(b'foo')) fails
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Aug 24 19:42:16 2012
From: report at bugs.python.org (James Hutchison)
Date: Fri, 24 Aug 2012 17:42:16 +0000
Subject: [New-bugs-announce] [issue15779] socket error [Errno 10013] when
	creating SMTP object
Message-ID: <1345830136.59.0.644251371515.issue15779@psf.upfronthosting.co.za>


New submission from James Hutchison:

Windows 7 64-bit, Python 3.2.3

This is a very odd issue and I haven't figured out what caused it. I have a python script that runs continuously. When it receives a request to do a task, it creates a new thread (not a new process), does the task, then sends out an e-mail to indicate it was done. It doesn't do this a lot (maybe 10 - 30 times a day). This is all the script does.

Well today, it randomly broke. It was working fine, then suddenly I was getting the following error when it would create an SMTP object:

socket.error: [Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions

What I found was, even after trying a different script that did nothing but create a simple SMTP connection to localhost, running with admin privileges, and even after rebooting the machine, I was getting this error. I checked my firewall and didn't see any changes (I share a group policy so I do not have full control). I also tried the script on a different machine and found no issue. The issue also persisted between IDLE and simply running python.exe

When I tried to debug the issue, I discovered the following piece of code made the issue go away:

s = socket.socket()
s.bind(('',50007))
s.listen(1);
s.close();

And it hasn't come back since. I've tried to reproduce the circumstances that my script was running by creating SMTP instances in a loop but haven't been able to recreate the error. Checking my log, there isn't anything abnormal that occurred just before this issue (like attempting to do the task several times at once or something).

----------
components: Library (Lib)
messages: 169055
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: socket error [Errno 10013] when creating SMTP object
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Fri Aug 24 22:44:45 2012
From: report at bugs.python.org (James Hutchison)
Date: Fri, 24 Aug 2012 20:44:45 +0000
Subject: [New-bugs-announce] [issue15780] IDLE (windows) with PYTHONPATH and
	multiple python	versions
Message-ID: <1345841085.37.0.939660475067.issue15780@psf.upfronthosting.co.za>


New submission from James Hutchison:

One issue I've encountered is someone else's software setting PYTHONPATH to their install directory of python. We have some old software that installs and uses python 2.3 scripts and unfortunately this prevents the IDLE shortcuts for newer versions of python from working correctly on the system. This could be remedied with -E being added to the shortcut, but windows doesn't allow me to directly edit the IDLE shortcut, and it hides how IDLE is being launched via Python in the first place, making it a challenge to create my own. I'd remove PYTHONPATH from the system environment variables except I don't know why it's set in the first place.

Suggestion: IDLE safe-mode which runs with -E OR include a batch file for IDLE so that I can easily append my own command line arguments and create my own shortcuts.

----------
components: IDLE
messages: 169082
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: IDLE (windows) with PYTHONPATH and multiple python versions
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Aug 25 10:33:40 2012
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 25 Aug 2012 08:33:40 +0000
Subject: [New-bugs-announce] [issue15781] test_threaded_import fails on
	Windows
Message-ID: <1345883620.41.0.296577026972.issue15781@psf.upfronthosting.co.za>


New submission from Stefan Krah:

test_parallel_module_init() fails on Windows-64:

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/553/steps/test/logs/stdio

======================================================================
FAIL: test_parallel_module_init (test.test_threaded_import.ThreadedImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_threaded_import.py", line 125, in test_parallel_module_init
    self.check_parallel_module_init()
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_threaded_import.py", line 120, in check_parallel_module_init
    self.assertFalse(errors)
AssertionError: [AttributeError("'module' object has no attribute 'randrange'",)] is not false

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

----------
components: Tests
messages: 169116
nosy: brett.cannon, haypo, jkloth, pitrou, skrah
priority: normal
severity: normal
status: open
title: test_threaded_import fails on Windows
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Aug 25 12:05:30 2012
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 25 Aug 2012 10:05:30 +0000
Subject: [New-bugs-announce] [issue15782] Compile error for a number of Mac
	modules with recent	Xcode
Message-ID: <1345889130.68.0.165099119682.issue15782@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

Recent versions of Xcode on OSX 10.7 and 10.8 fail to compile 3 of the extension modules in Mac/Modules: the modules for fm, qd and qdoffs.

That's because those extensions wrap APIs that are long deprecated and are no longer present.

The attached patch "fixes" the miscompilation by making most of the body of the extension empty when compiling with the 10.7 (or later) SDK.

This changes the API of these extension modules, but that cannot be helped because the platform APIs that are wrapped by these extensions are no longer present.

(Patch is not relevant for python 3.x because these extensions have been removed in python 3.0)

----------
assignee: ronaldoussoren
components: Build, Macintosh
files: miscompile-mac-modules.txt
keywords: needs review
messages: 169123
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: patch review
status: open
title: Compile error for a number of Mac modules with recent Xcode
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file26993/miscompile-mac-modules.txt

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

From report at bugs.python.org  Sat Aug 25 16:24:43 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 25 Aug 2012 14:24:43 +0000
Subject: [New-bugs-announce] [issue15783] decimal.localcontext(None) fails
	when using the C	accelerator module
Message-ID: <1345904683.65.0.863127291798.issue15783@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

decimal.localcontext() works correctly with both the pure Python decimal module and the C accelerator.

decimal.localcontext(None) only works with the pure Python version. The C accelerator throws an exception instead of treating it as equivalent to omitting the argument.

----------
keywords: 3.3regression
messages: 169135
nosy: ncoghlan, skrah
priority: normal
severity: normal
stage: test needed
status: open
title: decimal.localcontext(None) fails when using the C accelerator module
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Aug 25 20:44:37 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sat, 25 Aug 2012 18:44:37 +0000
Subject: [New-bugs-announce] [issue15784] OSError.__str__() should
	distinguish between errno and	winerror
Message-ID: <1345920277.5.0.279969365859.issue15784@psf.upfronthosting.co.za>


New submission from Richard Oudkerk:

Since WindowsError became an alias of OSError, the error number shown in the stringification of an OSError err can either be a windows error code (err.winerror) or a posix style error number (err.errno), with no way to tell which.

For instance in

  >>> os.read(999, 0)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  OSError: [Errno 9] Bad file descriptor

err.errno == EBADF == 9 and err.winerror == None, but in

  >>> _winapi.ReadFile(999, 0)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  OSError: [Error 6] The handle is invalid

err.errno == EBADF == 9 and err.winerror == ERROR_INVALID_HANDLE == 6.  (winerror gets priority over errno if it exists.)

With the attached patch the second will be shown as

  >>> _winapi.ReadFile(999, 0)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  OSError: [WinError 6] The handle is invalid
            ^^^

Since this issue only applies to 3.3 and the patch is trivial, it would be nice to get this in before 3.3 is released.

----------
files: winerror.patch
keywords: patch
messages: 169153
nosy: pitrou, sbt
priority: normal
severity: normal
status: open
title: OSError.__str__() should distinguish between errno and winerror
Added file: http://bugs.python.org/file27001/winerror.patch

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

From report at bugs.python.org  Sun Aug 26 12:09:38 2012
From: report at bugs.python.org (Adam Simpkins)
Date: Sun, 26 Aug 2012 10:09:38 +0000
Subject: [New-bugs-announce] [issue15785] curses.get_wch() returns keypad
	codes incorrectly
Message-ID: <1345975778.97.0.705241878581.issue15785@psf.upfronthosting.co.za>


New submission from Adam Simpkins:

The curses.get_wch() function does not check if wget_wch() returned OK or KEY_CODE_YES.  In either case, it simply returns the character code.

This makes get_wch() unusable when keypad is enabled, because the caller cannot distinguish function key or arrow key presses from real unicode code points.  For example, get_wch() returns 259 both for an up arrow press and for the input character '?'.

It seems like this API needs to be redesigned somehow to allow terminal keypad codes to be distinguished from unicode input.

----------
components: Library (Lib)
messages: 169165
nosy: simpkins
priority: normal
severity: normal
status: open
title: curses.get_wch() returns keypad codes incorrectly
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Aug 27 02:35:01 2012
From: report at bugs.python.org (suddha sourav)
Date: Mon, 27 Aug 2012 00:35:01 +0000
Subject: [New-bugs-announce] [issue15786] IDLE code completion window does
	not scoll/select with	mouse
Message-ID: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za>


New submission from suddha sourav:

In IDLE, pressing tab brings up the code completion menu - however, the scrollbar, when clicked, does not scroll - it disappears. Same goes for clicking an option in the code completion widget - it disappears. Keyboard navigation (pgup/pgdown/up/down) and tab works. In addition, pressing enter does not autocomplete but execute what was meant to be selected.

----------
components: IDLE
messages: 169175
nosy: suddha.sourav
priority: normal
severity: normal
status: open
title: IDLE code completion window does not scoll/select with mouse
versions: Python 2.7

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

From report at bugs.python.org  Mon Aug 27 05:36:05 2012
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 27 Aug 2012 03:36:05 +0000
Subject: [New-bugs-announce] [issue15787] PEP 3121 Refactoring
Message-ID: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

This is a meta-issue to keep track of a global PEP 3121 refactoring effort.  Per-module issues will be added as dependencies. Let's move the discussion that is not specific to any particular module here.

----------
components: Extension Modules
messages: 169177
nosy: Robin.Schreiber, belopolsky
priority: normal
severity: normal
status: open
title: PEP 3121 Refactoring
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug 27 08:46:20 2012
From: report at bugs.python.org (Chris Rebert)
Date: Mon, 27 Aug 2012 06:46:20 +0000
Subject: [New-bugs-announce] [issue15788] cross-refs in the
	subprocess.Popen.std{in, out, err} warning box aren't linked
Message-ID: <1346049980.8.0.0439689816925.issue15788@psf.upfronthosting.co.za>


New submission from Chris Rebert:

The cross-references, particularly to Popen.communicate(), in the warning box in the subprocess docs about using Popen.stdout.read() etc. aren't hyperlinked. The attached patch fixes that.

----------
assignee: docs at python
components: Documentation
files: link_communicate_warning.patch
keywords: patch
messages: 169182
nosy: cvrebert, docs at python
priority: normal
severity: normal
status: open
title: cross-refs in the subprocess.Popen.std{in,out,err} warning box aren't linked
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27010/link_communicate_warning.patch

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

From report at bugs.python.org  Mon Aug 27 09:24:02 2012
From: report at bugs.python.org (Chris Rebert)
Date: Mon, 27 Aug 2012 07:24:02 +0000
Subject: [New-bugs-announce] [issue15789] mention shell-like parts of the
	std lib in the	subprocess docs
Message-ID: <1346052242.66.0.254880477781.issue15789@psf.upfronthosting.co.za>


New submission from Chris Rebert:

To further dissuade people from using subprocess.Popen's shell=True option unnecessarily, this patch points out that some common shell features are also available directly in Python via certain modules & functions.

----------
assignee: docs at python
components: Documentation
files: subprocess.rst.patch
keywords: patch
messages: 169188
nosy: cvrebert, docs at python
priority: normal
severity: normal
status: open
title: mention shell-like parts of the std lib in the subprocess docs
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27013/subprocess.rst.patch

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

From report at bugs.python.org  Mon Aug 27 13:41:37 2012
From: report at bugs.python.org (Pas)
Date: Mon, 27 Aug 2012 11:41:37 +0000
Subject: [New-bugs-announce] [issue15790] Python 3.3.0rc1 release notes
	claims PEP-405 support,
	yet pysetup is not in the package (needs more usage documentation,
	to get pip working)
Message-ID: <1346067697.02.0.646215299942.issue15790@psf.upfronthosting.co.za>


New submission from Pas:

Python 3.3.0rc1 release notes ( http://python.org/download/releases/3.3.0/ ) claims PEP-405 support, yet pysetup is not in the tarball. (After reading through mailing lists and bugs it's clear that the move to "packaging" module got pulled, so it's still just distutils in there.)

There is no documentation on how to get a pyvenv (or virtualenv, or any other virtual enviroment solution) built venv to gain setuptools/pip support.

----------
assignee: docs at python
components: Documentation
messages: 169194
nosy: docs at python, pas
priority: normal
severity: normal
status: open
title: Python 3.3.0rc1 release notes claims PEP-405 support, yet pysetup is not in the package (needs more usage documentation, to get pip working)
versions: Python 3.3

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

From report at bugs.python.org  Mon Aug 27 14:28:43 2012
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Mon, 27 Aug 2012 12:28:43 +0000
Subject: [New-bugs-announce] [issue15791] pydoc does not handle unicode
	AUTHOR field
Message-ID: <1346070523.56.0.605519792769.issue15791@psf.upfronthosting.co.za>


New submission from Michele Orr?:

$ echo "__author__ = u'Michele Orr\xf9'" > foo.py && python -c "import foo; print foo.__author__; help(foo)"
Michele Orr?
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site.py", line 467, in __call__
    return pydoc.help(*args, **kwds)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1747, in __call__
    self.help(request)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1794, in help
    else: doc(request, 'Help on %s:')
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1531, in doc
    pager(render_doc(thing, title, forceload))
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1526, in render_doc
    return title % desc + '\n\n' + text.document(object, name)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 329, in document
    if inspect.ismodule(object): return self.docmodule(*args)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pydoc.py", line 1126, in docmodule
    result = result + self.section('AUTHOR', str(object.__author__))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xf9' in position 11: ordinal not in range(128)

----------
components: Unicode
messages: 169196
nosy: eric.araujo, ezio.melotti, maker
priority: normal
severity: normal
status: open
title: pydoc does not handle unicode AUTHOR field
type: crash
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Mon Aug 27 16:17:31 2012
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 27 Aug 2012 14:17:31 +0000
Subject: [New-bugs-announce] [issue15792] Fix compiler options for x64
	builds on Windows
Message-ID: <1346077051.29.0.85020459134.issue15792@psf.upfronthosting.co.za>


New submission from Jeremy Kloth:

The attached patch fixes the compiler options used for building the x64 platform.

- In VC10 the passing /GS- as an additional option has been replaced by the MSBuild BufferSecurityCheck command
- The /USECL:xxx option is only for the VSExtComp plugin for VS.NET 2003 (VC7.1) used to build a 64-bit Python 2.5

The attached patch modifies the x64 properties for VS8/9/10.

----------
components: Build
files: pcbuild.diff
keywords: patch
messages: 169200
nosy: jkloth
priority: normal
severity: normal
status: open
title: Fix compiler options for x64 builds on Windows
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27015/pcbuild.diff

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

From report at bugs.python.org  Mon Aug 27 23:17:20 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Aug 2012 21:17:20 +0000
Subject: [New-bugs-announce] [issue15793] Stack corruption in ssl.RAND_egd()
Message-ID: <1346102240.18.0.678395188074.issue15793@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch that fixes stack corruption in ssl.RAND_egd().

----------
components: Library (Lib)
files: ssl_RAND_egd.patch
keywords: patch
messages: 169221
nosy: haypo, storchaka
priority: normal
severity: normal
status: open
title: Stack corruption in ssl.RAND_egd()
type: crash
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27020/ssl_RAND_egd.patch

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

From report at bugs.python.org  Tue Aug 28 00:35:01 2012
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 27 Aug 2012 22:35:01 +0000
Subject: [New-bugs-announce] [issue15794] test_importlib: test_locks failure
Message-ID: <1346106901.9.0.610184889675.issue15794@psf.upfronthosting.co.za>


New submission from Stefan Krah:

On the obstinate i7 machine (see #15781), test_importlib fails
sporadically (after 10 repetitions or so).

$ ./python -m test -uall -F test_importlib                                                               
[  1] test_importlib                                                                                     
test test_importlib failed -- Traceback (most recent call last):                                         
  File "/home/stefan/hg/cpython/Lib/test/test_importlib/test_locks.py", line 80, in test_deadlock        
    self.assertEqual(results.count((True, False)), 1)                                                    
AssertionError: 2 != 1                                                                                   
                                                                                                         
1 test failed:                                                                                           
    test_importlib

----------
components: Tests
messages: 169232
nosy: brett.cannon, christian.heimes, eric.snow, georg.brandl, haypo, ncoghlan, pitrou, skrah
priority: normal
severity: normal
status: open
title: test_importlib: test_locks failure
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Aug 28 00:36:04 2012
From: report at bugs.python.org (Alexey Boriskin)
Date: Mon, 27 Aug 2012 22:36:04 +0000
Subject: [New-bugs-announce] [issue15795] Zipfile.extractall does not
	preserve file permissions
Message-ID: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za>


New submission from Alexey Boriskin:

Zipfile._extract_member does not preserve file permissions while extracting it. As may be seen at link[1], raw open() is used and no os.chmod() applied after that, therefore any permission data stored in zipfile is dropped and file is created with default permission depending on current user's umask.

[1] http://hg.python.org/cpython/file/52159aa5d401/Lib/zipfile.py#l1251

----------
components: Library (Lib)
messages: 169233
nosy: uruz
priority: normal
severity: normal
status: open
title: Zipfile.extractall does not preserve file permissions
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Tue Aug 28 00:43:57 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Aug 2012 22:43:57 +0000
Subject: [New-bugs-announce] [issue15796] Fix readline() docstrings
Message-ID: <1346107437.01.0.760856446484.issue15796@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch that escapes '\n' in readline() docstrings.

----------
assignee: docs at python
components: Documentation
files: escape_nl.patch
keywords: patch
messages: 169235
nosy: docs at python, storchaka
priority: normal
severity: normal
status: open
title: Fix readline() docstrings
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27021/escape_nl.patch

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

From report at bugs.python.org  Tue Aug 28 11:51:12 2012
From: report at bugs.python.org (B Maqueira)
Date: Tue, 28 Aug 2012 09:51:12 +0000
Subject: [New-bugs-announce] [issue15797] bdist_msi does not pass
	-install/remove flags to	install_script
Message-ID: <1346147472.01.0.0635028414042.issue15797@psf.upfronthosting.co.za>


New submission from B Maqueira:

When building an msi package using the --install-script=xx.py, the script "xx.py" is called on msi package install/removal as expected. However the cmd line flags -install/-remove are not passed to the script making it hard to write "step specific" code. 

I experienced this under python 2.7.3 (winXP / distutils 2.7.3, setuptools 0.6c11).

I attach a patch for bdist_msi.py for your consideration.

Kind regards,

Braudel

----------
assignee: eric.araujo
components: Distutils
files: patch.diff
keywords: patch
messages: 169262
nosy: braudel, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: bdist_msi does not pass -install/remove flags to install_script
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file27031/patch.diff

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

From report at bugs.python.org  Tue Aug 28 15:03:50 2012
From: report at bugs.python.org (Aleksey Filippov)
Date: Tue, 28 Aug 2012 13:03:50 +0000
Subject: [New-bugs-announce] [issue15798] subprocess.Popen() fails if 0,
	1 or 2 descriptor is closed
Message-ID: <1346159030.18.0.947370235022.issue15798@psf.upfronthosting.co.za>


New submission from Aleksey Filippov:

System info:
kernel: 3.4.8-1-ARCH
dist: Arch linux
python: 3.2.3

subprocess.Popen() fails if python interpreter is started with closed 0, 1 or 2 descriptor.

Traceback (most recent call last):
  File "<string>", line 14, in <module>
  File "/usr/lib/python3.2/subprocess.py", line 745, in __init__
    restore_signals, start_new_session)
  File "/usr/lib/python3.2/subprocess.py", line 1197, in _execute_child
    restore_signals, start_new_session, preexec_fn)
ValueError: errpipe_write must be >= 3

----------
messages: 169276
nosy: sarum9in
priority: normal
severity: normal
status: open
title: subprocess.Popen() fails if 0, 1 or 2 descriptor is closed
versions: Python 3.2

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

From report at bugs.python.org  Tue Aug 28 22:31:31 2012
From: report at bugs.python.org (karl)
Date: Tue, 28 Aug 2012 20:31:31 +0000
Subject: [New-bugs-announce] [issue15799] httplib client and statusline
Message-ID: <1346185891.22.0.123491218752.issue15799@psf.upfronthosting.co.za>


New submission from karl:

The current parsing of HTTP status line seems strange with regards to its definition in HTTP.

http://hg.python.org/cpython/file/3.2/Lib/http/client.py#l307

Currently the code is 
version, status, reason = line.split(None, 2)

>>> status1 = "HTTP/1.1 200 OK"
>>> status2 = "HTTP/1.1 200 "
>>> status3 = "HTTP/1.1 200"
>>> status1.split(None, 2)
['HTTP/1.1', '200', 'OK']
>>> status2.split(None, 2)
['HTTP/1.1', '200']
>>> status3.split(None, 2)
['HTTP/1.1', '200']

According to the production rules of HTTP/1.1 bis only status1 and status2 are valid.

  status-line = HTTP-version SP status-code SP reason-phrase CRLF
  ? http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-20#section-3.1.2

with reason-phrase  = *( HTAB / SP / VCHAR / obs-text ) aka 0 or more characters.

I'm also not sure what are the expected ValueError with additional parsing rules which seems even more bogus.

First modification should be

>>> status1.split(' ', 2)
['HTTP/1.1', '200', 'OK']
>>> status2.split(' ', 2)
['HTTP/1.1', '200', '']

Which would be correct for the first two, with an empty reason-phrase
The third one is still no good.

>>> status3.split(' ', 2)
['HTTP/1.1', '200']

An additional check could be done with 

len(status.split(' ', 2)) == 3

Will return False in the third case.

Do you want me to create a patch and a test for it?

----------
messages: 169293
nosy: karlcow
priority: normal
severity: normal
status: open
title: httplib client and statusline
type: enhancement
versions: Python 3.2

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

From report at bugs.python.org  Tue Aug 28 22:52:06 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Aug 2012 20:52:06 +0000
Subject: [New-bugs-announce] [issue15800] Closing of sys.std* files in gzip
	test.
Message-ID: <1346187126.27.0.0616133533378.issue15800@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When porting gzip module from Python 2 to Python 3, binary files sys.std(in|out) was replaced by sys.std(in|out).buffer in gzip module internal testing code (when gzip used as executable). But in one place the replacement was skipped. As the result the condition now always true and standard files are closed after use.

Here is a patch that fixes this error.

----------
components: Library (Lib)
files: gzip_main_close.patch
keywords: patch
messages: 169296
nosy: pitrou, storchaka
priority: low
severity: normal
status: open
title: Closing of sys.std* files in gzip test.
type: resource usage
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27035/gzip_main_close.patch

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

From report at bugs.python.org  Tue Aug 28 23:06:22 2012
From: report at bugs.python.org (Erik Allik)
Date: Tue, 28 Aug 2012 21:06:22 +0000
Subject: [New-bugs-announce] [issue15801] Weird string interpolation
	behaviour
Message-ID: <1346187982.17.0.733777939563.issue15801@psf.upfronthosting.co.za>


New submission from Erik Allik:

>>> class Foo(object):
...     pass
... 
>>> "asdads" % Foo()
'asdads'


Doesn't look like it's supposed to be this way.

As per the documentation:

"If format requires a single argument, values may be a single non-tuple object. [5] Otherwise, values must be a tuple with exactly the number of items specified by the format string, or a single mapping object (for example, a dictionary)."

Tested and confirmed on 2.5, 2.6, 2.7 (both old and new style classes) and 3.2.

----------
messages: 169300
nosy: eallik
priority: normal
severity: normal
status: open
title: Weird string interpolation behaviour
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Aug 28 23:50:08 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Aug 2012 21:50:08 +0000
Subject: [New-bugs-announce] [issue15802] Illegal test for mailbox
Message-ID: <1346190608.89.0.55767676189.issue15802@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Test for mailbox contains meaningless asserts. Here is a patch that corrects testing, if I correctly understand it.

----------
components: Tests
files: test_mailbox_create_tmp.patch
keywords: patch
messages: 169307
nosy: akuchling, barry, r.david.murray, storchaka
priority: normal
severity: normal
status: open
title: Illegal test for mailbox
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27036/test_mailbox_create_tmp.patch

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

From report at bugs.python.org  Wed Aug 29 03:12:25 2012
From: report at bugs.python.org (Nathan Trapuzzano)
Date: Wed, 29 Aug 2012 01:12:25 +0000
Subject: [New-bugs-announce] [issue15803] Incorrect docstring on
	ConfigParser.items()
Message-ID: <1346202745.06.0.103510250689.issue15803@psf.upfronthosting.co.za>


New submission from Nathan Trapuzzano:

The docstring on ConfigParser.items() is self-evidently bass ackwards. Fix is in attached patch.

----------
components: Library (Lib)
files: cpython.patch
keywords: patch
messages: 169324
nosy: nbtrap
priority: normal
severity: normal
status: open
title: Incorrect docstring on ConfigParser.items()
type: enhancement
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file27041/cpython.patch

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

From report at bugs.python.org  Wed Aug 29 03:37:16 2012
From: report at bugs.python.org (gd2shoe)
Date: Wed, 29 Aug 2012 01:37:16 +0000
Subject: [New-bugs-announce] [issue15804] Feature request,
	implicit "except : pass"
Message-ID: <1346204236.32.0.579082427996.issue15804@psf.upfronthosting.co.za>


New submission from gd2shoe:

I'm constantly finding myself writing itty-bitty try blocks like such:

process stuff
try : someSubProcess.kill()
except : pass
process stuff

I realize this isn't a rigorous use of except, but it's good enough for a vast majority of what I need it for.  Still, it adds excess verbiage and makes code slightly harder to read.

All I need except to do most of the time is suppress exceptions.  I think the language could be enhanced by making the except clause implicit.

the above would become:

process stuff
try : someSubProcess.kill()
process stuff

The intent remains clear.  The code is cleaner and easier to read.

This does not happen often in rigorous code, but grep does find 3 counts in standard modules and 9 counts in numpy.  I'm certain most prototype code (like mine) would greatly benefit.  (My current 300 line project uses 4 so far.)

----------
components: Interpreter Core
messages: 169326
nosy: gd2shoe
priority: normal
severity: normal
status: open
title: Feature request, implicit "except : pass"
type: enhancement
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Wed Aug 29 06:26:24 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Aug 2012 04:26:24 +0000
Subject: [New-bugs-announce] [issue15805] Add stdout redirection tool to
	contextlib
Message-ID: <1346214384.31.0.130580797931.issue15805@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The technique of temporarily redirecting stdout could be encapsulated in a context manager.

print('This goes to stdout')
with RedirectStdout(sys.stderr):
     print('This goes to stderr')
     print('So does this')
print('This goes to stdout')

The print function already supports redirection but it much be done for every single call to print().  The context manager let's the redirection apply to a batch of statements.

The context manager is also useful with existing tools that don't currently provide output redirection hooks:

   from collections import namedtuple
   with open('model.py', 'w') as module:
       with RedirectStdout(module):
            namedtuple('Person', ['name', 'age', 'email'], verbose=True)


   import dis
   with open('disassembly.txt', 'w') as f:
       with RedirectStdout(f):
            dis.dis(myfunc)


A possible implementation is:

class RedirectStdout:
    ''' Create a context manager for redirecting sys.stdout
        to another file.
    '''
    def __init__(self, new_target):
        self.new_target = new_target

    def __enter__(self):
        self.old_target = sys.stdout
        sys.stdout = self.new_target
        return self

    def __exit__(self, exctype, excinst, exctb):
        sys.stdout = self.old_target

----------
components: Library (Lib)
messages: 169335
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add stdout redirection tool to contextlib
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 29 07:15:15 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Aug 2012 05:15:15 +0000
Subject: [New-bugs-announce] [issue15806] Add context manager for the "try:
	... except: pass"	pattern
Message-ID: <1346217315.31.0.832549559428.issue15806@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

It is a somewhat common pattern to write:

   try:
       do_something()
   except SomeException:
       pass

To search examples in the standard library (or any other code base) use:

    $ egrep -C2 "except( [A-Za-z]+)?:" *py  | grep -C2 "pass"

In the Python2.7 Lib directory alone, we find 213 examples.

I suggest a context manager be added that can ignore specifie exceptions.  Here's a possible implementation:

class Ignore:
    ''' Context manager to ignore particular exceptions'''

    def __init__(self, *ignored_exceptions):
        self.ignored_exceptions = ignored_exceptions

    def __enter__(self):
        return self

    def __exit__(self, exctype, excinst, exctb):
        return exctype in self.ignored_exceptions

The usage would be something like this:

    with Ignore(IndexError, KeyError):
        print(s[t])

Here's a real-world example taken from zipfile.py:

    def _check_zipfile(fp):
        try:
            if _EndRecData(fp):
                return True         # file has correct magic number                                                                        
        except IOError:
            pass
        return False

With Ignore() context manager, the code cleans-up nicely:

    def _check_zipfile(fp):
        with Ignore(IOError):
            return bool(EndRecData(fp))  # file has correct magic number                                                                        
        return False

I think this would make a nice addition to contextlib.

----------
assignee: ncoghlan
messages: 169337
nosy: ncoghlan, rhettinger
priority: low
severity: normal
status: open
title: Add context manager for the "try: ... except: pass" pattern
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 29 12:14:05 2012
From: report at bugs.python.org (Gunnlaugur Thor Briem)
Date: Wed, 29 Aug 2012 10:14:05 +0000
Subject: [New-bugs-announce] [issue15807] Bogus versionchanged note
	in	logging.handlers.MemoryHandler doc
Message-ID: <1346235245.12.0.797988832511.issue15807@psf.upfronthosting.co.za>


New submission from Gunnlaugur Thor Briem:

In logging.handlers.MemoryHandler documentation:

?Changed in version 2.6: credentials was added.?

There's no `credentials` anywhere nearby, and at first glance I can't see anything new in `MemoryHandler` when this was introduced. Presumably the `.. versionchanged::` note just landed there by copy-paste error in 6fb033af9310.

----------
assignee: docs at python
components: Documentation
messages: 169360
nosy: docs at python, gthb
priority: normal
severity: normal
status: open
title: Bogus versionchanged note in logging.handlers.MemoryHandler doc
type: enhancement
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Wed Aug 29 13:23:44 2012
From: report at bugs.python.org (Rostyslav Dzinko)
Date: Wed, 29 Aug 2012 11:23:44 +0000
Subject: [New-bugs-announce] [issue15808] Possibility of setting custom key
	bindings for	"Additional help sources" menu items
Message-ID: <1346239424.4.0.436515008596.issue15808@psf.upfronthosting.co.za>


New submission from Rostyslav Dzinko:

There's a possibility to add additional help sources in IDLE via

    Options -> Configure IDLE... -> General -> Additional Help Sources

Use case:

> If someone wants to download certain version of Python documentation in HTML and specify local "index.html" to be opened by custom menu item which appears the in Help menu.

Problem:

> It's not possible to assign custom hot-key (Options -> Configure IDLE... -> Keys) for such menu items or reassign <F1> to that new menu-item, which actually makes sense when talking in context of the use case specified above.

This use case was taken from real life (stackoverflow site):

http://stackoverflow.com/questions/12174255/linking-offline-documentation-to-idle-linux

----------
components: IDLE
messages: 169365
nosy: Rostyslav.Dzinko
priority: normal
severity: normal
status: open
title: Possibility of setting custom key bindings for "Additional help sources" menu items
type: enhancement
versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Aug 29 14:41:42 2012
From: report at bugs.python.org (alex hartwig)
Date: Wed, 29 Aug 2012 12:41:42 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlMTU4MDldINCh0YLRgNC+0Lo=?=
 =?utf-8?b?0Lgg0LjQtyBJRExFINC/0L7RgdGC0YPQv9Cw0Y7RgiDQsiDQvdC10LLQtdGA?=
 =?utf-8?b?0L3QvtC5INC60L7QtNC40YDQvtCy0LrQtS4=?=
Message-ID: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za>


New submission from alex hartwig:

??? ?? IDLE:
Python 2.7.2+ (default, Oct  4 2011, 20:03:08) 
[GCC 4.6.1] on linux2
Type "copyright", "credits" or "license()" for more information.
>>> import sys
>>> import locale
>>> sys.getdefaultencoding()
'ascii'
>>> locale.getpreferredencoding()
'UTF-8'
>>> s = u'??????? ?????'
>>> print s.encode('utf_8')
? ???????????? ??????????
>>> print s.encode('latin1')
??????? ?????

??? ?? ???????:
>>> import sys
>>> import locale
>>> sys.getdefaultencoding()
'ascii'
>>> locale.getpreferredencoding()
'UTF-8'
>>> s = u'??????? ?????'
>>> print s.encode('utf_8')
??????? ?????

----------
components: IDLE
files: ??????-2012-08-21 10:37:23.png
messages: 169369
nosy: alex.hartwig, asvetlov
priority: normal
severity: normal
status: open
title: ?????? ?? IDLE ????????? ? ???????? ?????????.
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file27044/??????-2012-08-21 10:37:23.png

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

From report at bugs.python.org  Wed Aug 29 15:18:19 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Wed, 29 Aug 2012 13:18:19 +0000
Subject: [New-bugs-announce] [issue15810] assertSequenceEqual should be
	fired when comparing	sequences
Message-ID: <1346246299.41.0.924919509525.issue15810@psf.upfronthosting.co.za>


New submission from Florent Xicluna:

When writing unittest, I noticed that I need to uses assertSequenceEqual explicitly when comparing sequences of different kinds.

If I only use the plain assertEqual, it does not generate pretty diffs.

On second thought, I think it could be fixed in unittest to use assertSequenceEqual when isinstance(arg, (tuple, list)) or isinstance(arg, collections.Sequence) is True.

----------
components: Library (Lib), Tests
messages: 169372
nosy: flox
priority: normal
severity: normal
status: open
title: assertSequenceEqual should be fired when comparing sequences
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Aug 29 15:18:40 2012
From: report at bugs.python.org (David Buxton)
Date: Wed, 29 Aug 2012 13:18:40 +0000
Subject: [New-bugs-announce] [issue15811] ElementTree.write() raises
	TypeError when	xml_declaration = True and encoding is a
	unicode string
Message-ID: <1346246320.04.0.762260786774.issue15811@psf.upfronthosting.co.za>


New submission from David Buxton:

The problem is an inconsistency between the ElementTree.write() method on Python 2 and 3 when xml_declaration is True. For Python 2.7 the encoding argument MUST NOT be a unicode string. For Python 3.2 the encoding argument MUST be a unicode string.

On Python 2.7.3 (ElementTree 1.3.0) you can only use byte strings as the encoding argument when including the xml declaration. If you use a unicode object you get TypeError thrown:


    >>> from xml.etree import ElementTree as ET
    >>> from io import BytesIO
    >>> 
    >>> tree = ET.ElementTree(ET.Element(u'example'))
    >>> tree.write(BytesIO(), xml_declaration=True, encoding='utf-8')
    >>> tree.write(BytesIO(), xml_declaration=True, encoding=u'utf-8')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 813, in write
        write("<?xml version='1.0' encoding='%s'?>\n" % encoding)
    TypeError: 'unicode' does not have the buffer interface


So the encoding argument must be a byte string.

However on Python 3.2.3 (ElementTree 1.3.0) the same argument must be a unicode string. If you pass a byte string in it raises TypeError.

This only happens when you pass in an encoding and xml_declaration=True. This is a (small) problem when writing Py 2/3 compatible code since the version of ElementTree is supposed to be the same.

----------
components: XML
messages: 169373
nosy: David.Buxton
priority: normal
severity: normal
status: open
title: ElementTree.write() raises TypeError when xml_declaration = True and encoding is a unicode string
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug 29 16:54:39 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 29 Aug 2012 14:54:39 +0000
Subject: [New-bugs-announce] [issue15812] inspect.getframeinfo() cannot show
	first line
Message-ID: <1346252079.7.0.669819400342.issue15812@psf.upfronthosting.co.za>


New submission from Richard Oudkerk:

When inspect.getframeinfo() tries to collect lines of context it never shows the first line (unless context is as big as the number of lines in the file).

The relevant code is

        start = lineno - 1 - context//2
        try:
            lines, lnum = findsource(frame)
        except IOError:
            lines = index = None
        else:
-->         start = max(start, 1)
            start = max(0, min(start, len(lines) - context))
            lines = lines[start:start+context]
            index = lineno - 1 - start

I think that

            start = max(start, 1)

should be replaced by

            start = max(start, 0)

For some reason getframeinfo() (and the functions which use it) don't seem to be tested by the testsuite...

----------
messages: 169387
nosy: sbt
priority: normal
severity: normal
status: open
title: inspect.getframeinfo() cannot show first line

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

From report at bugs.python.org  Wed Aug 29 18:08:49 2012
From: report at bugs.python.org (V.E.O)
Date: Wed, 29 Aug 2012 16:08:49 +0000
Subject: [New-bugs-announce] [issue15813] Python function decorator scope
	losing variable
Message-ID: <1346256529.91.0.837970613737.issue15813@psf.upfronthosting.co.za>


New submission from V.E.O:

I just learned python @ decorator, it's cool, but soon I found my modified code coming out weird problems.

def with_wrapper(param1):
    def dummy_wrapper(fn):
        print param1
        param1 = 'new'
        fn(param1)
    return dummy_wrapper

def dummy():
    @with_wrapper('param1')
    def implementation(param2):
        print param2

dummy()



I debug it, it throws out exception at print param1

UnboundLocalError: local variable 'param1' referenced before assignment

If I remove param1 = 'new' this line, without any modify operation(link to new object) on variables from outer scope, this routine might working.

Is it meaning I only have made one copy of outer scope variables, then make modification?
The policy of variable scope towards decorator is different?

----------
components: Interpreter Core
messages: 169389
nosy: V.E.O
priority: normal
severity: normal
status: open
title: Python function decorator scope losing variable
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug 29 19:07:09 2012
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 29 Aug 2012 17:07:09 +0000
Subject: [New-bugs-announce] [issue15814] memoryview: equality-hash invariant
Message-ID: <1346260029.19.0.320505643782.issue15814@psf.upfronthosting.co.za>


New submission from Stefan Krah:

The new PEP-3118 equality definition from #15573 that is based
on element-wise comparisons breaks the equality-hash invariant:

>>> from _testbuffer import ndarray
>>> x = ndarray([1,2,3], shape=[3], format='f')
>>> y = ndarray([1,2,3], shape=[3], format='B')
>>> a = memoryview(x)
>>> b = memoryview(y)
>>> a == b
True
>>> hash(a) == hash(b)
False
>>>

----------
assignee: skrah
messages: 169398
nosy: Arfrever, christian.heimes, georg.brandl, haypo, loewis, mark.dickinson, meador.inge, ncoghlan, pitrou, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: memoryview: equality-hash invariant
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 29 21:24:44 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 29 Aug 2012 19:24:44 +0000
Subject: [New-bugs-announce] [issue15815] Add numerator to ZeroDivisionError
	messages
Message-ID: <1346268284.86.0.294059613354.issue15815@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

I propose that we add 'of ####' to all ZeroDivisionError messagesso it is less necessary to use a debugger to add print statements to recover the information currently tossed away. (I also propose to change denominator from 'zero' to '0', '0.0', '0+0j', as appropriate.) 

>>> 3//0
...
ZeroDivisionError: integer division or modulo by zero

# augment to
ZeroDivisionError: integer division or modulo of 3 by 0

Similarly for

>>> 3 / 0
ZeroDivisionError: division by zero

# perhaps this should be 'true division of 3 by 0'

>>> 3.0 / 0.0
ZeroDivisionError: float division by zero

>>> (3+3j) / (0+0j)
ZeroDivisionError: complex division by zero

In #7482 it was proposed to make float and complex messages same as int message by adding 'or modulo'. I an not sure why not to do that, or if it was just deferred.

Fractions currently print the numerator as part of an invalid numerator / 0 result from *either* construction or division.

>>> from fractions import Fraction as F
>>> F(3, 0)
Traceback (most recent call last):
  File "<pyshell#20>", line 1, in <module>
    F(3, 0)
  File "C:\Programs\Python33\lib\fractions.py", line 167, in __new__
    raise ZeroDivisionError('Fraction(%s, 0)' % numerator)
ZeroDivisionError: Fraction(3, 0)

# Here, 'Fraction(3, 0)' is invalid input.

>>> F(3, 1) / F(0, 1)
Traceback (most recent call last):
  File "<pyshell#19>", line 1, in <module>
    F(3, 1) / F(0, 1)
  File "C:\Programs\Python33\lib\fractions.py", line 367, in forward
    return monomorphic_operator(a, b)
  File "C:\Programs\Python33\lib\fractions.py", line 417, in _div
    a.denominator * b.numerator)
  File "C:\Programs\Python33\lib\fractions.py", line 167, in __new__
    raise ZeroDivisionError('Fraction(%s, 0)' % numerator)
ZeroDivisionError: Fraction(3, 0)

# Here, 'Fraction(3, 0)' is invalid output.
I found this confusing until I worked out the dual meaning. I think

ZeroDevisionError: invalid Fraction(3, 0) from construction or division

might be a bit clearer.

I have not looked at decimals.

----------
components: Interpreter Core
messages: 169410
nosy: ezio.melotti, mark.dickinson, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Add numerator to ZeroDivisionError messages
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 29 21:45:15 2012
From: report at bugs.python.org (David Kreuter)
Date: Wed, 29 Aug 2012 19:45:15 +0000
Subject: [New-bugs-announce] [issue15816] pydoc.py uses a hack that depends
	on implementation	details and breaks help() when
	__builtin__.__import__ is overwritten.
Message-ID: <1346269515.86.0.485633003934.issue15816@psf.upfronthosting.co.za>


New submission from David Kreuter:

help("compile") # this works
import __builtin__
real_import = __import__
__builtin__.__import__ = lambda *a: real_import(*a)
help("compile") # this fails

The line responsible for this is in pydoc.py around line 300:
... elif exc is ImportError and extract_tb(tb)[-1][2]=='safeimport': ...

----------
components: Library (Lib)
messages: 169412
nosy: dkreuter
priority: normal
severity: normal
status: open
title: pydoc.py uses a hack that depends on implementation details and breaks help() when __builtin__.__import__ is overwritten.
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Aug 30 01:33:05 2012
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 29 Aug 2012 23:33:05 +0000
Subject: [New-bugs-announce] [issue15817] Misc/gdbinit: Expose command
	documentation to gdb help
Message-ID: <1346283185.13.0.0954859318202.issue15817@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

Currently "help user-defined" lists commands defined in Misc/gdbinit without explanations


(gdb) help user-defined
User-defined commands.
The commands in this class are those defined by the user.
Use the "define" command to define a command.

List of commands:

lineno -- User-defined
printframe -- User-defined
pu -- User-defined
pyframe -- User-defined
pyframev -- User-defined
pyg -- User-defined

With attached patch, you get


List of commands:

lineno -- User-defined
printframe -- User-defined
pu -- Generally useful macro to print a Unicode string
pyframe -- User-defined
pyframev -- Print the current frame - verbose
pyg -- Prints a representation of the object to stderr
pylocals -- Print the local variables of the current frame
pyo -- Prints a representation of the object to stderr
pystack -- Print the entire Python call stack
pystackv -- Print the entire Python call stack - verbose mode

This should be further polished, but I wanted to hear from others before spending more effort.

----------
components: Demos and Tools
files: gdbinit.diff
keywords: patch
messages: 169424
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Misc/gdbinit: Expose command documentation to gdb help
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file27050/gdbinit.diff

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

From report at bugs.python.org  Thu Aug 30 04:49:48 2012
From: report at bugs.python.org (Josh Kupershmidt)
Date: Thu, 30 Aug 2012 02:49:48 +0000
Subject: [New-bugs-announce] [issue15818] multiprocessing documentation of
	Process.exitcode
Message-ID: <1346294988.32.0.746763914895.issue15818@psf.upfronthosting.co.za>


New submission from Josh Kupershmidt:

[I tried to send this as an email to docs at python.org yesterday, but it seems to have gotten eaten, as I don't see the message in the archives.]

Hi all,

The documentation for the multiprocessing module claims:

| Note that the start(), join(), is_alive() and exit_code methods
| should only be called by the process that created the process object.

Two problems with this description:
 1. "exit_code" should be spelled "exitcode"
 2. exitcode is an attribute of the Process class, not a method as
claimed, since the underlying method is decorated with @property

Also, aside from the above documentation issues, if it is true that
it's not safe to query the exitcode from a separate process, should
the exitcode property method include a check like so:

    assert self._parent_pid == os.getpid(), 'can only test a child process'

since start(), join(), and is_alive() all perform this check?

----------
assignee: docs at python
components: Documentation
messages: 169428
nosy: docs at python, schmiddy
priority: normal
severity: normal
status: open
title: multiprocessing documentation of Process.exitcode
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Aug 30 08:49:22 2012
From: report at bugs.python.org (Trent Nelson)
Date: Thu, 30 Aug 2012 06:49:22 +0000
Subject: [New-bugs-announce] [issue15819] Unable to build Python out-of-tree
	when source tree is	readonly.
Message-ID: <1346309362.14.0.312540957077.issue15819@psf.upfronthosting.co.za>


New submission from Trent Nelson:

This is somewhat related to Issue #9860.  You can't currently build Python out-of-tree when the source directory is readonly.  This is because there are a few Parser/pgen/AST/python_asdl.py steps that try and write to $(srcdir).

The attached patch fixes this.

----------
assignee: trent
files: readonly_src.patch
keywords: patch
messages: 169430
nosy: trent
priority: low
severity: normal
stage: needs patch
status: open
title: Unable to build Python out-of-tree when source tree is readonly.
type: compile error
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27054/readonly_src.patch

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

From report at bugs.python.org  Thu Aug 30 09:45:41 2012
From: report at bugs.python.org (Mike Hoy)
Date: Thu, 30 Aug 2012 07:45:41 +0000
Subject: [New-bugs-announce] [issue15820] Add additional info to Resources
	area on Dev Guide
Message-ID: <1346312741.02.0.319894267547.issue15820@psf.upfronthosting.co.za>


New submission from Mike Hoy:

I wrote a patch which adds more info the devguide under Resources: http://docs.python.org/devguide/index.html#resources

----------
messages: 169436
nosy: mikehoy
priority: normal
severity: normal
status: open
title: Add additional info to Resources area on Dev Guide
versions: Python 3.3

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

From report at bugs.python.org  Thu Aug 30 11:53:08 2012
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 30 Aug 2012 09:53:08 +0000
Subject: [New-bugs-announce] [issue15821] Improve docs for
	PyMemoryView_FromBuffer()
Message-ID: <1346320388.88.0.494685067241.issue15821@psf.upfronthosting.co.za>


New submission from Stefan Krah:

People are using PyMemoryView_FromBuffer() to create and return
permanent memoryviews from buffers that are allocated on the stack.
See:

http://stackoverflow.com/questions/8123121/how-to-get-back-a-valid-object-from-python-in-c-while-this-object-has-been-con


The docs should perhaps warn against this.

----------
assignee: docs at python
components: Documentation
messages: 169443
nosy: belopolsky, docs at python, ncoghlan, pitrou, skrah
priority: normal
severity: normal
status: open
title: Improve docs for  PyMemoryView_FromBuffer()
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Aug 30 12:05:26 2012
From: report at bugs.python.org (=?utf-8?q?Tomi_Pievil=C3=A4inen?=)
Date: Thu, 30 Aug 2012 10:05:26 +0000
Subject: [New-bugs-announce] [issue15822] Python 3.3 creates lib2to3 grammar
	in wrong order
Message-ID: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za>


New submission from Tomi Pievil?inen:

Python 3.3rc1 source install modifies/installs lib2to3/Grammar.txt after modifying Grammar3.3.0.candidate.1.pickle:

-rw-r--r--. 1 root root  6589 2012-08-27 13:25:33.190414570 +0300 Grammar.txt
-rw-r--r--. 1 root root 20622 2012-08-27 13:25:33.150477192 +0300 Grammar3.3.0.candidate.1.pickle

This causes lib2to3/pgen2/driver:load_grammar to try to recreate the pickle (the _newer call on line 119 returns false), which triggers SandboxViolation in when using easy_install/distribute (https://bitbucket.org/tarek/distribute/issue/317/easy_install-fails-with-sandboxviolation) see .

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 169445
nosy: tpievila
priority: normal
severity: normal
status: open
title: Python 3.3 creates lib2to3 grammar in wrong order
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Aug 30 16:14:22 2012
From: report at bugs.python.org (Nikolay Golub)
Date: Thu, 30 Aug 2012 14:14:22 +0000
Subject: [New-bugs-announce] [issue15823] argparse produces error when
	multiply help lines
Message-ID: <1346336062.37.0.78121639083.issue15823@psf.upfronthosting.co.za>


New submission from Nikolay Golub:

When i use this code:
  parser.add_argument('-r', '--range',
                        action = 'store',
                        dest = 'ranges',
                        nargs = 2,
                        metavar = 'RANGE',
                        required = False,
                        help = 'Start and end range date and time for report data.'\
                                'Timeformat is %y-%m-%d %H:%M:%S'\
                                'for example -r "2012-08-20 14:48:39 "2012-08-25 15:35:00"'
                        )

I get this error:


Traceback (most recent call last):
  File "./create_report.py", line 166, in <module>
    main()
  File "./create_report.py", line 123, in main
    args = parser.parse_args()
  File "/usr/lib/python2.7/argparse.py", line 1688, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib/python2.7/argparse.py", line 1720, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib/python2.7/argparse.py", line 1926, in _parse_known_args
    start_index = consume_optional(start_index)
  File "/usr/lib/python2.7/argparse.py", line 1866, in consume_optional
    take_action(action, args, option_string)
  File "/usr/lib/python2.7/argparse.py", line 1794, in take_action
    action(self, namespace, argument_values, option_string)
  File "/usr/lib/python2.7/argparse.py", line 994, in __call__
    parser.print_help()
  File "/usr/lib/python2.7/argparse.py", line 2313, in print_help
    self._print_message(self.format_help(), file)
  File "/usr/lib/python2.7/argparse.py", line 2287, in format_help
    return formatter.format_help()
  File "/usr/lib/python2.7/argparse.py", line 279, in format_help
    help = self._root_section.format_help()
  File "/usr/lib/python2.7/argparse.py", line 209, in format_help
    func(*args)
  File "/usr/lib/python2.7/argparse.py", line 209, in format_help
    func(*args)
  File "/usr/lib/python2.7/argparse.py", line 515, in _format_action
    help_text = self._expand_help(action)
  File "/usr/lib/python2.7/argparse.py", line 601, in _expand_help
    return self._get_help_string(action) % params
ValueError: unsupported format character 'y' (0x79) at index 65

i think that it sin't normal. i always cut strings like these, according to pep8

----------
components: Library (Lib)
messages: 169456
nosy: Nikolay.Golub
priority: normal
severity: normal
status: open
title: argparse produces error when multiply help lines
versions: Python 2.7

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

From report at bugs.python.org  Thu Aug 30 20:17:45 2012
From: report at bugs.python.org (mastahyeti)
Date: Thu, 30 Aug 2012 18:17:45 +0000
Subject: [New-bugs-announce] [issue15824] mutable urlparse return type
Message-ID: <1346350665.33.0.731435453404.issue15824@psf.upfronthosting.co.za>


New submission from mastahyeti:

This patch removes the inheritance from namedtuple and attempts to add the necessary methods to make it backwards compatible.

When parsing a url with urlparse.urlparse, the return type is non-mutable (named tuple). This is really inconvenient, because one of the most common (imop) use cases for urlparse is to parse a url, make an adjustment or change and then unparse it. Currently, something like this is required:

    import urlparse

    url = list(urlparse.urlparse('http://www.example.com/foo/bar?hehe=haha'))
    url[1] = 'python.com'
    new_url = urllib.urlunparse(url)

I think this is really clunky. Moving to a mutable return type is challenging because (to my knowledge) there are no types that are mutable and compatible with tuple. This patch removes the inheritance from namedtuple and attempts to add the necessary methods to make it backwards compatible. Does any one know of a better way to do this? It would be nice if there were a namedlist type that acted like namedtuple but was mutable. 

With these updates, urlparse can be used as follows:

    import urlparse

    url = list(urlparse.urlparse('http://www.example.com/foo/bar?hehe=haha'))
    url.netloc = 'www.python.com'
    urlparse.urlunparse(url)

I think this is much better. Let me know if you disagree...

Also, I ran the script through autopep8 because it was messy.

Also, I'm not sure if I'm supposed to duplicate this patch over to Python3. I can do that if necessary

----------
components: Library (Lib)
files: urlparse_patch.patch
keywords: patch
messages: 169474
nosy: mastahyeti
priority: normal
severity: normal
status: open
title: mutable urlparse return type
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file27063/urlparse_patch.patch

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

From report at bugs.python.org  Thu Aug 30 23:29:19 2012
From: report at bugs.python.org (ThiefMaster)
Date: Thu, 30 Aug 2012 21:29:19 +0000
Subject: [New-bugs-announce] [issue15825] Typo in OrderedDict docs
Message-ID: <1346362159.24.0.0813127284667.issue15825@psf.upfronthosting.co.za>


New submission from ThiefMaster:

"It is also straight-forward to create an ordered dictionary variant that the remembers the order the keys were last inserted."

The first "the" doesn't belong there.

----------
assignee: docs at python
components: Documentation
messages: 169493
nosy: ThiefMaster, docs at python
priority: normal
severity: normal
status: open
title: Typo in OrderedDict docs
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Fri Aug 31 04:52:14 2012
From: report at bugs.python.org (Alessandro Moura)
Date: Fri, 31 Aug 2012 02:52:14 +0000
Subject: [New-bugs-announce] [issue15826] Increased test coverage of
	test_glob.py
Message-ID: <1346381534.69.0.636623200483.issue15826@psf.upfronthosting.co.za>


New submission from Alessandro Moura:

Hi,

Here is a patch to increase test coverage of test_glob.py. I added tests where the glob patterns are of type bytes. The coverage (according to coverage.py) is now complete, except for what are clearly artefacts probably caused by the fact that glob is loaded before coverage measurements start (global statements are reported not covered but local ones are).

----------
components: Tests
files: glob-cov-incr.patch
keywords: patch
messages: 169496
nosy: eng793
priority: normal
severity: normal
status: open
title: Increased test coverage of test_glob.py
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file27067/glob-cov-incr.patch

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

From report at bugs.python.org  Fri Aug 31 07:01:21 2012
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 31 Aug 2012 05:01:21 +0000
Subject: [New-bugs-announce] [issue15827] Use "ll" for PY_FORMAT_SIZE_T on
	Win64
Message-ID: <1346389281.37.0.195421488616.issue15827@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

Formatting support for "lld"/"llu" was added (I think) in issue 7228, but the definition of PY_FORMAT_SIZE_T wasn't adapted. We are getting test output failures in Cython on Win64 when formatting error messages using the "Id" format, as defined by pyport.h:

"""
#ifndef PY_FORMAT_SIZE_T
#   if SIZEOF_SIZE_T == SIZEOF_INT && !defined(__APPLE__)
#       define PY_FORMAT_SIZE_T ""
#   elif SIZEOF_SIZE_T == SIZEOF_LONG
#       define PY_FORMAT_SIZE_T "l"
#   elif defined(MS_WINDOWS)
#       define PY_FORMAT_SIZE_T "I"
#   else
#       error "This platform's pyconfig.h needs to define PY_FORMAT_SIZE_T"
#   endif
#endif
"""

The "%Id" format is not being resolved in the error messages and shows up in the output instead.

NumPy uses "lld" when available, starting with Py2.7:

https://github.com/numpy/numpy/blob/master/numpy/core/include/numpy/npy_common.h#L66

Shouldn't PY_FORMAT_SIZE_T become "ll" on Win64 directly?

----------
components: Interpreter Core
messages: 169500
nosy: scoder
priority: normal
severity: normal
status: open
title: Use "ll" for PY_FORMAT_SIZE_T on Win64
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Aug 31 09:32:28 2012
From: report at bugs.python.org (Mark Tolonen)
Date: Fri, 31 Aug 2012 07:32:28 +0000
Subject: [New-bugs-announce] [issue15828] imp.load_module doesn't support
	C_EXTENSION type
Message-ID: <1346398348.83.0.242228991466.issue15828@psf.upfronthosting.co.za>


New submission from Mark Tolonen:

I built a C extension using SWIG for both Python 3.2 and Python 3.3.  The Python file supplying class proxies uses imp.load_module and fails with the following traceback on 3.3.0rc1, but works on 3.2.3:

   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
     File ".\Widget.py", line 26, in <module>
       _Widget = swig_import_helper()
     File ".\Widget.py", line 22, in swig_import_helper
       _mod = imp.load_module('_Widget', fp, pathname, description)
     File "D:\dev\python33\lib\imp.py", line 171, in load_module
       raise ImportError(msg, name=name)
   ImportError: Don't know how to import _Widget (type code 3

It looks like imp.py is new in Python 3.3, and imp.load_module no longer supports the C_EXTENSION type.  It looks like a regression.

To reproduce, I was able to run the following lines with the .pyd file in the current directory:

   import imp
   fp, pathname, description = imp.find_module('_Widget')
   imp.load_module('_Widget', fp, pathname, description)

Nit: Also note the missing final ')' in the ImportError message.

----------
components: Library (Lib)
messages: 169506
nosy: metolone
priority: normal
severity: normal
status: open
title: imp.load_module doesn't support C_EXTENSION type
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Fri Aug 31 11:55:35 2012
From: report at bugs.python.org (Mike Hoy)
Date: Fri, 31 Aug 2012 09:55:35 +0000
Subject: [New-bugs-announce] [issue15829] Threading Lock - Wrong Exception
	Name
Message-ID: <1346406935.1.0.0548021295601.issue15829@psf.upfronthosting.co.za>


New submission from Mike Hoy:

>From the Docs mailing list:

>Hi

>I found a bug in python docs which can be accessed at links:
>http://docs.python.org/library/threading.html#lock-objects
>http://docs.python.org/py3k/library/threading.html#lock-objects

>Bug is in second paragraph describing threading.Lock. I found that >statement:
>"If an attempt is made to release an unlocked lock, a RuntimeError will >be raised."
>Which is not true, name of exception is wrong it should be (and it >relay is) ThreadError (from threading module)

>Could someone fix it?

>-- 
>Br,
>Slawomir Kuszczynski

----------
messages: 169513
nosy: mikehoy
priority: normal
severity: normal
status: open
title: Threading Lock - Wrong Exception Name
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Aug 31 16:03:16 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 31 Aug 2012 14:03:16 +0000
Subject: [New-bugs-announce] [issue15830] make -s no longer silences output
	from setup.py
Message-ID: <1346421796.43.0.205634084125.issue15830@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Sometime in the last month (probably) I change has been made in either configure(.ac), Makefile.pre.in, or setup.py that is causing the -s option passed to make to not also make its way into setup.py when extensions are built.

----------
components: Build
keywords: 3.2regression
messages: 169536
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: make -s no longer silences output from setup.py
versions: Python 3.3

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

From report at bugs.python.org  Fri Aug 31 17:57:14 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 31 Aug 2012 15:57:14 +0000
Subject: [New-bugs-announce] [issue15831] comma after leading optional
	argument is after bracket	in docs
Message-ID: <1346428634.66.0.0584130722662.issue15831@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

>From docs at python.org:

"""
In a number of places we find documentation with optional leading arguments where the meta-notation (square brackets) are in the wrong place.   For example, for range, the standard doc heading says

       range([start], stop [, step])   # The comma after start should be inside the square bracket, not outside.

The same error occurs with docs for print, and for slice, for random.randrange and for random.seed, etc, etc.   This seems a consistent bug whenever a function or method takes an optional first argument, and it looks like it might have been put there by some tool that generates the docs.

I use Python 3 - perhaps there was once a time when one had to supply the comma if one omitted the first argument?   In Python 3 it gives errors if one follows the documentation carefully and uses the comma.
""""

(or see http://mail.python.org/pipermail/docs/2012-August/010051.html )

----------
assignee: docs at python
components: Documentation
messages: 169547
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: comma after leading optional argument is after bracket in docs
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Aug 31 18:08:10 2012
From: report at bugs.python.org (Riccardo Murri)
Date: Fri, 31 Aug 2012 16:08:10 +0000
Subject: [New-bugs-announce] [issue15832] argparse: typechecks default value
	too early
Message-ID: <1346429290.76.0.112195597635.issue15832@psf.upfronthosting.co.za>


New submission from Riccardo Murri:

The `argparse` module (tested with 2.7, but other versions might be
affected) checks the `default` value of an option too early: if the
default value raises an exception, then command-line parsing stops.

Consider for example the following code:

############### begin sample #####################
import os
import argparse

def existing_filename(path):
    if not os.access(path, os.F_OK | os.R_OK):
        raise argparse.ArgumentTypeError("File '%s' does not exist or cannot be read." % path)
    return path

parser = argparse.ArgumentParser(description='Process a file.')
parser.add_argument('file', type=existing_filename, default='/some/weird/default',
                    help='A file to process.')

args = parser.parse_args()
print ("Will process file '%s' ..." % args.file)
############### end sample #####################

The intention here is that the default value should be used *if and
only if* the script users do not provide their own file to process.
It may happen that the default is invalid, but that should be reported
as an error only if the default is used, i.e., users did not provide
any file name to the script.

What happens instead is that the argparse errors out in any case, even
when `--help` is requested or when a valid file name is passed, as the
following two examples show:

    rmurri at xenia:/tmp$ ./argparse-processes-defaults-too-early.py --help
    Traceback (most recent call last):
      File "./argparse-processes-defaults-too-early.py", line 18, in <module>
        args = parser.parse_args()
      File "/usr/lib/python2.7/argparse.py", line 1688, in parse_args
        args, argv = self.parse_known_args(args, namespace)
      File "/usr/lib/python2.7/argparse.py", line 1710, in parse_known_args
        default = self._get_value(action, default)
      File "/usr/lib/python2.7/argparse.py", line 2239, in _get_value
        raise ArgumentError(action, msg)
    argparse.ArgumentError: argument file: File '/some/weird/default' does not exist or cannot be read.

    rmurri at xenia:/tmp$ ./argparse-processes-defaults-too-early.py /tmp/xxx.py 
    Traceback (most recent call last):
      File "./argparse-processes-defaults-too-early.py", line 18, in <module>
        args = parser.parse_args()
      File "/usr/lib/python2.7/argparse.py", line 1688, in parse_args
        args, argv = self.parse_known_args(args, namespace)
      File "/usr/lib/python2.7/argparse.py", line 1710, in parse_known_args
        default = self._get_value(action, default)
      File "/usr/lib/python2.7/argparse.py", line 2239, in _get_value
        raise ArgumentError(action, msg)
    argparse.ArgumentError: argument file: File '/some/weird/default' does not exist or cannot be read.

Thanks!

----------
components: Library (Lib)
messages: 169548
nosy: riccardomurri
priority: normal
severity: normal
status: open
title: argparse: typechecks default value too early
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug 31 18:57:26 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Fri, 31 Aug 2012 16:57:26 +0000
Subject: [New-bugs-announce] [issue15833] most failures to write
	byte-compiled file no longer	suppressed
Message-ID: <1346432246.49.0.876284426658.issue15833@psf.upfronthosting.co.za>


New submission from Richard Oudkerk:

As discussed in

    http://bugs.python.org/issue15819

trying to run python built outside a read-only source directory fails for me because OSError(EIO, ...) is raised when importlib tries to write the byte compiled file.  (I built python in a Linux VM using VMware Player which only had read-only access to the source directory.)

Currently importlib only ignores PermissionError (EACCES, EPERM) and FileExistsError (EEXIST):

    http://hg.python.org/cpython/file/d54f047312a8/Lib/importlib/_bootstrap.py#l1080

Under Python 3.2 all failures are ignored:

    http://hg.python.org/cpython/file/69952b5599b5/Python/import.c#l905

so this seems to be a regression.

----------
components: Interpreter Core
keywords: 3.3regression
messages: 169564
nosy: brett.cannon, sbt
priority: normal
severity: normal
status: open
title: most failures to write byte-compiled file no longer suppressed
type: behavior
versions: Python 3.3, Python 3.4

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