From report at bugs.python.org  Fri Nov  1 00:39:46 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 31 Oct 2013 23:39:46 +0000
Subject: [New-bugs-announce] [issue19466] Clear state of threads earlier in
	Python shutdown
Message-ID: <1383262786.4.0.00831923947445.issue19466@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Each Python thread holds references to objects, in its current frame for example. At Python shutdown, clearing threads state happens very late: the import machinery is already dead, types are finalized, etc. If a thread has an object with a destructor, bad things may happen.

For example, when open files are destroyed, a warning is emitted. The problem is that you cannot emits warnings because the warnings module has been unloaded, and so you miss warnings. See the issue #19442 for this specific case.

It is possible to clear the Python threads earlier since Python 3.2, because Python threads will now exit cleanly when they try to acquire the GIL: see PyEval_RestoreThread(). The value of the tstate pointer is used in PyEval_RestoreThread(), but the pointer is not dereferenced (the content of a Python state is not read). So it is even possible to free the memory of the threads state (not only to clear the threads state).

Attached patch implements destroy the all threads except the current thread, and clear the state of the current thread.

The patch calls also the garbage collector before flushing stdout and stderr, and disable signal handlers just before PyImport_Cleanup(). The main idea is to reorder functions like this:

- clear state of all threads to release strong references -> may call destructores
- force a garbage collector to release more references -> may call destructores
- flush stdout and stderr -> write pending warnings and any other buffered messages
- disable signal handler -> only at the end so previous steps can still be interrupted by CTRL+c

The side effect of the patch is that the destructor of destroyed objects are now called, especially for daemon threads. If you try the warn_shutdown.py script attached to #19442, you now get the warning with the patch! As a result, test_threading.test_4_daemon_threads() is also modified by my patch to ignore warnings :-)

If I understood correctly, the patch only has an impact on daemon threads, the behaviour of classic threads is unchanged.

----------
files: finalize_threads.patch
keywords: patch
messages: 201860
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: Clear state of threads earlier in Python shutdown
versions: Python 3.4
Added file: http://bugs.python.org/file32443/finalize_threads.patch

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

From report at bugs.python.org  Fri Nov  1 02:30:16 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Nov 2013 01:30:16 +0000
Subject: [New-bugs-announce] [issue19467] asyncore documentation: redirect
	users t
Message-ID: <1383269416.17.0.388850209653.issue19467@psf.upfronthosting.co.za>


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


----------
nosy: haypo
priority: normal
severity: normal
status: open
title: asyncore documentation: redirect users t

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

From report at bugs.python.org  Fri Nov  1 04:16:53 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Nov 2013 03:16:53 +0000
Subject: [New-bugs-announce] [issue19468] Relax the type restriction on
	reloaded modules
Message-ID: <1383275813.81.0.924128062775.issue19468@psf.upfronthosting.co.za>


New submission from Eric Snow:

The first thing that importlib.reload() does is to verify that the passed module is an instance of types.ModuleType (Lib/importlib/__init__.py:107).  This check seems unnecessary to me.  We really don't have a functional need for the check (that I know of).  Furthermore, there has been at least one serious proposal recently that suggested using custom module types.

The only benefit that I can think of to the type check is it makes the failure more clear when someone tries to "reload" an attribute in a module (thinking just the attribute will get reloaded!).  However, does that matter all that much now that reload() is not a builtin (ergo less likely to get misused very often)?

I'm not invested in removing these 2 lines (or at least loosening the restriction).  I've brought it up simply because it keeps staring me in the face lately. :-)  If anyone has any objections, I'll drop it (at least it will be recorded here in the tracker).  That said, I'm glad to remove the restriction otherwise.

----------
components: Library (Lib)
messages: 201874
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Relax the type restriction on reloaded modules
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov  1 07:05:32 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Nov 2013 06:05:32 +0000
Subject: [New-bugs-announce] [issue19469] Duplicate namespace package
	portions (but not on Windows)
Message-ID: <1383285932.19.0.495289288555.issue19469@psf.upfronthosting.co.za>


New submission from Eric Snow:

In changeset 88c3a1a3c2ff you'll find in test_api.py where I threw together a __path__ to compare against the one I was getting (which had 2 identical entries) on my Ubuntu 12.04 workstation.  The XP buildbot (http://buildbot.python.org/all/builders/x86%20XP-4%203.x) took issue with that (but non-windows was fine).

I was able to work around the difference (78d36d54391c), but I find the extra namespace portions surprising.  I'd like to get to the bottom of it.  I expect it has to do with how path entries are done on Windows, or perhaps with the way support.temp_cwd() iteracts with sys.path during testing.

----------
messages: 201880
nosy: brett.cannon, eric.smith, eric.snow
priority: normal
severity: normal
stage: test needed
status: open
title: Duplicate namespace package portions (but not on Windows)
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov  1 10:13:40 2013
From: report at bugs.python.org (hhm)
Date: Fri, 01 Nov 2013 09:13:40 +0000
Subject: [New-bugs-announce] [issue19470] email.header.Header - should not
	allow two newlines in a	row
Message-ID: <1383297220.57.0.645523530796.issue19470@psf.upfronthosting.co.za>


New submission from hhm:

An email.header.Header object should not allow two consecutive newlines, since this terminates interpretation of headers and starts the body section. This can be exploited by an attacker in a case of user input being used in headers, and validated with the Header object, by stopping interpretation of any further headers, which become interpreted by an user (or other) agent. This in turn can be used to modify the behavior of emails, web pages, and the like, where such code is present.

----------
components: Library (Lib)
messages: 201884
nosy: hhm
priority: normal
severity: normal
status: open
title: email.header.Header - should not allow two newlines in a row
type: security
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov  1 10:17:42 2013
From: report at bugs.python.org (Russell Jurney)
Date: Fri, 01 Nov 2013 09:17:42 +0000
Subject: [New-bugs-announce] [issue19471] pandas DataFrame access results in
	segfault
Message-ID: <1383297462.98.0.184422006167.issue19471@psf.upfronthosting.co.za>


New submission from Russell Jurney:

Python 2.7.6 RC1 on Mac OS X Mavericks 10.9 results in segfault when accessing a Pandas DataFrame. Same problem as in 2.7.5.

See http://stackoverflow.com/questions/19722580/segfault-with-pandas-with-python-v2-7-6-rc1-on-mac-os-x-10-9

----------
messages: 201886
nosy: Russell.Jurney
priority: normal
severity: normal
status: open
title: pandas DataFrame access results in segfault
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov  1 12:54:23 2013
From: report at bugs.python.org (Marco Buttu)
Date: Fri, 01 Nov 2013 11:54:23 +0000
Subject: [New-bugs-announce] [issue19472] inspect.getsource() raises a wrong
	exception type
Message-ID: <1383306863.35.0.879382426433.issue19472@psf.upfronthosting.co.za>


New submission from Marco Buttu:

I was looking at inspect.getsource(). In Python 3.3 and 3.4 either the docstring and the online doc say it raises a OSError, and in fact: 


>>> import inspect
>>> def foo():
...     pass
... 
>>> inspect.getsource(foo)
Traceback (most recent call last):
    ...
OSError: could not get source code


However, getsource() calls getfile(), and this one raises a TypeError:


>>> inspect.getsource(0)
Traceback (most recent call last):
 ...
TypeError: 0 is not a module, class, method, function, traceback, frame, or code object

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 201891
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: inspect.getsource() raises a wrong exception type
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov  1 14:12:54 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Nov 2013 13:12:54 +0000
Subject: [New-bugs-announce] [issue19473] Expose cache validation check in
	FileFinder
Message-ID: <1383311574.05.0.474186248833.issue19473@psf.upfronthosting.co.za>


New submission from Brett Cannon:

People seem to be sensitive enough to stat calls that exposing the cache validation check in FileFinder so it can be overridden to effectively turn it off would be useful to power users.

----------
components: Library (Lib)
messages: 201893
nosy: brett.cannon
priority: low
severity: normal
stage: test needed
status: open
title: Expose cache validation check in FileFinder
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov  1 15:32:12 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Nov 2013 14:32:12 +0000
Subject: [New-bugs-announce] [issue19474] Argument Clinic causing compiler
	warnings about	uninitialized variables
Message-ID: <1383316332.19.0.314587339416.issue19474@psf.upfronthosting.co.za>


New submission from Brett Cannon:

In the curses module there are some variables that can go uninitialized which are causing clang to complain:

/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:624:17: warning: variable
      'x' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
            if (!PyArg_ParseTuple(args, "Ol:addch", &ch, &attr))
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:643:65: note: 
      uninitialized use occurs here
    return_value = curses_window_addch_impl(self, group_left_1, x, y, ch, group_right_1, attr);
                                                                ^
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:624:13: note: remove the
      'if' if its condition is always true
            if (!PyArg_ParseTuple(args, "Ol:addch", &ch, &attr))
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:620:17: warning: variable
      'x' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
            if (!PyArg_ParseTuple(args, "O:addch", &ch))
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:643:65: note: 
      uninitialized use occurs here
    return_value = curses_window_addch_impl(self, group_left_1, x, y, ch, group_right_1, attr);
                                                                ^
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:620:13: note: remove the
      'if' if its condition is always true
            if (!PyArg_ParseTuple(args, "O:addch", &ch))
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:612:10: note: initialize
      the variable 'x' to silence this warning
    int x;
         ^
          = 0
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:624:17: warning: variable
      'y' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
            if (!PyArg_ParseTuple(args, "Ol:addch", &ch, &attr))
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:643:68: note: 
      uninitialized use occurs here
    return_value = curses_window_addch_impl(self, group_left_1, x, y, ch, group_right_1, attr);
                                                                   ^
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:624:13: note: remove the
      'if' if its condition is always true
            if (!PyArg_ParseTuple(args, "Ol:addch", &ch, &attr))
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:620:17: warning: variable
      'y' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
            if (!PyArg_ParseTuple(args, "O:addch", &ch))
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:643:68: note: 
      uninitialized use occurs here
    return_value = curses_window_addch_impl(self, group_left_1, x, y, ch, group_right_1, attr);
                                                                   ^
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:620:13: note: remove the
      'if' if its condition is always true
            if (!PyArg_ParseTuple(args, "O:addch", &ch))
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:613:10: note: initialize
      the variable 'y' to silence this warning
    int y;
         ^
          = 0
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:629:17: warning: variable
      'attr' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
            if (!PyArg_ParseTuple(args, "iiO:addch", &x, &y, &ch))
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:643:90: note: 
      uninitialized use occurs here
    return_value = curses_window_addch_impl(self, group_left_1, x, y, ch, group_right_1, attr);
                                                                                         ^~~~
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:629:13: note: remove the
      'if' if its condition is always true
            if (!PyArg_ParseTuple(args, "iiO:addch", &x, &y, &ch))
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:620:17: warning: variable
      'attr' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
            if (!PyArg_ParseTuple(args, "O:addch", &ch))
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:643:90: note: 
      uninitialized use occurs here
    return_value = curses_window_addch_impl(self, group_left_1, x, y, ch, group_right_1, attr);
                                                                                         ^~~~
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:620:13: note: remove the
      'if' if its condition is always true
            if (!PyArg_ParseTuple(args, "O:addch", &ch))
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/bcannon/Repositories/cpython/default/Modules/_cursesmodule.c:616:14: note: initialize
      the variable 'attr' to silence this warning
    long attr;
             ^
              = 0
6 warnings generated.

----------
assignee: larry
components: Extension Modules
messages: 201901
nosy: brett.cannon, larry
priority: normal
severity: normal
status: open
title: Argument Clinic causing compiler warnings about uninitialized variables
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov  1 18:05:21 2013
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 01 Nov 2013 17:05:21 +0000
Subject: [New-bugs-announce] [issue19475] Inconsistency between datetime's
	str()/isoformat() and	its strptime() method
Message-ID: <1383325521.57.0.024650274045.issue19475@psf.upfronthosting.co.za>


New submission from Skip Montanaro:

I have a CSV file. Here are a few rows:

"2013-10-30 14:26:46.000528","1.36097023829"
"2013-10-30 14:26:46.999755","1.36097023829"
"2013-10-30 14:26:47.999308","1.36097023829"
"2013-10-30 14:26:49.002472","1.36097023829"
"2013-10-30 14:26:50","1.36097023829"
"2013-10-30 14:26:51.000549","1.36097023829"
"2013-10-30 14:26:51.999315","1.36097023829"
"2013-10-30 14:26:52.999703","1.36097023829"
"2013-10-30 14:26:53.999640","1.36097023829"
"2013-10-30 14:26:54.999139","1.36097023829"

I want to parse the strings in the first column as timestamps. I can, and often do, use dateutil.parser.parse(), but in situations like this where all the timestamps are of the same format, it can be incredibly slow. OTOH, there is no single format I can pass to datetime.datetime.strptime() that will parse all the above timestamps. Using "%Y-%m-%d %H:%M:%S" I get errors about the leftover microseconds. Using "%Y-%m-%d %H:%M:%S".%f" I get errors when I try to parse a timestamp which doesn't have microseconds.

Alas, it is datetime itself which is to blame for this problem. The above timestamps were all printed from an earlier Python program which just dumps the str() of a datetime object to its output CSV file. Consider:

>>> dt = dateutil.parser.parse("2013-10-30 14:26:50")
>>> print dt
2013-10-30 14:26:50
>>> dt2 = dateutil.parser.parse("2013-10-30 14:26:51.000549")
>>> print dt2
2013-10-30 14:26:51.000549

The same holds for isoformat():

>>> print dt.isoformat()
2013-10-30T14:26:50
>>> print dt2.isoformat()
2013-10-30T14:26:51.000549

Whatever happened to "be strict in what you send, but generous in what you receive"? If strptime() is going to complain the way it does, then str() should always generate a full timestamp, including microseconds. The above is from a Python 2.7 session, but I also confirmed that Python 3.3 behaves the same.

I've checked 2.7 and 3.3 in the Versions list, but I don't think it can be fixed there. Can the __str__ and isoformat methods of datetime (and time) objects be modified for 3.4 to always include the microseconds? Alternatively, can the %S format character be modified to consume optional decimal point and microseconds? I rate this as "easy" considering the easiest fix is to modify __str__ and isoformat, which seems unchallenging.

----------
components: Extension Modules
keywords: easy
messages: 201917
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: Inconsistency between datetime's str()/isoformat() and its strptime() method
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov  1 18:52:24 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Nov 2013 17:52:24 +0000
Subject: [New-bugs-announce] [issue19476] Add a dedicated specification for
	module "reloading" to	the language reference
Message-ID: <1383328344.74.0.699907316394.issue19476@psf.upfronthosting.co.za>


New submission from Eric Snow:

In recent PEP 451-related discussions, the subject of reloading has come up multiple times.  Most recently, PJE suggested that reload semantics are under-specified (and under-tested). [1][2]

It may be worth adding a dedicated section on reloading to the reference doc.  As evidenced by that email thread (and issue #19413), there are some reload semantics that should be specified (and tested) but aren't.

While reload has a less prominent place in Python 3 (no longer a builtin), it is still a long-standing feature of the import system which gets used at more than just the interactive prompt.  I'd hate to see more issues like 19413 pop up later because of under-specification.  Furthermore, it would likely help other implementations pre-3.3 (a.k.a. pre-importlib) cover reload corner cases.

[1] https://mail.python.org/pipermail/python-dev/2013-October/129868.html
[2] https://mail.python.org/pipermail/python-dev/2013-October/129971.html

----------
components: Interpreter Core
messages: 201923
nosy: brett.cannon, eric.snow, ncoghlan, pje
priority: normal
severity: normal
stage: needs patch
status: open
title: Add a dedicated specification for module "reloading" to the language reference
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov  1 19:43:21 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 01 Nov 2013 18:43:21 +0000
Subject: [New-bugs-announce] [issue19477] document tp_print() as being dead
	in Py3
Message-ID: <1383331401.83.0.986088466963.issue19477@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

The "tp_print" slot is still documented as it was in Py2, although it is no longer used in Py3.

http://docs.python.org/3.4/c-api/typeobj.html?highlight=tp_print#PyTypeObject.tp_print

Given that it no longer serves any purpose, it should at least be deprecated and documented as unused/ignored (and eventually removed completely, at the same time as tp_reserved).

----------
assignee: docs at python
components: Documentation
messages: 201933
nosy: docs at python, scoder
priority: normal
severity: normal
status: open
title: document tp_print() as being dead in Py3
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov  1 20:53:28 2013
From: report at bugs.python.org (Marc Liyanage)
Date: Fri, 01 Nov 2013 19:53:28 +0000
Subject: [New-bugs-announce] [issue19478] Add ability to prefix posix
	semaphore names created by	multiprocessing module
Message-ID: <1383335608.62.0.190972038385.issue19478@psf.upfronthosting.co.za>


New submission from Marc Liyanage:

I'm running Python 2.7 in a sandboxed OS X app. There are restrictions on the naming of POSIX semaphores when running in the sandbox. Specifically, there is a mandatory prefix.

I would like the ability to inject this prefix into the part of the multiprocessing module that creates the semaphore, perhaps by way of an environment variable.

I see that this is how the module generates the semaphore name:

    PyOS_snprintf(buffer, sizeof(buffer), "/mp%ld-%d", (long)getpid(), counter++);

Apple's documentation about the restrictions are here:

https://developer.apple.com/library/mac/documentation/security/conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW24

The relevant part:

"POSIX semaphores and shared memory names must begin with the application group identifier, followed by a slash (/), followed by a name of your choosing."

So if I could inject that string before the leasing slash, I could make this work.

----------
components: Extension Modules
messages: 201936
nosy: Marc.Liyanage, jnoller, sbt
priority: normal
severity: normal
status: open
title: Add ability to prefix posix semaphore names created by multiprocessing module
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sat Nov  2 15:50:18 2013
From: report at bugs.python.org (Alexis Daboville)
Date: Sat, 02 Nov 2013 14:50:18 +0000
Subject: [New-bugs-announce] [issue19479] textwrap.dedent doesn't work
	properly with strings	containing CRLF
Message-ID: <1383403818.41.0.713007913793.issue19479@psf.upfronthosting.co.za>


New submission from Alexis Daboville:

If a string contains an empty line and is using CRLF newlines instead of LF newlines textwrap.dedent doesn't work properly: it returns the original string w/o dedenting it.

As far as I can tell it's because it considers the empty string to be the longest common indent (http://hg.python.org/cpython/file/2.7/Lib/textwrap.py#l372, '[^ \t\n]' matches '\r').

Expected behavior: textwrap.dedent should work the same way whether lines are separated by a single LF character or by CRLF.

To repro:

 ? 15:26 dabovill @ morag in /tmp/dedent $ cat dedent.py
import textwrap

lf = '\ta\n\tb\n\n\tc'
crlf = '\ta\r\n\tb\r\n\r\n\tc'

print('- lf')
print(lf)
print('- dedent(lf)')
print(textwrap.dedent(lf))
print('- crlf')
print(crlf)
print('- dedent(crlf)')
print(textwrap.dedent(crlf))
 ? 15:26 dabovill @ morag in /tmp/dedent $ python2.7 dedent.py
- lf
        a
        b

        c
- dedent(lf)
a
b

c
- crlf
        a
        b

        c
- dedent(crlf)
        a
        b

        c
 ? 15:26 dabovill @ morag in /tmp/dedent $ python3.3 dedent.py
- lf
        a
        b

        c
- dedent(lf)
a
b

c
- crlf
        a
        b

        c
- dedent(crlf)
        a
        b

        c

----------
components: Library (Lib)
messages: 201975
nosy: alexis.d
priority: normal
severity: normal
status: open
title: textwrap.dedent doesn't work properly with strings containing CRLF
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sat Nov  2 17:57:52 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 02 Nov 2013 16:57:52 +0000
Subject: [New-bugs-announce] [issue19480] HTMLParser fails to handle some
	characters in the	starttag
Message-ID: <1383411472.4.0.242370272088.issue19480@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

HTMLParser fails to handle some characters in the starttag, e.g. <a$b> should see 'a$b' as name but currently stops at $.  The attached patch fixes the issue.

----------
assignee: ezio.melotti
files: starttag.diff
keywords: patch
messages: 201980
nosy: ezio.melotti
priority: normal
severity: normal
stage: patch review
status: open
title: HTMLParser fails to handle some characters in the starttag
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32464/starttag.diff

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

From report at bugs.python.org  Sun Nov  3 05:29:16 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 03 Nov 2013 04:29:16 +0000
Subject: [New-bugs-announce] [issue19481] IDLE hangs while printing instance
	of Unicode subclass
Message-ID: <1383452956.07.0.644121763839.issue19481@psf.upfronthosting.co.za>


New submission from Tim Peters:

This showed up on StackOverflow:

http://stackoverflow.com/questions/19749757/print-is-blocking-forever-when-printing-unicode-subclass-instance-from-idle

They were using 32-bit Python 2.7.5 on Windows 7; I reproduced using the same Python on Windows Vista.  To reproduce, open IDLE, and enter

>>> class Foo(unicode):
        pass
>>> foo = Foo('bar')
>>> print foo

IDLE hangs then, and Ctrl+C is ignored.  Stranger, these variants do *not* hang:

>>> foo
>>> print str(foo)
>>> print repr(foo)

Those all work as expected.  Cute :-)

And none of these hang in a DOS-box session.

----------
components: IDLE
messages: 201991
nosy: tim.peters
priority: normal
severity: normal
status: open
title: IDLE hangs while printing instance of Unicode subclass
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov  3 07:31:23 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 03 Nov 2013 06:31:23 +0000
Subject: [New-bugs-announce] [issue19482] _pickle build warnings on Fedora 19
Message-ID: <1383460283.32.0.964490197084.issue19482@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Currently getting build warnings from _pickle.c:
==========================
building '_pickle' extension
gcc -pthread -fPIC -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I./Include -I. -IInclude -I/usr/local/include -I/home/ncoghlan/devel/py3k/Include -I/home/ncoghlan/devel/py3k -c /home/ncoghlan/devel/py3k/Modules/_pickle.c -o build/temp.linux-x86_64-3.4/home/ncoghlan/devel/py3k/Modules/_pickle.o
/home/ncoghlan/devel/py3k/Modules/_pickle.c: In function ?load_counted_long?:
/home/ncoghlan/devel/py3k/Modules/_pickle.c:4143:15: warning: ?pdata? may be used uninitialized in this function [-Wmaybe-uninitialized]
         value = _PyLong_FromByteArray((unsigned char *)pdata, (size_t)size,
               ^
/home/ncoghlan/devel/py3k/Modules/_pickle.c: In function ?load?:
/home/ncoghlan/devel/py3k/Modules/_pickle.c:5330:25: warning: ?s? may be used uninitialized in this function [-Wmaybe-uninitialized]
     i = (unsigned char)s[0];
                         ^
/home/ncoghlan/devel/py3k/Modules/_pickle.c:5324:11: note: ?s? was declared here
     char *s;
           ^
/home/ncoghlan/devel/py3k/Modules/_pickle.c:4995:30: warning: ?s? may be used uninitialized in this function [-Wmaybe-uninitialized]
     idx = Py_CHARMASK(s[0]);
                              ^
/home/ncoghlan/devel/py3k/Modules/_pickle.c:4986:11: note: ?s? was declared here
     char *s;
           ^
/home/ncoghlan/devel/py3k/Modules/_pickle.c:4005:20: warning: ?s? may be used uninitialized in this function [-Wmaybe-uninitialized]
     x |= (size_t) s[3] << 24;
                    ^
/home/ncoghlan/devel/py3k/Modules/_pickle.c:4858:11: note: ?s? was declared here
     char *s;
           ^
gcc -pthread -shared build/temp.linux-x86_64-3.4/home/ncoghlan/devel/py3k/Modules/_pickle.o -L/usr/local/lib -o build/lib.linux-x86_64-3.4/_pickle.cpython-34m.so
==========================

----------
components: Extension Modules
messages: 201997
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: _pickle build warnings on Fedora 19
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov  3 11:58:40 2013
From: report at bugs.python.org (Brecht Machiels)
Date: Sun, 03 Nov 2013 10:58:40 +0000
Subject: [New-bugs-announce] [issue19483] Pure-Python ElementTree classes no
	longer available	since 3.3
Message-ID: <1383476320.61.0.0930927196631.issue19483@psf.upfronthosting.co.za>


New submission from Brecht Machiels:

With Python 3.2, I subclassed ElementTree.XMLParser to set ExternalEntityRefHandler on the XMLParser's (expat) 'parser' member. I understand the 'parser' member is not part of the public API, but this was the only way to customize the parser without having to write a parser from scratch.

With 3.3, cElementTree replaces the Python implementation by default. Its XMLParser class has no accessible 'parser' member to configure. Unfortunately, there does not seem to be a way to use the pure-Python XMLParser, which would still allow for customization of the parser. Why is the Python version still in the library if it can't be accessed? Only for platforms where the C extension is not available?

I see two possible solutions:

1) Have XMLParser (both the C and Python versions) accept an optional parser argument, so that a custom parser can be passed in.

2) Make the Python version of ElementTree available again.

My other option is to copy the Python XMLParser version into my project. I would like to avoid this, as this would duplicate a lot of perfectly good code.
Perhaps there are other solutions?

----------
components: XML
messages: 202011
nosy: brechtm, eli.bendersky, scoder
priority: normal
severity: normal
status: open
title: Pure-Python ElementTree classes no longer available since 3.3
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Nov  3 15:52:54 2013
From: report at bugs.python.org (Annika Schiefner)
Date: Sun, 03 Nov 2013 14:52:54 +0000
Subject: [New-bugs-announce] [issue19484] Idle crashes when opening file
Message-ID: <1383490374.07.0.903795655927.issue19484@psf.upfronthosting.co.za>


New submission from Annika Schiefner:

Whenever I try opening a .py file, Idle crashes. 
Mac OS X, 10.6.8

----------
components: IDLE
messages: 202027
nosy: Schiefna
priority: normal
severity: normal
status: open
title: Idle crashes when opening file
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov  3 16:12:10 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 03 Nov 2013 15:12:10 +0000
Subject: [New-bugs-announce] [issue19485] Slightly incorrect doc for
	get_param method in	Lib/email/message.py
Message-ID: <1383491530.88.0.114432864855.issue19485@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Lib/email/message.py, line 665 & 666:

    param = msg.get_param('foo')
    param = email.utils.collapse_rfc2231_value(rawparam)

Where does rawparam come from?

On top of that, sending the result of get_param to collapse_rfc2231_value can make it chokes if the result of get_param is None. I already proposed the change in collapse_rfc2231_value to handle None gracefully in another ticket #19063, though.

----------
assignee: docs at python
components: Documentation
files: fix_doc_get_param_in_email_message.patch
keywords: patch
messages: 202029
nosy: docs at python, vajrasky
priority: normal
severity: normal
status: open
title: Slightly incorrect doc for get_param method in Lib/email/message.py
versions: Python 3.4
Added file: http://bugs.python.org/file32480/fix_doc_get_param_in_email_message.patch

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

From report at bugs.python.org  Sun Nov  3 16:30:01 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Sun, 03 Nov 2013 15:30:01 +0000
Subject: [New-bugs-announce] [issue19486] Bump up version of Tcl/Tk in
	building Python in Windows	platform
Message-ID: <1383492601.4.0.567246282787.issue19486@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Right now, at November 3rd 2013, the latest minor version of Tcl/Tk 8.5 is 8.5.15.

http://www.activestate.com/activetcl/downloads
http://www.tcl.tk/

When building Python in Windows in release mode (not debug mode), I had to download the Tcl/Tk binary build from ActiveState which only offers 8.5.15 version. To download the older version, you have to buy business license from them.

So maybe it's the time to bump up the version?

Of course we have to update the svn repository as well.
http://svn.python.org/projects/external/

----------
components: Tkinter
files: bump_up_tcl_version_windows.patch
keywords: patch
messages: 202030
nosy: vajrasky, zach.ware
priority: normal
severity: normal
status: open
title: Bump up version of Tcl/Tk in building Python in Windows platform
versions: Python 3.4
Added file: http://bugs.python.org/file32481/bump_up_tcl_version_windows.patch

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

From report at bugs.python.org  Sun Nov  3 18:38:46 2013
From: report at bugs.python.org (iMom0)
Date: Sun, 03 Nov 2013 17:38:46 +0000
Subject: [New-bugs-announce] [issue19487] Correct the error of the example
	given in the doc of	partialmethod
Message-ID: <1383500326.46.0.871927825617.issue19487@psf.upfronthosting.co.za>


Changes by iMom0 <mobeiheart at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: partialmethod-doc-fix.patch
keywords: patch
nosy: docs at python, imom0
priority: normal
severity: normal
status: open
title: Correct the error of the example given in the doc of partialmethod
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32484/partialmethod-doc-fix.patch

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

From report at bugs.python.org  Mon Nov  4 05:05:16 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 04 Nov 2013 04:05:16 +0000
Subject: [New-bugs-announce] [issue19488] idlelib tests are silently skipped
	by test.regrtest on	2.7
Message-ID: <1383537916.61.0.84173881768.issue19488@psf.upfronthosting.co.za>


New submission from Ned Deily:

Running test_idle is supposed to cause the tests in Lib/idlelib/idle_test to be run.  Unfortunately, under 2.7, when test.regrtest is used as the test runner, either directly or via "make test" (which buildbots use), the idlelib tests are currently silently skipped.  This can be seen by running with -v and observing that nothing is run:

python -m test.regrtest -v -uall test_idle

The problem is that test_idle.py is depending on regrtest support of the load_tests protocol; that support was only added to regrtest in 3.3.  Without changes to regrtest for 2.7, test_idle needs to define test_main as other tests do.  The attached patch seems to fix the problem.

----------
components: IDLE
files: test_idle_regrtest_27.patch
keywords: patch
messages: 202082
nosy: ned.deily, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: idlelib tests are silently skipped by test.regrtest on 2.7
versions: Python 2.7
Added file: http://bugs.python.org/file32488/test_idle_regrtest_27.patch

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

From report at bugs.python.org  Mon Nov  4 07:28:30 2013
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 Nov 2013 06:28:30 +0000
Subject: [New-bugs-announce] [issue19489] move quick search box above TOC
Message-ID: <1383546510.68.0.587653327623.issue19489@psf.upfronthosting.co.za>


New submission from Georg Brandl:

>From Mark Summerfield:,

    The Quick search box is really useful, but it is annoying that its
    position varies from page to page. On pages with long tables of
    contents it is often out of sight.

    Why not put it above the Table of Contents. That way it is always
    in the same place and easily accessible.

----------
assignee: docs at python
components: Documentation
messages: 202091
nosy: docs at python, georg.brandl
priority: normal
severity: normal
status: open
title: move quick search box above TOC

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

From report at bugs.python.org  Mon Nov  4 09:41:48 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 04 Nov 2013 08:41:48 +0000
Subject: [New-bugs-announce] [issue19490] Problem installing matplotlib
	1.3.1 with Python 2.7.6rc1	and 3.3.3rc1
Message-ID: <1383554508.21.0.868746765749.issue19490@psf.upfronthosting.co.za>


New submission from Ned Deily:

Piet van Oostrum (on python-dev and elsewhere) wrote:

I tried to install matplotlib 1.3.1 on the release candidates of Python 2.7.6 and 3.3.3.
I am on Mac OS X 10.6.8.
Although the installation gave no problems, there is a problem with Tcl/Tk.

The new Pythons have their own embedded Tcl/Tk, but when installing matplotlib it links to the Frameworks version of Tcl and TK, not to the embedded version. This causes confusion when importing matplotlib.pyplot:

objc[70648]: Class TKApplication is implemented in both /Library/Frameworks/Python.framework/Versions/2.7/lib/libtk8.5.dylib and /Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two will be used. Which one is undefined.
objc[70648]: Class TKMenu is implemented in both /Library/Frameworks/Python.framework/Versions/2.7/lib/libtk8.5.dylib and /Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two will be used. Which one is undefined.
objc[70648]: Class TKContentView is implemented in both /Library/Frameworks/Python.framework/Versions/2.7/lib/libtk8.5.dylib and /Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two will be used. Which one is undefined.
objc[70648]: Class TKWindow is implemented in both /Library/Frameworks/Python.framework/Versions/2.7/lib/libtk8.5.dylib and /Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two will be used. Which one is undefined.

And then later it gives a lot of error messages.

So I think it should be linked to the embedded version. For this the matplotlib setupext.py should be adapted to find out if there is an embedded Tcl/Tk in the Python installation and set the link parameters accordingly. However, the installed Python versions (from the DMG's) do not contain the Tcl/Tk header files, only the shared library and the tcl files. So I thing the distributed Python should also include the Tcl/Tk header files.

https://mail.python.org/pipermail/python-dev/2013-November/129993.html

----------
assignee: ned.deily
components: Installation, Macintosh
messages: 202097
nosy: benjamin.peterson, georg.brandl, larry, ned.deily, pietvo
priority: release blocker
severity: normal
status: open
title: Problem installing matplotlib 1.3.1 with Python 2.7.6rc1 and 3.3.3rc1
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Nov  4 10:55:41 2013
From: report at bugs.python.org (Carolyn Reed)
Date: Mon, 04 Nov 2013 09:55:41 +0000
Subject: [New-bugs-announce] [issue19491] Python Crashing When Saving
	Documents
Message-ID: <1383558941.35.0.744248647996.issue19491@psf.upfronthosting.co.za>


New submission from Carolyn Reed:

The ICT teacher at the school I work at has reported that frequently students are experiencing their Python software crashing when they attempt to save files.  No error message is reported, the software just freezes.

They are using the IDLE GUI Python v 3.2.4 on Windows 7 Professional 32-bit.

Please advise.

----------
components: IDLE
messages: 202103
nosy: carolyn.reed at talktalk.net
priority: normal
severity: normal
status: open
title: Python Crashing When Saving Documents
type: crash
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  4 13:57:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Nov 2013 12:57:44 +0000
Subject: [New-bugs-announce] [issue19492] Report skipped distutils tests as
	skipped
Message-ID: <1383569864.94.0.187586889245.issue19492@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Some skipped distutils tests are reported as passed. Arfrever pointed out on some of these tests on IRC. Proposed patch adds explicit reporting them as skipped.

See also issue18702.

----------
assignee: eric.araujo
components: Distutils, Tests
messages: 202123
nosy: eric.araujo, serhiy.storchaka, tarek
priority: normal
severity: normal
stage: patch review
status: open
title: Report skipped distutils tests as skipped
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Nov  4 13:57:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Nov 2013 12:57:58 +0000
Subject: [New-bugs-announce] [issue19493] Report skipped ctypes tests as
	skipped
Message-ID: <1383569878.45.0.454771857446.issue19493@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Some skipped ctypes tests are reported as passed. Proposed patch adds explicit reporting them as skipped.

See also issue18702.

----------
components: Tests, ctypes
files: skip_tests_ctypes.patch
keywords: patch
messages: 202124
nosy: amaury.forgeotdarc, belopolsky, meador.inge, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Report skipped ctypes tests as skipped
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32495/skip_tests_ctypes.patch

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

From report at bugs.python.org  Mon Nov  4 16:00:19 2013
From: report at bugs.python.org (Matej Cepl)
Date: Mon, 04 Nov 2013 15:00:19 +0000
Subject: [New-bugs-announce] [issue19494] urllib2.HTTPBasicAuthHandler
	(or	urllib.request.HTTPBasicAuthHandler) doesn't work with
	GitHub	API v3 and similar
Message-ID: <1383577219.47.0.139805262488.issue19494@psf.upfronthosting.co.za>


New submission from Matej Cepl:

GitHub API v3 is intentionally broken (see http://developer.github.com/v3/auth/):

> The main difference is that the RFC requires unauthenticated requests to be answered with 401 Unauthorized responses. In many places, this would disclose the existence of user data. Instead, the GitHub API responds with 404 Not Found. This may cause problems for HTTP libraries that assume a 401 Unauthorized response. The solution is to manually craft the Authorization header.

Unfortunately, urllib2.HTTPBasicAuthHandler relies on the standard-conformant behavior. So a naive programmer (like me) who wants to program against GitHub API using urllib2 (and foolishly ignores this comment about the API non-conformance, because he thinks GitHub wouldn't be that stupid and break all Python applications) uses for authentication something like the example script on http://docs.python.org/2/howto/urllib2.html#id6, spends couple of hours hitting this issue, until he tries python-requests (which work) and his (mistaken) conclusion is that urllib2 is a piece of crap which should never be used again.

I am not sure how widespread is this breaking of RFC, but it seems to me that quite a lot (e.g., http://stackoverflow.com/a/9698319/164233 which just en passant expects urllib2 authentication stuff to be useless), and the question is whether it shouldn't be documented somehow and/or urllib2.HTTPBasicAuthHandler shouldn't be modified to try add Authenticate header first.

----------
components: Library (Lib)
messages: 202144
nosy: mcepl
priority: normal
severity: normal
status: open
title: urllib2.HTTPBasicAuthHandler (or urllib.request.HTTPBasicAuthHandler) doesn't work with GitHub API v3 and similar
versions: Python 2.6, Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Nov  4 19:07:31 2013
From: report at bugs.python.org (Damien Moore)
Date: Mon, 04 Nov 2013 18:07:31 +0000
Subject: [New-bugs-announce] [issue19495] Enhancement for timeit: measure
	time to run blocks of	code using 'with'
Message-ID: <1383588451.25.0.545990193953.issue19495@psf.upfronthosting.co.za>


New submission from Damien Moore:

It would be useful if timeit had a class like `timeblock` below that would allow one to easily time code inside a `with` block:

import time

class timeblock:
    def __init__(self,descr=''):
        self.descr=descr
    def __enter__(self):
        self.t0=time.time()
        return self
    def __exit__(self, type, value, traceback):
        self.t1=time.time()
        self.elapsed = self.t1-self.t0
        if self.descr:
            print self.descr,'took',self.elapsed,'seconds'

This would be used as follows:

with timeblock('cumsum') as t:
    a=0
    for x in range(10000000):
        a+=x

and would output:
cumsum took 2.39 seconds

This is useful when trying to find bottlenecks in large programs without interfering with their operation, which would be harder to do with timeit.timeit and more verbose with time.

----------
components: Library (Lib)
messages: 202151
nosy: dmoore
priority: normal
severity: normal
status: open
title: Enhancement for timeit: measure time to run blocks of code using 'with'
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Nov  4 20:04:37 2013
From: report at bugs.python.org (Sergey)
Date: Mon, 04 Nov 2013 19:04:37 +0000
Subject: [New-bugs-announce] [issue19496] Website link
Message-ID: <1383591877.41.0.929815000655.issue19496@psf.upfronthosting.co.za>


New submission from Sergey:

Wrong ling following to Windows help file on the Python 2.7.6 RC 1 Web page.
It is the following:
http://www.python.org/ftp/python/2.7.6/python275.chm

And should be:
http://www.python.org/ftp/python/2.7.6/python276rc1.chm

----------
components: Build
messages: 202154
nosy: MolotoFF
priority: normal
severity: normal
status: open
title: Website link
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov  4 21:40:21 2013
From: report at bugs.python.org (Arnaud Faure)
Date: Mon, 04 Nov 2013 20:40:21 +0000
Subject: [New-bugs-announce] [issue19497] selectors and modify()
Message-ID: <1383597621.34.0.405182296639.issue19497@psf.upfronthosting.co.za>


Changes by Arnaud Faure <faure.arno at gmail.com>:


----------
files: modify_data.patch
keywords: patch
nosy: Arnaud.Faure
priority: normal
severity: normal
status: open
title: selectors and modify()
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32499/modify_data.patch

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

From report at bugs.python.org  Mon Nov  4 21:47:39 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 04 Nov 2013 20:47:39 +0000
Subject: [New-bugs-announce] [issue19498] IDLE is behaving badly in Python
	2.7.6rc1
Message-ID: <1383598059.38.0.633189194104.issue19498@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

IDLE is behaving badly in Python 2.7.6rc1 with a fresh install.

The problem occurs with a sequence of creating a new window, pasting code, and running the code:   Cmd-N, Cmd-V, Cmd-S, F5

The visible effect in IDLE is that a new window named "idle" is created and is unresponsive.  Behind the scenes, the following tracebacks occur.

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

Python 2.7.6rc1 (v2.7.6rc1:4913d0e9be30+, Oct 27 2013, 20:52:11) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin

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

~/tmp $ python2.7 -m idlelib.idle
Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 1470, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/IOBinding.py", line 222, in open
    flist.open(filename)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/FileList.py", line 36, in open
    return self.EditorWindow(self, filename, key)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/PyShell.py", line 131, in __init__
    EditorWindow.__init__(self, *args)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 323, in __init__
    io.loadfile(filename)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/IOBinding.py", line 258, in loadfile
    chars = self.decode(chars)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/IOBinding.py", line 296, in decode
    enc = coding_spec(chars)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/IOBinding.py", line 129, in coding_spec
    for line in lst:
NameError: global name 'lst' is not defined
Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 1470, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1025, in close
    self._close()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/PyShell.py", line 302, in _close
    EditorWindow._close(self)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1032, in _close
    self.unload_extensions()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1053, in unload_extensions
    for ins in self.extensions.values():
AttributeError: 'PyShellEditorWindow' object has no attribute 'extensions'
Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 1470, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1025, in close
    self._close()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/PyShell.py", line 302, in _close
    EditorWindow._close(self)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1032, in _close
    self.unload_extensions()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1053, in unload_extensions
    for ins in self.extensions.values():
AttributeError: 'PyShellEditorWindow' object has no attribute 'extensions'
Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 1470, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1025, in close
    self._close()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/PyShell.py", line 302, in _close
    EditorWindow._close(self)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1032, in _close
    self.unload_extensions()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1053, in unload_extensions
    for ins in self.extensions.values():
AttributeError: 'PyShellEditorWindow' object has no attribute 'extensions'
Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 1470, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1025, in close
    self._close()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/PyShell.py", line 302, in _close
    EditorWindow._close(self)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1032, in _close
    self.unload_extensions()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1053, in unload_extensions
    for ins in self.extensions.values():
AttributeError: 'PyShellEditorWindow' object has no attribute 'extensions'
Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 1470, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1025, in close
    self._close()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/PyShell.py", line 302, in _close
    EditorWindow._close(self)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1032, in _close
    self.unload_extensions()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1053, in unload_extensions
    for ins in self.extensions.values():
AttributeError: 'PyShellEditorWindow' object has no attribute 'extensions'
Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 1470, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1025, in close
    self._close()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/PyShell.py", line 302, in _close
    EditorWindow._close(self)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1032, in _close
    self.unload_extensions()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1053, in unload_extensions
    for ins in self.extensions.values():
AttributeError: 'PyShellEditorWindow' object has no attribute 'extensions'
Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 1470, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1025, in close
    self._close()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/PyShell.py", line 302, in _close
    EditorWindow._close(self)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1032, in _close
    self.unload_extensions()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1053, in unload_extensions
    for ins in self.extensions.values():
AttributeError: 'PyShellEditorWindow' object has no attribute 'extensions'
Exception in Tkinter callback
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 1470, in __call__
    return self.func(*args)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1025, in close
    self._close()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/PyShell.py", line 302, in _close
    EditorWindow._close(self)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1032, in _close
    self.unload_extensions()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1053, in unload_extensions
    for ins in self.extensions.values():
AttributeError: 'PyShellEditorWindow' object has no attribute 'extensions'
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/idle.py", line 11, in <module>
    idlelib.PyShell.main()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/PyShell.py", line 1582, in main
    root.mainloop()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py", line 1068, in mainloop
    self.tk.mainloop(n)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/FileList.py", line 48, in close_all_callback
    reply = edit.close()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1025, in close
    self._close()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/PyShell.py", line 302, in _close
    EditorWindow._close(self)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1032, in _close
    self.unload_extensions()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/EditorWindow.py", line 1053, in unload_extensions
    for ins in self.extensions.values():
AttributeError: 'PyShellEditorWindow' object has no attribute 'extensions'

----------
components: IDLE
messages: 202167
nosy: benjamin.peterson, rhettinger
priority: release blocker
severity: normal
stage: needs patch
status: open
title: IDLE is behaving badly in Python 2.7.6rc1
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov  5 02:55:02 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Nov 2013 01:55:02 +0000
Subject: [New-bugs-announce] [issue19499] "import this" is cached in
	sys.modules
Message-ID: <1383616502.26.0.617402510046.issue19499@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The "this" module doesn't import functions; instead, it prints directly to stdout.  Accordingly, there is no reason to cache this module in sys.modules.

Ideally, a learner should be able to type "import this" more than once in  a Python session.

----------
components: Library (Lib)
messages: 202183
nosy: rhettinger
priority: low
severity: normal
status: open
title: "import this" is cached in sys.modules
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov  5 05:02:10 2013
From: report at bugs.python.org (Ye Wang)
Date: Tue, 05 Nov 2013 04:02:10 +0000
Subject: [New-bugs-announce] [issue19500] Error when connecting to FTPS
	servers not supporting SSL	session resuming
Message-ID: <1383624130.64.0.185541289049.issue19500@psf.upfronthosting.co.za>


New submission from Ye Wang:

According to RFC4217 (Securing FTP with TLS, aka the FTPS spec), 

http://tools.ietf.org/html/rfc4217.html#section-10.2

"  It is reasonable for the server to insist that the data connection
   uses a TLS cached session.  This might be a cache of a previous data
   connection or of a cleared control connection.  If this is the reason
   for the refusal to allow the data transfer, then the '522' reply
   should indicate this.

   Note: This has an important impact on client design, but allows
   servers to minimize the cycles used during TLS negotiation by
   refusing to perform a full negotiation with a previously
   authenticated client."

It appears that vsftpd server implemented exactly that by enforcing the "SSL session reuse between the control and data connection".

http://scarybeastsecurity.blogspot.com/2009/02/vsftpd-210-released.html

Looking at the source of Python core library ftplib.py, there isn't any regard to the idea of SSL session reuse between data connection vs. control connection (correct me if I am wrong here. I've tried FTP_TLS.transfercmd(cmd[, rest])?, didn't work). 

This issue is well documented on other FTP clients that supports FTPS, I.E. WinSCP: http://winscp.net/tracker/show_bug.cgi?id=668

See test log file attached. A vsftpd server with "require_ssl_reuse" set to true in vsftpd.conf would do the trick and can be reproduced.

----------
components: Library (Lib)
files: ftplib-FTPS-bug.txt
messages: 202193
nosy: Ye.Wang
priority: normal
severity: normal
status: open
title: Error when connecting to FTPS servers not supporting SSL session resuming
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file32505/ftplib-FTPS-bug.txt

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

From report at bugs.python.org  Tue Nov  5 05:24:24 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 05 Nov 2013 04:24:24 +0000
Subject: [New-bugs-announce] [issue19501] Buildbot testing of 3.2 broken
Message-ID: <1383625464.91.0.832501203458.issue19501@psf.upfronthosting.co.za>


New submission from Zachary Ware:

After the recent commits to 3.2, I noticed that the only non-red 3.2 buildbots are the Windows bots; all other 3.2 bots are failing on `make touch`, which doesn't exist in 3.2.

The simplest fix seems to me to be to add a fake 'touch' target to the Makefile, but I'm not sure where that falls on the 'security fix only' policy.

How long will we continue buildbot testing of 3.2?

----------
components: Build
files: make_touch-3.2.diff
keywords: buildbot, patch
messages: 202194
nosy: georg.brandl, pitrou, zach.ware
priority: normal
severity: normal
status: open
title: Buildbot testing of 3.2 broken
versions: Python 3.2
Added file: http://bugs.python.org/file32506/make_touch-3.2.diff

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

From report at bugs.python.org  Tue Nov  5 10:01:32 2013
From: report at bugs.python.org (=?utf-8?q?Pawe=C5=82_Wroniszewski?=)
Date: Tue, 05 Nov 2013 09:01:32 +0000
Subject: [New-bugs-announce] [issue19502] Wrong time zone offset,
	when using time.strftime() with a given struct_time
Message-ID: <1383642092.47.0.283452068876.issue19502@psf.upfronthosting.co.za>


New submission from Pawe? Wroniszewski:

I encountered the problem in logging module, but it is broader then that. Have a look at the following code:

====
import time
DATE_FORMAT = '%d/%b/%Y %H:%M:%S%z %Z'
print(time.strftime(DATE_FORMAT))
print(time.strftime(DATE_FORMAT,time.localtime()))
====

The first print statement prints the correct time zone offset (in the place of %z), while the second prints +0000. It is important, because the logging module passes a predifined time_struct to time.strftime to format it - the timezone offset is not usable in such case. 

The documentation for time.strftime(format[, t]) reads:
"If t is not provided, the current time as returned by localtime() is used"
but apparently there must be something extra going on under the hood.

I checked that the problem is present in Python 2.7 and 3.2, probably in other version as well. Maybe it is platform dependent - I use Ubuntu 12.04 64 bit. 

If you want to change the time zone for testing, just run e.g.:
===
import os
os.environ['TZ'] = 'Asia/Kolkata'
import time
time.tzset()
===

----------
messages: 202200
nosy: pwronisz
priority: normal
severity: normal
status: open
title: Wrong time zone offset, when using time.strftime() with a given struct_time
type: behavior
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Tue Nov  5 12:14:05 2013
From: report at bugs.python.org (martenjan)
Date: Tue, 05 Nov 2013 11:14:05 +0000
Subject: [New-bugs-announce] [issue19503] does gc_list_merge merge properly?
Message-ID: <1383650045.9.0.887861923874.issue19503@psf.upfronthosting.co.za>


New submission from martenjan:

The code for gc_list_merge is given in gcmodule.c. I retrieved it from
http://hg.python.org/cpython/file/tip/Modules/gcmodule.c#l287

The code seems to merge list `from` incompletely: the first entry of `from` is omitted in the merged list. 

The issue is in line 295:   tail->gc.gc_next = from->gc.gc_next;
I fixed it as :             tail->gc.gc_next = from;

Please check if my analysis is correct.


See below for the context.

Original: lines 287 to 301

/* append list `from` onto list `to`; `from` becomes an empty list */
static void
gc_list_merge(PyGC_Head *from, PyGC_Head *to)
{
    PyGC_Head *tail;
    assert(from != to);
    if (!gc_list_is_empty(from)) {
        tail = to->gc.gc_prev;
        tail->gc.gc_next = from->gc.gc_next;
        tail->gc.gc_next->gc.gc_prev = tail;
        to->gc.gc_prev = from->gc.gc_prev;
        to->gc.gc_prev->gc.gc_next = to;
    }
    gc_list_init(from);
}


Fix:
/* append list `from` onto list `to`; `from` becomes an empty list */
static void
gc_list_merge(PyGC_Head *from, PyGC_Head *to)
{
    PyGC_Head *tail;
    assert(from != to);
    if (!gc_list_is_empty(from)) {
        tail = to->gc.gc_prev;
        tail->gc.gc_next = from;
        tail->gc.gc_next->gc.gc_prev = tail;
        to->gc.gc_prev = from->gc.gc_prev;
        to->gc.gc_prev->gc.gc_next = to;
    }
    gc_list_init(from);
}

----------
components: Interpreter Core
messages: 202206
nosy: martenjan
priority: normal
severity: normal
status: open
title: does gc_list_merge merge properly?
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov  5 14:46:40 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 05 Nov 2013 13:46:40 +0000
Subject: [New-bugs-announce] [issue19504] Change "customise" to "customize".
Message-ID: <1383659200.62.0.979344465483.issue19504@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

The python source code usually uses "customiz*" (341 instances) over "customis*" (19 instance, 8 of which are in logging).

I realize "foolish consistency", and all that, but I think the documentation should all use the same conventions. I'd be happy to change the documentation.

Most of these changes are in documentation or docstrings, but some are in comments. Which is why I'm assigning to docs at . I didn't change 2.0.rst, because that seemed like a historical document.

----------
assignee: docs at python
components: Documentation
files: customise.diff
keywords: easy, patch
messages: 202210
nosy: docs at python, eric.smith
priority: low
severity: normal
stage: patch review
status: open
title: Change "customise" to "customize".
versions: Python 3.4
Added file: http://bugs.python.org/file32507/customise.diff

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

From report at bugs.python.org  Tue Nov  5 17:17:58 2013
From: report at bugs.python.org (ThiefMaster)
Date: Tue, 05 Nov 2013 16:17:58 +0000
Subject: [New-bugs-announce] [issue19505] OrderedDict views don't implement
	__reversed__
Message-ID: <1383668278.19.0.898064141243.issue19505@psf.upfronthosting.co.za>


New submission from ThiefMaster:

The view objects for `collections.OrderedDict` do not implement `__reversed__` so something like this fails:

    >>> from collections import OrderedDict
    >>> od = OrderedDict()
    >>> reversed(od.viewvalues())
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: argument to reversed() must be a sequence

----------
components: Library (Lib)
messages: 202221
nosy: ThiefMaster
priority: normal
severity: normal
status: open
title: OrderedDict views don't implement __reversed__
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Nov  5 21:34:46 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Nov 2013 20:34:46 +0000
Subject: [New-bugs-announce] [issue19506] subprocess.communicate() should
	use a memoryview
Message-ID: <1383683686.87.0.96753537873.issue19506@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The following code copies data, whereas the copy can be avoided using a memory view:

chunk = self._input[self._input_offset:self._input_offset + _PIPE_BUF]
self._input_offset += os.write(key.fd, chunk)

It should be replaced with:

input_view = memoryview(self._input)
...
chunk = input_view[self._input_offset:self._input_offset + _PIPE_BUF]
self._input_offset += os.write(key.fd, chunk)


This issue is a reminder for one of my comment of issue #18923.

----------
messages: 202240
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: subprocess.communicate() should use a memoryview
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov  5 23:47:30 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Nov 2013 22:47:30 +0000
Subject: [New-bugs-announce] [issue19507] ssl.wrap_socket() with
	server_hostname should imply	match_hostname()
Message-ID: <1383691650.31.0.697174756225.issue19507@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I find it surprising that wrap_socket() doesn't verify the server name with match_hostname() when it is called with a server_name argument. The check should be done by default.

I suggest:

- add validate_hostname=True flag to wrap_socket() and functions that call wrap_socket()

- add SSLSocket.match_hostname(hostname=None) to validate hostname with current cert. hostname shall default to server_hostname

----------
messages: 202244
nosy: christian.heimes, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
stage: test needed
status: open
title: ssl.wrap_socket() with server_hostname should imply match_hostname()
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov  5 23:52:07 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Nov 2013 22:52:07 +0000
Subject: [New-bugs-announce] [issue19508] Add warning that Python doesn't
	verify SSL certs by	default
Message-ID: <1383691927.99.0.022250098505.issue19508@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Developers are still surprised that Python's ssl library doesn't validate SSL certs by default. We should add a *big* warning to the SSL module as well as to all consumers (http, ftp, imap, pop, smtp, nntp ...) that neither the CA cert chain nor the hostname are validated by default. (AFAIK only http.client does match_hostname()).

----------
assignee: docs at python
components: Documentation
messages: 202245
nosy: christian.heimes, docs at python, giampaolo.rodola, janssen, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: Add warning that Python doesn't verify SSL certs by default
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Nov  5 23:57:12 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Nov 2013 22:57:12 +0000
Subject: [New-bugs-announce] [issue19509] No SSL match_hostname() in ftp,
	imap, nntp, pop, smtp modules
Message-ID: <1383692232.58.0.310780294932.issue19509@psf.upfronthosting.co.za>


New submission from Christian Heimes:

None of the TLS/SSL classes for ftp, imap, nntp, pop and smtp have support for match_hostname() in order to verify that the SSL cert matches the host name. I'm not sure how we can handle the problem without creating backwards incompatibilities.

----------
messages: 202246
nosy: christian.heimes, giampaolo.rodola, janssen, pitrou
priority: high
severity: normal
stage: needs patch
status: open
title: No SSL match_hostname() in ftp, imap, nntp, pop, smtp modules
type: security
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov  6 01:27:39 2013
From: report at bugs.python.org (Augie Fackler)
Date: Wed, 06 Nov 2013 00:27:39 +0000
Subject: [New-bugs-announce] [issue19510] lib2to3.fixes.fix_import gets
	confused if implicit	relative imports and absolute imports
	are on the same line
Message-ID: <1383697659.1.0.717023788788.issue19510@psf.upfronthosting.co.za>


New submission from Augie Fackler:

While tinkering (again) with Mercurial Python 3 messes, I ran across this gem:

import error, osutil, encoding, collections

(http://selenic.com/hg/file/e1317d3e59e1/mercurial/util.py#l17)

That import statement contains 3 relative imports (that is, mercurial.error, mercurial.osutil, and mercurial.encoding), and one standard library import (collections). Because of the standard lib import on that line, lib2to3 doesn't rewrite any of the imports. If I instead move collections to its own line, then the first three imports get correctly rewritten to the "from . import error" form.

I've got Python 3.3.2 locally, and the lib2to3 is the one from that stdlib.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 202248
nosy: durin42, twouters
priority: normal
severity: normal
status: open
title: lib2to3.fixes.fix_import gets confused if implicit relative imports and absolute imports are on the same line
versions: Python 3.3

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

From report at bugs.python.org  Wed Nov  6 13:56:51 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 Nov 2013 12:56:51 +0000
Subject: [New-bugs-announce] [issue19511] lib2to3 Grammar file is no longer
	a Python 3 superset
Message-ID: <1383742611.34.0.802324885429.issue19511@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

In writing some new fixers for issue 17823, I noticed the 2/3 bridge grammar in lib2to3 was never updated to handle "yield from".

This item is also missing from the checklist in the devguide:

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

----------
components: Devguide, Library (Lib)
messages: 202265
nosy: ezio.melotti, ncoghlan
priority: low
severity: normal
status: open
title: lib2to3 Grammar file is no longer a Python 3 superset
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov  6 18:05:05 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Nov 2013 17:05:05 +0000
Subject: [New-bugs-announce] [issue19512] Avoid most calls to
	PyUnicode_DecodeUTF8Stateful() in	Python interactive mode
Message-ID: <1383757505.5.0.780170182234.issue19512@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In interactive mode, when I run python in gdb, I see that PyUnicode_DecodeUTF8Stateful() is called a lot of times. Calls come from PyDict_GetItemString() or PySys_GetObject() for example.

Allocating a temporary Unicode string and decode a byte string from UTF-8 is inefficient: the memory allocator is stressed and the byte string is decoded at each call.

I propose to reuse the _Py_IDENTIFIER API in most common places to limit calls to the memory allocator and to PyUnicode_DecodeUTF8Stateful().

----------
messages: 202273
nosy: haypo
priority: normal
severity: normal
status: open
title: Avoid most calls to PyUnicode_DecodeUTF8Stateful() in Python interactive mode
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov  7 01:33:00 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2013 00:33:00 +0000
Subject: [New-bugs-announce] [issue19513] Use PyUnicodeWriter instead of
	PyAccu in repr(tuple) and	repr(list)
Message-ID: <1383784380.8.0.280742626622.issue19513@psf.upfronthosting.co.za>


New submission from STINNER Victor:

PyUnicodeWriter is (a little bit) more efficient than PyAccu to build Unicode strings.

Attached patch list_repr_writer.patch modify list_repr() to use PyUnicodeWriter.

----------
files: list_repr_writer.patch
keywords: patch
messages: 202298
nosy: haypo, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use PyUnicodeWriter instead of PyAccu in repr(tuple) and repr(list)
versions: Python 3.4
Added file: http://bugs.python.org/file32520/list_repr_writer.patch

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

From report at bugs.python.org  Thu Nov  7 02:02:53 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2013 01:02:53 +0000
Subject: [New-bugs-announce] [issue19514] Merge duplicated _Py_IDENTIFIER
	identifiers in C code
Message-ID: <1383786173.17.0.938161811283.issue19514@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Some C files use more than once the same _Py_IDENTIFIER identifier. It would be more efficient to merge duplicated identifiers. Just move the definition to the top of the file.

_Py_IDENTIFIER(as_integer_ratio): Modules/_datetimemodule.c:1569
_Py_IDENTIFIER(as_integer_ratio): Modules/_datetimemodule.c:1668

_Py_IDENTIFIER(cursor): Modules/_sqlite/connection.c:1282
_Py_IDENTIFIER(cursor): Modules/_sqlite/connection.c:1312
_Py_IDENTIFIER(cursor): Modules/_sqlite/connection.c:1342

_Py_IDENTIFIER(fromutc): Modules/_datetimemodule.c:4210
_Py_IDENTIFIER(fromutc): Modules/_datetimemodule.c:4249
_Py_IDENTIFIER(fromutc): Modules/_datetimemodule.c:4812

_Py_IDENTIFIER(__len__): Objects/typeobject.c:5071
_Py_IDENTIFIER(__len__): Objects/typeobject.c:5235

_Py_IDENTIFIER(insert): Modules/_bisectmodule.c:198
_Py_IDENTIFIER(insert): Modules/_bisectmodule.c:93

_Py_IDENTIFIER(isoformat): Modules/_datetimemodule.c:2638
_Py_IDENTIFIER(isoformat): Modules/_datetimemodule.c:3596
_Py_IDENTIFIER(isoformat): Modules/_datetimemodule.c:4532

_Py_IDENTIFIER(strftime): Modules/_datetimemodule.c:1280
_Py_IDENTIFIER(strftime): Modules/_datetimemodule.c:2679

----------
keywords: easy
messages: 202300
nosy: haypo
priority: normal
severity: normal
status: open
title: Merge duplicated _Py_IDENTIFIER identifiers in C code
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov  7 02:08:17 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2013 01:08:17 +0000
Subject: [New-bugs-announce] [issue19515] Share duplicated _Py_IDENTIFIER
	identifiers in C code
Message-ID: <1383786497.11.0.135880606465.issue19515@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I started to share some common identifiers in Python/pythonrun.c, extract:

/* Common identifiers */
_Py_Identifier _PyId_argv = _Py_static_string_init("argv");
_Py_Identifier _PyId_builtins = _Py_static_string_init("builtins");
...

Do you think it would be interesting to continue to share such identifier somewhere? Maybe in a new file?

We might do the same for some common strings like empty string, single character (like "\n"), etc.


See also issue #19514.


Duplicated identifiers in the io module:

_Py_IDENTIFIER(_dealloc_warn): Modules/_io/bufferedio.c:17
_Py_IDENTIFIER(_dealloc_warn): Modules/_io/textio.c:15

_Py_IDENTIFIER(__IOBase_closed): Modules/_io/iobase.c:183
_Py_IDENTIFIER(__IOBase_closed): Modules/_io/iobase.c:62

_Py_IDENTIFIER(read1): Modules/_io/bufferedio.c:24
_Py_IDENTIFIER(read1): Modules/_io/textio.c:25

_Py_IDENTIFIER(readable): Modules/_io/bufferedio.c:25
_Py_IDENTIFIER(readable): Modules/_io/textio.c:26

_Py_IDENTIFIER(readall): Modules/_io/fileio.c:590
_Py_IDENTIFIER(readall): Modules/_io/iobase.c:802

_Py_IDENTIFIER(seek): Modules/_io/iobase.c:101
_Py_IDENTIFIER(seek): Modules/_io/textio.c:29

_Py_IDENTIFIER(writable): Modules/_io/bufferedio.c:27
_Py_IDENTIFIER(writable): Modules/_io/textio.c:33


Duplicated identifiers in other files:

_Py_IDENTIFIER(append): Modules/_elementtree.c:2373
_Py_IDENTIFIER(append): Modules/_pickle.c:5056

_Py_IDENTIFIER(__bases__): Objects/abstract.c:2417
_Py_IDENTIFIER(__bases__): Objects/typeobject.c:2813

_Py_IDENTIFIER(builtins): pythonrun.c
_Py_IDENTIFIER(builtins): Python/sysmodule.c:169

_Py_IDENTIFIER(__bytes__): Objects/bytesobject.c:2458
_Py_IDENTIFIER(__bytes__): Objects/object.c:563

_Py_IDENTIFIER(__class__): Objects/abstract.c:2492
_Py_IDENTIFIER(__class__): Objects/typeobject.c:42
_Py_IDENTIFIER(__class__): Python/codecs.c:470
_Py_IDENTIFIER(__class__): Python/compile.c:553

_Py_IDENTIFIER(close): Modules/_io/bufferedio.c:16
_Py_IDENTIFIER(close): Modules/_io/fileio.c:129
_Py_IDENTIFIER(close): Modules/_io/textio.c:14
_Py_IDENTIFIER(close): Modules/mmapmodule.c:707
_Py_IDENTIFIER(close): Modules/ossaudiodev.c:540
_Py_IDENTIFIER(close): Modules/selectmodule.c:1513
_Py_IDENTIFIER(close): Objects/genobject.c:173
_Py_IDENTIFIER(close): Python/traceback.c:235

_Py_IDENTIFIER(__delitem__): Objects/typeobject.c:5132
_Py_IDENTIFIER(__delitem__): Objects/typeobject.c:5183

_Py_IDENTIFIER(__dict__): Modules/arraymodule.c:2040
_Py_IDENTIFIER(__dict__): Modules/_collectionsmodule.c:894
_Py_IDENTIFIER(__dict__): Modules/_pickle.c:5204
_Py_IDENTIFIER(__dict__): Objects/bytearrayobject.c:2704
_Py_IDENTIFIER(__dict__): Objects/moduleobject.c:479
_Py_IDENTIFIER(__dict__): Objects/setobject.c:1946
_Py_IDENTIFIER(__dict__): Objects/typeobject.c:43
_Py_IDENTIFIER(__dict__): Parser/asdl_c.py:702
_Py_IDENTIFIER(__dict__): Python/bltinmodule.c:1942
_Py_IDENTIFIER(__dict__): Python/ceval.c:4660
_Py_IDENTIFIER(__dict__): Python/Python-ast.c:544

_Py_IDENTIFIER(__doc__): Objects/descrobject.c:1443
_Py_IDENTIFIER(__doc__): Objects/typeobject.c:44

_Py_IDENTIFIER(enable): Modules/faulthandler.c:1050
_Py_IDENTIFIER(enable): Modules/_posixsubprocess.c:50

_Py_IDENTIFIER(encoding): Python/bltinmodule.c:1716
_Py_IDENTIFIER(encoding): Python/pythonrun.c:1359
_Py_IDENTIFIER(encoding): Python/sysmodule.c:107

_Py_IDENTIFIER(filename): Python/errors.c:932
_Py_IDENTIFIER(filename): Python/pythonrun.c:1634

_Py_IDENTIFIER(fileno): Modules/faulthandler.c:133
_Py_IDENTIFIER(fileno): Modules/_io/_iomodule.c:238
_Py_IDENTIFIER(fileno): Modules/_io/textio.c:17
_Py_IDENTIFIER(fileno): Objects/fileobject.c:200
_Py_IDENTIFIER(fileno): Python/bltinmodule.c:35

_Py_IDENTIFIER(flush): Modules/faulthandler.c:134
_Py_IDENTIFIER(flush): Modules/_io/bufferedio.c:18
_Py_IDENTIFIER(flush): Modules/_io/textio.c:18
_Py_IDENTIFIER(flush): Python/bltinmodule.c:1550
_Py_IDENTIFIER(flush): Python/bltinmodule.c:36
_Py_IDENTIFIER(flush): Python/pythonrun.c:2120
_Py_IDENTIFIER(flush): Python/pythonrun.c:519

_Py_IDENTIFIER(__getinitargs__): Modules/_datetimemodule.c:3075
_Py_IDENTIFIER(__getinitargs__): Modules/_pickle.c:4501

_Py_IDENTIFIER(TextIOWrapper): Python/pythonrun.c:1005
_Py_IDENTIFIER(TextIOWrapper): Python/traceback.c:237

_Py_IDENTIFIER(__getstate__): Modules/_datetimemodule.c:3076
_Py_IDENTIFIER(__getstate__): Objects/typeobject.c:3448

_Py_IDENTIFIER(__import__): Python/ceval.c:2428
_Py_IDENTIFIER(__import__): Python/import.c:1230

_Py_IDENTIFIER(__module__): Objects/typeobject.c:48
_Py_IDENTIFIER(__module__): Python/errors.c:840
_Py_IDENTIFIER(__module__): Python/pythonrun.c:1916

_Py_IDENTIFIER(__name__): Objects/classobject.c:17
_Py_IDENTIFIER(__name__): Objects/typeobject.c:49
_Py_IDENTIFIER(__name__): Objects/weakrefobject.c:159
_Py_IDENTIFIER(__name__): Python/_warnings.c:260
_Py_IDENTIFIER(__name__): Python/codecs.c:471
_Py_IDENTIFIER(__name__): Python/import.c:1234

_Py_IDENTIFIER(__new__): Modules/_ctypes/callproc.c:1643
_Py_IDENTIFIER(__new__): Modules/_pickle.c:4511
_Py_IDENTIFIER(__new__): Objects/typeobject.c:50
_Py_IDENTIFIER(__new__): Objects/typeobject.c:5637

_Py_IDENTIFIER(__qualname__): Objects/descrobject.c:367
_Py_IDENTIFIER(__qualname__): Objects/methodobject.c:191
_Py_IDENTIFIER(__qualname__): Objects/typeobject.c:2032

_Py_IDENTIFIER(__setitem__): Modules/_collectionsmodule.c:1767
_Py_IDENTIFIER(__setitem__): Objects/typeobject.c:5133
_Py_IDENTIFIER(__setitem__): Objects/typeobject.c:5184

_Py_IDENTIFIER(__setstate__): Modules/_ctypes/callproc.c:1644
_Py_IDENTIFIER(__setstate__): Modules/_pickle.c:5147

_Py_IDENTIFIER(__trunc__): Modules/mathmodule.c:1464
_Py_IDENTIFIER(__trunc__): Objects/abstract.c:1273

_Py_IDENTIFIER(get): Modules/_collectionsmodule.c:1766
_Py_IDENTIFIER(get): Objects/descrobject.c:793

_Py_IDENTIFIER(isatty): Modules/_io/_iomodule.c:237
_Py_IDENTIFIER(isatty): Modules/_io/bufferedio.c:19
_Py_IDENTIFIER(isatty): Modules/_io/textio.c:20
_Py_IDENTIFIER(isatty): Python/pythonrun.c:1004

_Py_IDENTIFIER(items): Modules/_collectionsmodule.c:1566
_Py_IDENTIFIER(items): Modules/_pickle.c:2569
_Py_IDENTIFIER(items): Objects/abstract.c:2039
_Py_IDENTIFIER(items): Objects/descrobject.c:817
_Py_IDENTIFIER(items): Objects/typeobject.c:3537
_Py_IDENTIFIER(items): Python/Python-ast.c:108

_Py_IDENTIFIER(keys): Objects/abstract.c:2022
_Py_IDENTIFIER(keys): Objects/descrobject.c:803
_Py_IDENTIFIER(keys): Objects/dictobject.c:1792
_Py_IDENTIFIER(keys): Python/Python-ast.c:201

_Py_IDENTIFIER(lineno): Python/Python-ast.c:29
_Py_IDENTIFIER(lineno): Python/errors.c:933
_Py_IDENTIFIER(lineno): Python/pythonrun.c:1635

_Py_IDENTIFIER(mode): Modules/_io/_iomodule.c:239
_Py_IDENTIFIER(mode): Modules/_io/bufferedio.c:20
_Py_IDENTIFIER(mode): Modules/_io/textio.c:21
_Py_IDENTIFIER(mode): Python/pythonrun.c:1007

_Py_IDENTIFIER(msg): Python/Python-ast.c:130
_Py_IDENTIFIER(msg): Python/errors.c:934
_Py_IDENTIFIER(msg): Python/pythonrun.c:1633

_Py_IDENTIFIER(name): Modules/_io/bufferedio.c:21
_Py_IDENTIFIER(name): Modules/_io/fileio.c:62
_Py_IDENTIFIER(name): Modules/_io/textio.c:22
_Py_IDENTIFIER(name): Python/Python-ast.c:37
_Py_IDENTIFIER(name): Python/pythonrun.c:1006
_Py_IDENTIFIER(name): Python/pythonrun.c:222

_Py_IDENTIFIER(offset): Python/errors.c:935
_Py_IDENTIFIER(offset): Python/pythonrun.c:1636

_Py_IDENTIFIER(open): Objects/fileobject.c:33
_Py_IDENTIFIER(open): Parser/tokenizer.c:476
_Py_IDENTIFIER(open): Python/pythonrun.c:1003
_Py_IDENTIFIER(open): Python/traceback.c:155
_Py_IDENTIFIER(open): Python/traceback.c:236

_Py_IDENTIFIER(peek): Modules/_io/bufferedio.c:22
_Py_IDENTIFIER(peek): Modules/_io/iobase.c:453
_Py_IDENTIFIER(peek): Modules/_pickle.c:1181

_Py_IDENTIFIER(print_file_and_line): Python/errors.c:936
_Py_IDENTIFIER(print_file_and_line): Python/pythonrun.c:1865

_Py_IDENTIFIER(raw): Modules/_io/textio.c:23
_Py_IDENTIFIER(raw): Python/pythonrun.c:1029

_Py_IDENTIFIER(read): Modules/_cursesmodule.c:2336
_Py_IDENTIFIER(read): Modules/_io/bufferedio.c:23
_Py_IDENTIFIER(read): Modules/_io/bufferedio.c:55
_Py_IDENTIFIER(read): Modules/_io/iobase.c:452
_Py_IDENTIFIER(read): Modules/_io/iobase.c:846
_Py_IDENTIFIER(read): Modules/_io/textio.c:24
_Py_IDENTIFIER(read): Modules/_pickle.c:1182
_Py_IDENTIFIER(read): Modules/arraymodule.c:1267
_Py_IDENTIFIER(read): Modules/pyexpat.c:898
_Py_IDENTIFIER(read): Python/marshal.c:1595

_Py_IDENTIFIER(readinto): Modules/_io/bufferedio.c:26
_Py_IDENTIFIER(readinto): Python/marshal.c:621

_Py_IDENTIFIER(readline): Modules/_pickle.c:1183
_Py_IDENTIFIER(readline): Objects/fileobject.c:62
_Py_IDENTIFIER(readline): Parser/tokenizer.c:477

_Py_IDENTIFIER(replace): Modules/_datetimemodule.c:1071
_Py_IDENTIFIER(replace): Modules/_io/textio.c:27
_Py_IDENTIFIER(replace): Modules/zipimport.c:563
_Py_IDENTIFIER(replace): Modules/zipimport.c:70

_Py_IDENTIFIER(text): Modules/_elementtree.c:2357
_Py_IDENTIFIER(text): Python/errors.c:937
_Py_IDENTIFIER(text): Python/pythonrun.c:1637

_Py_IDENTIFIER(time): Modules/_datetimemodule.c:1309
_Py_IDENTIFIER(time): Modules/gcmodule.c:890

_Py_IDENTIFIER(upper): Modules/_sqlite/connection.c:1500
_Py_IDENTIFIER(upper): Modules/_sqlite/cursor.c:144
_Py_IDENTIFIER(upper): Modules/_sqlite/module.c:190
_Py_IDENTIFIER(upper): Python/Python-ast.c:329

_Py_IDENTIFIER(values): Objects/abstract.c:2056
_Py_IDENTIFIER(values): Objects/descrobject.c:810
_Py_IDENTIFIER(values): Python/Python-ast.c:170

_Py_IDENTIFIER(write): Modules/_csv.c:1374
_Py_IDENTIFIER(write): Modules/_cursesmodule.c:1792
_Py_IDENTIFIER(write): Modules/_io/bufferedio.c:28
_Py_IDENTIFIER(write): Modules/_pickle.c:831
_Py_IDENTIFIER(write): Modules/arraymodule.c:1340
_Py_IDENTIFIER(write): Modules/cjkcodecs/multibytecodec.c:1572
_Py_IDENTIFIER(write): Modules/cjkcodecs/multibytecodec.c:1642
_Py_IDENTIFIER(write): Objects/fileobject.c:131
_Py_IDENTIFIER(write): Python/marshal.c:1566
_Py_IDENTIFIER(write): Python/sysmodule.c:129
_Py_IDENTIFIER(write): Python/sysmodule.c:2007

----------
messages: 202301
nosy: haypo
priority: normal
severity: normal
status: open
title: Share duplicated _Py_IDENTIFIER identifiers in C code
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov  7 03:30:54 2013
From: report at bugs.python.org (Michael Merickel)
Date: Thu, 07 Nov 2013 02:30:54 +0000
Subject: [New-bugs-announce] [issue19516] segmentation fault using a dict as
	a key
Message-ID: <1383791454.4.0.286950370994.issue19516@psf.upfronthosting.co.za>


New submission from Michael Merickel:

I assume there is some incompatibility in the maverick's C runtime, but getting a segfault only on the python binaries from python.org.

Version shipped by Apple OS X 10.9 Mavericks:

~? python2.7
Python 2.7.5 (default, Sep 12 2013, 21:33:34)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> foo = {}
>>> foo[{}] = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'dict'
>>>

2.7 binary installed from python.org:

~? /Library/Frameworks/Python.framework/Versions/2.7/bin/python
Python 2.7.5 (v2.7.5:ab05e7dd2788, May 13 2013, 13:18:45)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> foo = {}
>>> foo[{}] = 1
[1]    4517 segmentation fault  /Library/Frameworks/Python.framework/Versions/2.7/bin/python

3.3 binary installed from python.org:

Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> foo = {}
>>> foo[{}] = 1
[1]    1898 segmentation fault  python

----------
assignee: ronaldoussoren
components: Macintosh
messages: 202303
nosy: mmerickel, ronaldoussoren
priority: normal
severity: normal
status: open
title: segmentation fault using a dict as a key
type: crash
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Nov  7 10:42:50 2013
From: report at bugs.python.org (Yury V. Zaytsev)
Date: Thu, 07 Nov 2013 09:42:50 +0000
Subject: [New-bugs-announce] [issue19517] sysconfig variables introduced by
	PEP-3149 are currently	undocumented
Message-ID: <1383817370.06.0.832101604134.issue19517@psf.upfronthosting.co.za>


New submission from Yury V. Zaytsev:

PEP-3149 (issue9193) introduces new variables (SO and SOABI) so that one can find out what are the supported extension suffixes.

Quote from the PEP:

>>> sysconfig.get_config_var('SO')
'.cpython-32mu.so'
>>> sysconfig.get_config_var('SOABI')
'cpython-32mu'

Later, in issue16754, doko introduced EXT_SUFFIX & SHLIB_SUFFIX and planned to update the PEP, but this didn't happen. This caused discrepancy in the news (issue11234), and the news item was fixed:

http://docs.python.org/3.4/whatsnew/3.2.html?highlight=soabi

>>> sysconfig.get_config_var('SOABI')       # find the version tag
'cpython-32mu'
>>> sysconfig.get_config_var('EXT_SUFFIX')  # find the full filename extension
'.cpython-32mu.so'

However, the PEP is still not up-to-date and is in conflict with the implementation.

In an IRC discussion with Barry he suggested that PEPs shouldn't be considered documentation, so updating the PEP is not the right way to go.

My proposal is then to document the intent behind SO, SOABI, EXT_SUFFIX & SHLIB_SUFFIX on the sysconfig documentation page and mention that they are platform-specific, and maybe add a link to this page to the PEP.

As of now, I find the situation highly confusing... Any opinions or suggestions please?

Thanks,

Z.

----------
assignee: docs at python
components: Documentation
messages: 202321
nosy: barry, docs at python, doko, zaytsev
priority: normal
severity: normal
status: open
title: sysconfig variables introduced by PEP-3149 are currently undocumented
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Nov  7 12:48:00 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2013 11:48:00 +0000
Subject: [New-bugs-announce] [issue19518] Add new PyRun_xxx() functions to
	not encode the filename
Message-ID: <1383824880.09.0.781641455514.issue19518@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The changeset af822a6c9faf of the issue #19512 added the function PyRun_InteractiveOneObject(). By the way, I forgot to document this function. This issue is also a reminder for that. The purpose of the new function is to avoid creation of temporary Unicode strings and useless call to Unicode encoder/decoder.

I propose to generalize the change to other PyRun_xxx() functions. Attached patch adds the following functions:

- PyRun_AnyFileObject()
- PyRun_SimpleFileObject()
- PyRun_InteractiveLoopObject()
- PyRun_FileObject()

On Windows, these changes should allow to pass an unencodable filename on the command line (ex: japanese script name on an english setup).

TODO: I should document all these new functions.

----------
files: pyrun_object.patch
keywords: patch
messages: 202326
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add new PyRun_xxx() functions to not encode the filename
versions: Python 3.4
Added file: http://bugs.python.org/file32524/pyrun_object.patch

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

From report at bugs.python.org  Thu Nov  7 13:40:55 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Nov 2013 12:40:55 +0000
Subject: [New-bugs-announce] [issue19519] Parser: don't transcode input
	string to UTF-8 if it is	already encoded to UTF-8
Message-ID: <1383828055.35.0.303135915018.issue19519@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Python parser (Parser/tokenizer.c) has a translate_into_utf8() function to decode a string from the input encoding and encode it to UTF-8.

This function is unnecessary if the input string is already encoded to UTF-8, which is something common nowadays. Linux, Mac OS X and many other operating systems are now using UTF-8 as the default locale encoding, UTF-8 is the default encoding for Python scripts, etc. compile(), eval() and exec() functions pass UTF-8 encoded strings to the parser.

Attached patch adds an input_is_utf8 flag to the tokenizer to skip translate_into_utf8() if the input string is already encoded to UTF-8.

----------
files: input_is_utf8.patch
keywords: patch
messages: 202331
nosy: benjamin.peterson, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Parser: don't transcode input string to UTF-8 if it is already encoded to UTF-8
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file32526/input_is_utf8.patch

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

From report at bugs.python.org  Thu Nov  7 16:41:52 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 07 Nov 2013 15:41:52 +0000
Subject: [New-bugs-announce] [issue19520] Win32 compiler warning in _sha3
Message-ID: <1383838912.21.0.108258927136.issue19520@psf.upfronthosting.co.za>


New submission from Zachary Ware:

There is only one remaining compiler warning on 32-bit Windows, see [1] (buildbot doubles warning counts on the Windows bots).

The warning is coming from Modules/_sha3/keccak/KeccakF-1600-opt32.c#l497, which uses extractLanes as defined on line 213.

The attached patch fixes the compiler warning, doesn't add any new ones, compiles, and doesn't break anything obvious.  I don't know enough about it to be confident in whether this is the right fix, so I'll leave it up to you, Christian :)

Thanks,

Zach


[1] http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%203.x/builds/1682/steps/compile/logs/warnings%20%282%29

----------
components: Build, Windows
files: sha3_compile_warning.diff
keywords: patch
messages: 202344
nosy: christian.heimes, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Win32 compiler warning in _sha3
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32530/sha3_compile_warning.diff

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

From report at bugs.python.org  Thu Nov  7 17:04:54 2013
From: report at bugs.python.org (Michael Haubenwallner)
Date: Thu, 07 Nov 2013 16:04:54 +0000
Subject: [New-bugs-announce] [issue19521] parallel build race condition on
	AIX since python-3.2
Message-ID: <1383840294.95.0.0890053719997.issue19521@psf.upfronthosting.co.za>


New submission from Michael Haubenwallner:

Since python-3.2, there is a race condition building in parallel on AIX:

Consider these Makefile(.pre.in) rules:

$(BUILDPYTHON): ...
  $(LINKCC) ... $(LINKFORSHARED) ...

Modules/_testembed: ...
  $(LINKCC) ... $(LINKFORSHARED) ...

Modules/_freeze_importlib: ...
  $(LINKCC) ...

On AIX, the variables get these values:

LINKCC = $(srcdir)/Modules/makexp_aix Modules/python.exp ...
LINKFORSHARED = -Wl,-bE:Modules/python.exp ...

Now $(BUILDPYTHON) and Modules/_testembed may run in parallel, causing Modules/python.exp to be created by two instances of makexp_aix eventually running at the same time.

Attached patch fixes this problem for cpython tip (doubt supporting AIX 4.1 and earlier still is necessary).

Thank you!

----------
components: Build
files: python-tip-aix-parallel.patch
keywords: patch
messages: 202357
nosy: haubi
priority: normal
severity: normal
status: open
title: parallel build race condition on AIX since python-3.2
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file32534/python-tip-aix-parallel.patch

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

From report at bugs.python.org  Fri Nov  8 02:23:27 2013
From: report at bugs.python.org (wang xuancong)
Date: Fri, 08 Nov 2013 01:23:27 +0000
Subject: [New-bugs-announce] [issue19522] A suggestion: python 3.* is not as
	convenient as python	2.*
Message-ID: <1383873807.23.0.835137280859.issue19522@psf.upfronthosting.co.za>


New submission from wang xuancong:

Hi python developers,

I notice that one major change in python 3 is that you make 'print' as a standard function, and it will require typing (). As you know, reading from and writing to IO is a high frequency operation. By entropy coding theorem, you should make your language having shortest code for doing that job. Typing a '(' requires holding SHIFT and pressing 9, the input effort is much higher. Also, specifying IO has changed from >>* to file=*, which becomes more inconvenient.

I hope you can take a look at user's code and see what are the most commonly used functions and try to shorten language codes for those functions. Assigning shortest language codes to most frequently used functions will make python the best programming language in the world.

Another suggestion is that 'enumerate' is also frequently used, hopefully you can shorten the command.

Wang Xuancong
National University of Singapore

----------
components: Interpreter Core
messages: 202400
nosy: xuancong84
priority: normal
severity: normal
status: open
title: A suggestion: python 3.* is not as convenient as python 2.*
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov  8 04:40:03 2013
From: report at bugs.python.org (DDGG)
Date: Fri, 08 Nov 2013 03:40:03 +0000
Subject: [New-bugs-announce] [issue19523] logging.FileHandler - using of
	delay argument case	handler leaks
Message-ID: <1383882003.26.0.546663037949.issue19523@psf.upfronthosting.co.za>


New submission from DDGG:

Issue File: Python26\Lib\logging\__init__.py

class FileHandler(StreamHandler):
    """
    A handler class which writes formatted logging records to disk files.
    """
    def __init__(self, filename, mode='a', encoding=None, delay=0):
        """
        Open the specified file and use it as the stream for logging.
        """
        #keep the absolute path, otherwise derived classes which use this
        #may come a cropper when the current directory changes
        if codecs is None:
            encoding = None
        self.baseFilename = os.path.abspath(filename)
        self.mode = mode
        self.encoding = encoding
        if delay:
            #We don't open the stream, but we still need to call the
            #Handler constructor to set level, formatter, lock etc.
            Handler.__init__(self)   ## 1. here will insert instance into logging._handlerList
            self.stream = None
        else:
            StreamHandler.__init__(self, self._open())

    def close(self):
        """
        Closes the stream.
        """
        if self.stream:   ## 2. when delay=1, here should call Handler.close(self), or the instance still store in logging._handlerList, lead to leak (instance's owner's __del__ will not be called).
            self.flush()
            if hasattr(self.stream, "close"):
                self.stream.close()
            StreamHandler.close(self)
            self.stream = None

------------------------------------------------
leak demo:

import logging
import time

def using_handler():
    filename = "test.log"
    handler = logging.FileHandler(filename, mode="w", delay=1)
    handler.close()

def test():
    while True:
        using_handler()
        time.sleep(.01)

if __name__ == "__main__":
    test()


If you run this script, and then view the Task Manager for this process's handlers, it is growing forever.

------------------------------------
Solution: very easy

Fix the method FileHandler.close:

    def close(self):
        """
        Closes the stream.
        """
        if self.stream:
            self.flush()
            if hasattr(self.stream, "close"):
                self.stream.close()
            StreamHandler.close(self)
            self.stream = None
        else:                       
            Handler.close(self)     


regards
DDGG

----------
components: Library (Lib)
messages: 202403
nosy: DDGG
priority: normal
severity: normal
status: open
title: logging.FileHandler - using of delay argument case handler leaks
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Fri Nov  8 04:45:17 2013
From: report at bugs.python.org (Martin Panter)
Date: Fri, 08 Nov 2013 03:45:17 +0000
Subject: [New-bugs-announce] [issue19524] ResourceWarning when urlopen()
	forgets the	HTTPConnection object
Message-ID: <1383882317.08.0.635493267684.issue19524@psf.upfronthosting.co.za>


New submission from Martin Panter:

The AbstractHTTPHandler.do_open() method creates a HTTPConnection object but does not save it anywhere. This means a ResourceWarning is eventually triggered, at least when the HTTP server leaves the the connection open.

Demonstration code:

from urllib.request import urlopen
with urlopen("http://localhost") as response: response.read()

When I used the above code, the warning did not trigger until I forced a garbage collection:

import gc; gc.collect()

Output:

__main__:1: ResourceWarning: unclosed <socket.socket object, fd=3, family=2, type=1, proto=6>

Alternatively, you can add a line to the bottom of the do_open() method:

        r.msg = r.reason
        del h; import gc; gc.collect()  # Add this to force warning
        return r

When the warning happens without forced garbage collection, it tends to happen here:

/usr/lib/python3.3/socket.py:370: ResourceWarning: unclosed <socket.socket object, fd=3, family=2, type=1, proto=6>
  self._sock = None

I tested by using the ?socat? CLI program and supplying a chunked HTTP response, without immediately closing the connection at the server end. Using the Content-length header also seems to trigger the issue.

$ sudo socat -d TCP-LISTEN:www,reuseaddr,crnl READLINE
GET / HTTP/1.1
Accept-Encoding: identity
Host: localhost
Connection: close
User-Agent: Python-urllib/3.3

<HTTP response start>
HTTP/1.1 200 OK
Transfer-encoding: chunked

0

<HTTP response end>

If the server leaves the connection open, it only seems to get closed when Python garbage-collects the socket and closes it. Perhaps the connection should be explicitly closed when the urlopen() response object is closed. But I guess that would require wrapping the HTTPResponse object to add to the close behaviour.

----------
components: Library (Lib)
messages: 202404
nosy: vadmium
priority: normal
severity: normal
status: open
title: ResourceWarning when urlopen() forgets the HTTPConnection object
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Nov  8 08:33:28 2013
From: report at bugs.python.org (Sworddragon)
Date: Fri, 08 Nov 2013 07:33:28 +0000
Subject: [New-bugs-announce] [issue19525] Strict indentation in Python3
Message-ID: <1383896008.92.0.87081391555.issue19525@psf.upfronthosting.co.za>


New submission from Sworddragon:

Python 2 provided this command line option:

"-t     Issue a warning when a source file mixes tabs and spaces for indentation in a way that makes it depend on the worth of a tab expressed in spaces.  Issue an error when the option is given twice."


I'm wondering why it doesn't exist anymore in Python 3. I wanted to make some tests to figure this out but I'm not able to trigger this behavior in Python 2. All my examples will result in throwing an exception with and without -tt or never throwing an exception with or without -tt. But I'm also having difficulties to understand what the second part of the sentence does mean. Can somebody maybe provide an example where "python2 -tt" will fail but "python2" not?

----------
components: Interpreter Core
messages: 202408
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Strict indentation in Python3
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Fri Nov  8 12:18:15 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Nov 2013 11:18:15 +0000
Subject: [New-bugs-announce] [issue19526] Review additions to the stable ABI
	of Python 3.4
Message-ID: <1383909495.56.0.906628582778.issue19526@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Example:

http://hg.python.org/cpython/rev/69071054b42f
PyAPI_FUNC(int) _PyDict_DelItemId(PyObject *mp, struct _Py_Identifier *key);

New functions added in this issue should also be reviewed (should them be part of the stable ABI?):

http://bugs.python.org/issue11619
http://hg.python.org/cpython/rev/df2fdd42b375

----------
messages: 202412
nosy: haypo, loewis, ncoghlan
priority: normal
severity: normal
status: open
title: Review additions to the stable ABI of Python 3.4
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov  8 13:30:13 2013
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Fri, 08 Nov 2013 12:30:13 +0000
Subject: [New-bugs-announce] [issue19527] Test failures with COUNT_ALLOCS
Message-ID: <1383913813.74.0.198352256395.issue19527@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

When Python is compiled with COUNT_ALLOCS, some tests in test_gc and test_module fail. I'm attaching the patch that skips 3 of them and modifies assertions in one of them, so that the tests pass.

I'm however still unsure about one of the skipped tests, since I'm unsure whether I totally understand what's wrong there - test_gc_ordinary_module_at_shutdown.

My guess is that due to COUNT_ALLOCS causing immortal types, the "final_a" and "final_b" types don't get destroyed on line [1] as they do in builds without COUNT_ALLOCS. AFAICS they are only "un-immortalized" on this line and destroyed during the following loop [2]. The problem here is that the order of destroyed modules is not deterministic, so sometimes the builtins module gets destroyed before the "final_X" and there is no "print" function, which makes the __del__ functions from "final_X" fail. IMO the best thing to do is to just skip this test with COUNT_ALLOCS. But I may be wrong, I don't have a great insight into Python's GC and module unloading.


[1] http://hg.python.org/cpython/annotate/0f48843652b1/Python/import.c#l383
[2] http://hg.python.org/cpython/annotate/0f48843652b1/Python/import.c#l394

----------
messages: 202414
nosy: bkabrda
priority: normal
severity: normal
status: open
title: Test failures with COUNT_ALLOCS
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov  8 15:58:14 2013
From: report at bugs.python.org (Simon Naish)
Date: Fri, 08 Nov 2013 14:58:14 +0000
Subject: [New-bugs-announce] [issue19528] logger.config.fileConfig cant cope
	with files starting	with an 'r' on windows
Message-ID: <1383922694.77.0.246440943969.issue19528@psf.upfronthosting.co.za>


New submission from Simon Naish:

When attempting to use a config file with logging to set up a series of loggers in a script, when running on windows, if the config file name starts with an 'r' then the script fails with the following error:-

 File "C:\Users\simon\Documents\python dev\RepositoryChainPkg\FileLogger.py", line 45, in fileConfig
    logging.config.fileConfig(FileLogger.CONF_FILENAME)
  File "C:\Python27\lib\logging\config.py", line 78, in fileConfig
    handlers = _install_handlers(cp, formatters)
  File "C:\Python27\lib\logging\config.py", line 156, in _install_handlers
    h = klass(*args)
  File "C:\Python27\lib\logging\handlers.py", line 117, in __init__
    BaseRotatingHandler.__init__(self, filename, mode, encoding, delay)
  File "C:\Python27\lib\logging\handlers.py", line 64, in __init__
    logging.FileHandler.__init__(self, filename, mode, encoding, delay)
  File "C:\Python27\lib\logging\__init__.py", line 902, in __init__
    StreamHandler.__init__(self, self._open())
  File "C:\Python27\lib\logging\__init__.py", line 925, in _open
    stream = open(self.baseFilename, self.mode)
IOError: [Errno 22] invalid mode ('a') or filename: 'C:\\Users\\simon\repositoryChainLogging\repo_log.log'

The same script works perfectly on linux and solaris.

Points to note, the config filename (and path) is listed in the error as:-

'C:\\Users\\simon\repositoryChainLogging\repo_log.log'

Yet when it is passed to logging\config.py as parameter fname in function fileConfig it is:-
b'C:\\Users\\simon\\repositoryChainLogging\\repo_log.conf'

In other words the path passed in by the script is correctly seperated and escaped by os.path functions.

However in _install_handlers (line 133 of logging\config.py) the args = eval(args, vars(logging))line (154) gets the path back in this tuple:-

(b'C:\\Users\\snaish.BRIGHTON\repositoryChainLogging\repo_log.log', b'a', 131072,
 10)

Where it has clearly lost some of the escaping, rendering the path useless, since \r is a control character, and therefore invalidates the path.

Therefore at the moment it is impossible to use logging config fiels beginning with r onw windows at the moment.

----------
components: Library (Lib)
messages: 202422
nosy: 51m0n
priority: normal
severity: normal
status: open
title: logger.config.fileConfig cant cope with files starting with an 'r' on windows
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov  8 16:34:39 2013
From: report at bugs.python.org (Michael Haubenwallner)
Date: Fri, 08 Nov 2013 15:34:39 +0000
Subject: [New-bugs-announce] [issue19529] Fix unicode_aswidechar() with
	4byte unicode and 2byte	wchar_t, for AIX
Message-ID: <1383924879.95.0.72869375832.issue19529@psf.upfronthosting.co.za>


New submission from Michael Haubenwallner:

The problem raises during build already when trying to run setup.py, where ./python is unavailable to locate the 'encodings' module and aborts.

It turns out that (some of) the filenames searched for are broken due to wrong conversion from unicode (across wchar_t) to char.

Attached patch is for 3.2 only, should be obvious enough.

Thanks!

----------
components: Interpreter Core
files: python-3.2-aix-unicode_aswidechar.patch
keywords: patch
messages: 202429
nosy: haubi
priority: normal
severity: normal
status: open
title: Fix unicode_aswidechar() with 4byte unicode and 2byte wchar_t, for AIX
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file32544/python-3.2-aix-unicode_aswidechar.patch

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

From report at bugs.python.org  Sat Nov  9 04:57:48 2013
From: report at bugs.python.org (mpb)
Date: Sat, 09 Nov 2013 03:57:48 +0000
Subject: [New-bugs-announce] [issue19530] cross thread shutdown of UDP
	socket exhibits unexpected	behavior
Message-ID: <1383969468.97.0.110285365425.issue19530@psf.upfronthosting.co.za>


New submission from mpb:

I have a multi-threaded application.
A background thread is blocked, having called recvfrom on a UDP socket.
The main thread wants to cause the background thread to unblock.
With TCP sockets, I can achieve this by calling:
sock.shutdown (socket.SHUT_RD)

When I try this with a UDP socket, the thread calling shutdown raises an OS Error (transport end point not connected).

The blocked thread does unblock (which is helpful), but recvform appears to return successfully, returning a zero length byte string, and a bogus address!

(This is the opposite of the TCP case, where the blocked thread raises the exception, and the call to shutdown succeeds.)

In contrast, sock.close does not cause the blocked thread to unblock.  (This is the same for both TCP and UDP sockets.)

I suspect Python is just exposing the underlying C behavior of shutdown and recvfrom.  I'd test it in C, but I'm not fluent in writing multi-threaded code in C.

It would be nice if the recvfrom thread could raise some kind of exception, rather than appearing to return successfully.  It might also be worth reporting this bug upstream (where ever upstream is for recvfrom).  I'm running Python 3.3.1 on Linux.

See also this similar bug.
http://bugs.python.org/issue8831

The Python socket docs could mention that to unblock a reading thread, sockets should be shutdown, not closed.  This might be implied in the current docs, but it could be made explicit.  See:

http://docs.python.org/3/library/socket.html#socket.socket.close

For example, the following sentence could be appended to the Note at the above link.  "Note: (...)  Specifically, in multi-threaded programming, if a thread is blocked performing a read or write on a socket, calling shutdown from another thread will unblock the blocked thread.  Unblocking via shutdown seems to work with TCP sockets, but may result in strange behavior with UDP sockets."

Here is sample Python code that demonstrates the behavior.

import socket, threading, time

sock = socket.socket (socket.AF_INET, socket.SOCK_DGRAM)
sock.bind (('localhost', 8000))

def recvfrom ():
  for i in range (2) :
    print ('recvfrom  blocking ...')
    recv, remote_addr = sock.recvfrom (1024)
    print ('recvfrom  %s  %s' % (recv, remote_addr))

thread = threading.Thread ( target = recvfrom )
thread.start ()
time.sleep (0.5)

sock2 = socket.socket (socket.AF_INET, socket.SOCK_DGRAM)
sock2.sendto (b'test', ('localhost', 8000))

time.sleep (0.5)

try:  sock.shutdown (socket.SHUT_RD)
except OSError as exc :  print ('shutdown  os error  %s' % str (exc))

sock.close ()

thread.join ()
print ('exiting')


----

And here is the output of the above code:

recvfrom  blocking ...
recvfrom  b'test'  ('127.0.0.1', 48671)
recvfrom  blocking ...
shutdown  os error  [Errno 107] Transport endpoint is not connected
recvfrom  b''  (59308, b'\xaa\xe5\xec\xde3\xe6\x82\x02\x00\x00\xa8\xe7\xaa\xe5')
exiting

----------
components: IO
messages: 202457
nosy: mpb
priority: normal
severity: normal
status: open
title: cross thread shutdown of UDP socket exhibits unexpected behavior
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Nov  9 06:57:27 2013
From: report at bugs.python.org (Sworddragon)
Date: Sat, 09 Nov 2013 05:57:27 +0000
Subject: [New-bugs-announce] [issue19531] Loading -OO bytecode files if -O
	was requested can lead	to problems
Message-ID: <1383976647.12.0.628513721742.issue19531@psf.upfronthosting.co.za>


New submission from Sworddragon:

The documentation says that -OO does remove docstrings so applications should be aware of it. But there is also a case where a valid declared docstring isn't accessible anymore if -O is given. First the testcase:

test1.py:

import test2
def test1():
	"""test1"""
print(test1.__doc__)
print(test2.test2.__doc__)


test2.py:

def test2():
	"""test2"""


A simple check will show the current result:

sworddragon at ubuntu:~/tmp$ python3 -BO test1.py
test1
test2


If -OO is given the docstrings will be removed as expected:

sworddragon at ubuntu:~/tmp$ python3 -OO test1.py
None
None


Now we have also bytecode files saved on the disk without any docstrings. But if we try to use only -O the problem appears:

sworddragon at ubuntu:~/tmp$ python3 -O test1.py
test1
None


Even with only -O given we doesn't get the docstring for the imported module. The problem is that Python allows to load -OO bytecode files if -O bytecode was requested. I think the simplest solution would be to name -OO bytecode-files as .pyoo.

----------
components: Interpreter Core
messages: 202462
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Loading -OO bytecode files if -O was requested can lead to problems
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sat Nov  9 07:14:31 2013
From: report at bugs.python.org (Sworddragon)
Date: Sat, 09 Nov 2013 06:14:31 +0000
Subject: [New-bugs-announce] [issue19532] compileall -f doesn't force to
	write bytecode files
Message-ID: <1383977671.71.0.216863733514.issue19532@psf.upfronthosting.co.za>


New submission from Sworddragon:

The force-option from compileall seems not to rebuild the bytecode files if they already exist. Here is an example of 2 calls:

root at ubuntu:~# python3 -m compileall -f
Skipping current directory
Listing '/usr/lib/python3.3'...
Compiling '/usr/lib/python3.3/__phello__.foo.py'...
Compiling '/usr/lib/python3.3/_compat_pickle.py'...
Compiling '/usr/lib/python3.3/_dummy_thread.py'...
...
Compiling '/usr/lib/python3.3/webbrowser.py'...
Compiling '/usr/lib/python3.3/xdrlib.py'...
Compiling '/usr/lib/python3.3/zipfile.py'...
Listing '/usr/lib/python3.3/plat-x86_64-linux-gnu'...
Listing '/usr/lib/python3.3/lib-dynload'...
Listing '/usr/local/lib/python3.3/dist-packages'...
Listing '/usr/lib/python3/dist-packages'...
root at ubuntu:~# python3 -m compileall -f
Skipping current directory
Listing '/usr/lib/python3.3'...
Listing '/usr/lib/python3.3/plat-x86_64-linux-gnu'...
Listing '/usr/lib/python3.3/lib-dynload'...
Listing '/usr/local/lib/python3.3/dist-packages'...
Listing '/usr/lib/python3/dist-packages'...

----------
components: Library (Lib)
messages: 202463
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: compileall -f doesn't force to write bytecode files
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Nov  9 07:54:19 2013
From: report at bugs.python.org (Sworddragon)
Date: Sat, 09 Nov 2013 06:54:19 +0000
Subject: [New-bugs-announce] [issue19533] Unloading docstrings from memory
	if -OO is given
Message-ID: <1383980059.61.0.697157457336.issue19533@psf.upfronthosting.co.za>


New submission from Sworddragon:

Using -OO on a script will remove the __doc__ attributes but the docstrings will still be in the process memory. In the attachments is an example script which demonstrates this with a docstring of ~10 MiB (opening the file in an editor can need some time). Calling "python3 -OO test.py" will result in a memory usage of ~16 MiB on my system (Linux 64 Bit) while test.__doc__ is None.

----------
components: Interpreter Core
files: test.py
messages: 202465
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Unloading docstrings from memory if -OO is given
type: enhancement
versions: Python 3.3
Added file: http://bugs.python.org/file32550/test.py

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

From report at bugs.python.org  Sat Nov  9 09:02:59 2013
From: report at bugs.python.org (Mike FABIAN)
Date: Sat, 09 Nov 2013 08:02:59 +0000
Subject: [New-bugs-announce] [issue19534] normalize() in locale.py fails for
	sr_RS.UTF-8@latin
Message-ID: <1383984179.72.0.86841867315.issue19534@psf.upfronthosting.co.za>


New submission from Mike FABIAN:

Originally reported here: 

https://bugzilla.redhat.com/show_bug.cgi?id=1024667

I found that Serbian translations in Latin do not work when the locale
name is written as sr_RS.UTF-8 at latin (one gets the cyrillic
translations instead), but they *do* work when the locale name is
written as sr_RS at latin (i.e. omitting the '.UTF-8'):

$ LANG='sr_RS.UTF-8'  python2 -c 'import gettext; print(gettext.ldgettext("anaconda", "What language would you like to use during the installation process?").decode("UTF-8"))'
???? ????? ????? ?????? ?? ????????? ????? ??????? ????????????
mfabian at ari:~
$ LANG='sr_RS.UTF-8 at latin'  python2 -c 'import gettext; print(gettext.ldgettext("anaconda", "What language would you like to use during the installation process?").decode("UTF-8"))'
???? ????? ????? ?????? ?? ????????? ????? ??????? ????????????
mfabian at ari:~
$ LANG='sr_RS at latin'  python2 -c 'import gettext; print(gettext.ldgettext("anaconda", "What language would you like to use during the installation process?").decode("UTF-8"))'
Koji jezik biste ?eleli da koristite tokom procesa instalacije?
mfabian at ari:~
$ 

The ?gettext? command line tool does not have this problem:

mfabian at ari:~
$ LANG='sr_RS at latin' gettext anaconda "What language would you like to use during the installation process?"
Koji jezik biste ?eleli da koristite tokom procesa instalacije?mfabian at ari:~
$ LANG='sr_RS.UTF-8 at latin' gettext anaconda "What language would you like to use during the installation process?"
Koji jezik biste ?eleli da koristite tokom procesa instalacije?mfabian at ari:~
$ LANG='sr_RS.UTF-8' gettext anaconda "What language would you like to use during the installation process?"
???? ????? ????? ?????? ?? ????????? ????? ??????? ????????????mfabian at ari:~
$

----------
components: Library (Lib)
messages: 202467
nosy: mfabian
priority: normal
severity: normal
status: open
title: normalize() in locale.py fails for sr_RS.UTF-8 at latin
versions: Python 2.7

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

From report at bugs.python.org  Sat Nov  9 10:21:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Nov 2013 09:21:23 +0000
Subject: [New-bugs-announce] [issue19535] Test failures with -OO
Message-ID: <1383988883.0.0.831312717343.issue19535@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python -OO -m test.regrtest test_docxmlrpc test_functools test_inspect test_pkg
[1/4] test_docxmlrpc
test test_docxmlrpc failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_docxmlrpc.py", line 210, in test_annotations
    response.read())
AssertionError: b'<dl><dt><a name="-annotation"><strong>annotation</strong></a>(x: int)</dt><dd><tt>Use&nbsp;function&nbsp;annotations.</tt></dd></dl>\n<dl><dt><a name="-method_annotation"><strong>method_annotation</strong></a>(x: bytes)</dt></dl>' not found in b'<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">\n<html><head><title>Python: DocXMLRPCServer Test Documentation</title>\n<meta http-equiv="Content-Type" content="text/html; charset=utf-8">\n</head><body bgcolor="#f0f0f8">\n\n<table width="100%" cellspacing=0 cellpadding=2 border=0 summary="heading">\n<tr bgcolor="#7799ee">\n<td valign=bottom>&nbsp;<br>\n<font color="#ffffff" face="helvetica, arial">&nbsp;<br><big><big><strong>DocXMLRPCServer Test Docs</strong></big></big></font></td\n><td align=right valign=bottom\n><font color="#ffffff" face="helvetica, arial">&nbsp;</font></td></tr></table>\n    <p><tt>This&nbsp;is&nbsp;an&nbsp;XML-RPC&nbsp;server\'s&nbsp;documentation,&nbsp;but&nbsp;the&nbsp;server&nbsp;can&nbsp;be&nbsp;used&nbsp;by&nbsp;POSTing&nbsp;to&nbsp;/RPC2.&nbsp;Try&nbsp;self.<strong>add</strong>,&nbsp;too.</tt></p>\n<p>\n<table width="100%" cellspacing=0 cellpadding=2 border=0 summary="section">\n<tr bgcolor="#eeaa77">\n<td colspan=3 valign=bottom>&nbsp;<br>\n<font color="#ffffff" face="helvetica, arial"><big><strong>Methods</strong></big></font></td></tr>\n    \n<tr><td bgcolor="#eeaa77"><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</tt></td><td>&nbsp;</td>\n<td width="100%"><dl><dt><a name="-&lt;lambda&gt;"><strong>&lt;lambda&gt;</strong></a>(x, y)</dt></dl>\n<dl><dt><a name="-add"><strong>add</strong></a>(x, y)</dt></dl>\n<dl><dt><a name="-annotation"><strong>annotation</strong></a>(x: int)</dt></dl>\n<dl><dt><a name="-method_annotation"><strong>method_annotation</strong></a>(x: bytes)</dt></dl>\n<dl><dt><a name="-system.listMethods"><strong>system.listMethods</strong></a>()</dt></dl>\n<dl><dt><a name="-system.methodHelp"><strong>system.methodHelp</strong></a>(method_name)</dt></dl>\n<dl><dt><a name="-system.methodSignature"><strong>system.methodSignature</strong></a>(method_name)</dt></dl>\n</td></tr></table>\n</body></html>'

[2/4/1] test_functools
test test_functools failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_functools.py", line 1127, in test_wrapping_attributes
    self.assertEqual(g.__doc__, "Simple test")
AssertionError: None != 'Simple test'

[3/4/2] test_inspect
test test_inspect failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_inspect.py", line 2528, in test_details
    self.assertIn(module.__cached__, output)
AssertionError: '/home/serhiy/py/cpython/Lib/unittest/__pycache__/__init__.cpython-34.pyo' not found in "Target: unittest\nOrigin: /home/serhiy/py/cpython/Lib/unittest/__init__.py\nCached: /home/serhiy/py/cpython/Lib/unittest/__pycache__/__init__.cpython-34.pyc\nLoader: <_frozen_importlib.SourceFileLoader object at 0xb7041c4c>\nSubmodule search path: ['/home/serhiy/py/cpython/Lib/unittest']\n\n\n"

[4/4/3] test_pkg
1 test OK.
3 tests failed:
    test_docxmlrpc test_functools test_inspect

----------
components: Tests
messages: 202476
nosy: serhiy.storchaka, skrah
priority: normal
severity: normal
status: open
title: Test failures with -OO
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Nov  9 16:15:27 2013
From: report at bugs.python.org (Brandon Rhodes)
Date: Sat, 09 Nov 2013 15:15:27 +0000
Subject: [New-bugs-announce] [issue19536] MatchObject should offer
	__getitem__()
Message-ID: <1384010127.61.0.754728433968.issue19536@psf.upfronthosting.co.za>


New submission from Brandon Rhodes:

Regular expression re.MatchObject objects are sequences.
They contain at least one ?group? string, possibly more,
which are integer-indexed starting at zero.
Today, groups can be accessed in one of two ways.

(1) You can call the method match.group(N).

(2) You can call glist = match.groups()
    and then access each group as glist[N-1].
    Note the obvious off-by-one error:
    .groups() does not include ?group zero?,
    which contains the entire match,
    and therefore its indexes are off-by-one
    from the values you would pass to .group().

I propose that MatchObject gain a __getitem__(N) method
whose return value for every N is the same as .group(N)
as I think that match[N] is a quite obvious syntax for
asking for one particular group of an RE match.

The only objection I can see to this proposal
is the obvious asymmetry between Group Zero and all
subsequent groups of a regular expression pattern:
zero means ?the whole thing? whereas each of the others
holds the content of a particular explicit set of parens.
Looping over the elements match[0], match[1], ... of a
pattern like this:

    r'(\d\d\d\d)/(\d\d)/(\d\d)'

will give you *first* the *entire* match, and only then
turn its attention to the three parenthesized substrings.

My retort is that concentric groups can happen anyway:
that Group Zero, holding the entire match, is not really
as special as the newcomer might suspect, because you can
always wind up with groups inside of other groups; it is
simply part of the semantics of regular expressions that
groups might overlap or might contain one another, as in:

    r'((\d\d)/(\d\d)) Description: (.*)'

Here, we see that concentricity is not a special property
of Group Zero, but in fact something that can happen quite
naturally with other groups.

The caller simply needs to imagine every regular expression
being surrounded by an ?automatic set of parentheses? to
understand where Group Zero comes from, and how it will be
ordered in the resulting sequence of groups relative to
the subordinate groups within the string.

If one or two people voice agreement here in this issue,
I will be very happy to offer a patch.

----------
components: Regular Expressions
messages: 202480
nosy: brandon-rhodes, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: MatchObject should offer __getitem__()
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Nov  9 17:32:08 2013
From: report at bugs.python.org (Andreas Schwab)
Date: Sat, 09 Nov 2013 16:32:08 +0000
Subject: [New-bugs-announce] [issue19537] Fix misalignment in
	fastsearch_memchr_1char
Message-ID: <1384014728.51.0.918202421473.issue19537@psf.upfronthosting.co.za>


New submission from Andreas Schwab:

sizeof(foo) is never a good approximation for the alignment of foo

----------
components: Interpreter Core
files: xx
messages: 202487
nosy: schwab
priority: normal
severity: normal
status: open
title: Fix misalignment in fastsearch_memchr_1char
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file32554/xx

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

From report at bugs.python.org  Sat Nov  9 21:28:24 2013
From: report at bugs.python.org (Thomas Heller)
Date: Sat, 09 Nov 2013 20:28:24 +0000
Subject: [New-bugs-announce] [issue19538] Changed function prototypes in the
	PEP 384 stable ABI
Message-ID: <1384028904.73.0.822920006161.issue19538@psf.upfronthosting.co.za>


New submission from Thomas Heller:

(As requested by email in python-dev I'm reporting this problem)

Some function prototypes in the stable ABI have been changed between Python 3.3 and 3.4.
PyObject_CallFunction is an example, the second parameter has been changed from 'char *' to 'const char *', which leads to compiler warnings in my code.

I admit that my use case is probably weird, but here we go:

I want to embed Python and use the stable ABI (API?) so that I the executable does not have to be recompiled for different Python versions.  I want to link dynamically to the Python runtime (loaded with LoadLibrary on Windows).  Also I do not want in use python3.dll.

To make calling the functions less painful I ended up with the following approach.

My executable is compiled with 'Py_BUILD_CORE' defined so that I can *implement* PyObject_CallFunction myself.  I have a python-dynload.c file which implements the API functions in this way:

#define Py_BUILD_CORE
#include <Python.h>
HMODULE hPyDLL; /* the module handle of a dynamically loaded python3X.dll */

PyObject *PyObject_CallFunction(PyObject *callable, char *format, ...)
{
   /* implement by forwarding to functions in the dynloaded dll */
}

When I compile this code with the Python 3.3 headers, everything is ok.  With the Python 3.4 headers, I get

  source/python-dynload.c(75) : warning C4028: formal parameter 2 different from declaration

When I change the second parameter in the function definition to 'const char *format', the situation reverses, compiling with 3.3 gives the warning but 3.4 is ok.

----------
components: Build
keywords: 3.3regression
messages: 202495
nosy: theller
priority: normal
severity: normal
status: open
title: Changed function prototypes in the PEP 384 stable ABI
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Nov 10 03:51:45 2013
From: report at bugs.python.org (Jan Kaliszewski)
Date: Sun, 10 Nov 2013 02:51:45 +0000
Subject: [New-bugs-announce] [issue19539] The 'raw_unicode_escape' codec
	buggy + not apropriate	for Python 3.x
Message-ID: <1384051905.56.0.969775270474.issue19539@psf.upfronthosting.co.za>


New submission from Jan Kaliszewski:

It seems that the 'raw_unicode_escape' codec:

1) produces data that could be suitable for Python 2.x raw unicode string literals and not for Python 3.x raw unicode string literals (in Python 3.x \u... escapes are also treated literally);

2) seems to be buggy anyway: bytes in range 128-255 are encoded with the 'latin-1' encoding (in Python 3.x it is definitely a bug; and even in Python 2.x the feature is dubious, although at least the Py2's eval() and compile() functions officially accept 'latin-1'-encoded byte strings...).

Python 3.3:

>>> b = "za????".encode('raw_unicode_escape')
>>> literal = b'r"' + b + b'"'
>>> literal
b'r"za\\u017c\xf3\\u0142\\u0107"'
>>> eval(literal)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
SyntaxError: (unicode error) 'utf-8' codec can't decode byte 0xf3 in position 8: invalid continuation byte
>>> b'\xf3'.decode('latin-1')
'?'
>>> b = "za?".encode('raw_unicode_escape')
>>> literal = b'r"' + b + b'"'
>>> literal
b'r"za\\u017c"'
>>> eval(literal)
'za\\u017c'
>>> print(eval(literal))
za\u017c

It believe that the 'raw_unicode_escape' codes should either be deprecated and later removed or be modified to accept only printable ascii characters.


PS. Also, as a side note: neither 'raw_unicode_escape' nor 'unicode_escape' does escape quotes (see issue #7615) -- shouldn't it be at least documented explicitly?

----------
components: Library (Lib), Unicode
messages: 202505
nosy: ezio.melotti, haypo, zuo
priority: normal
severity: normal
status: open
title: The 'raw_unicode_escape' codec buggy + not apropriate for Python 3.x
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Nov 10 05:21:33 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 10 Nov 2013 04:21:33 +0000
Subject: [New-bugs-announce] [issue19540] PEP339: Fix link to Zephyr ASDL
	paper
Message-ID: <1384057293.31.0.135079823938.issue19540@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
assignee: docs at python
components: Documentation
hgrepos: 213
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: PEP339: Fix link to Zephyr ASDL paper

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

From report at bugs.python.org  Sun Nov 10 06:16:58 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 10 Nov 2013 05:16:58 +0000
Subject: [New-bugs-announce] [issue19541] ast.dump(indent=True)
	prettyprinting
Message-ID: <1384060618.33.0.960245227555.issue19541@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

ast.dump needs an indent argument for pretty printing.

  from pprint import pprint as pp
  pp(ast.dump(node))

  "Assign(targets=[Tuple(elts=[Name(id='d', ctx=Store()), Name(id='m', ctx=Store())], ctx=Store())], value=Call(func=Name(id='divmod', ctx=Load()), args=[Call(func=Name(id='len', ctx=Load()), args=[Name(id='seq', ctx=Load())], keywords=[], starargs=None, kwargs=None), Name(id='size', ctx=Load())], keywords=[], starargs=None, kwargs=None))"

----------
assignee: docs at python
components: Documentation
messages: 202506
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: ast.dump(indent=True) prettyprinting

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

From report at bugs.python.org  Sun Nov 10 09:51:04 2013
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 10 Nov 2013 08:51:04 +0000
Subject: [New-bugs-announce] [issue19542] WeakValueDictionary bug in
	setdefault()&pop()
Message-ID: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za>


New submission from Armin Rigo:

WeakValueDictionary.setdefault() contains a bug that shows up in multithreaded situations using reference cycles.  Attached a test case: it is possible for 'setdefault(key, default)' to return None, although None is never put as a value in the dictionary.  (Actually, being a WeakValueDictionary, None is not allowed as a value.)

The reason is that the code in setdefault() ends in "return wr()", but the weakref "wr" might have gone invalid between the time it was fetched from "self.data" and the "wr()" itself, thus returning None.

A similar problem occurs in pop(), leading it to possibly raise KeyError even if it is called with a default argument.

----------
components: Library (Lib)
messages: 202510
nosy: arigo
priority: normal
severity: normal
status: open
title: WeakValueDictionary bug in setdefault()&pop()
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sun Nov 10 10:20:47 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 10 Nov 2013 09:20:47 +0000
Subject: [New-bugs-announce] [issue19543] Add -3 warnings for codec
	convenience method changes
Message-ID: <1384075247.27.0.0100141647279.issue19543@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The long discussion in issue 7475 and some subsequent discussions I had with Armin Ronacher have made it clear to me that the key distinction between the codec systems in Python 2 and Python 3 is the following differences in type signatures of various operations:

Python 2 (8 bit str):

    codecs module: object <-> object
    convenience methods: basestring <-> basestring
    available codecs: unicode <-> str, str <-> str, unicode <-> unicode

Python 3 (Unicode str):

    codecs module: object <-> object
    convenience methods: str <-> bytes
    available codecs: str <-> bytes, bytes <-> bytes, str <-> str

The significant distinction is the fact that, in Python 2, the convenience methods covered all standard library codecs, but for Python 3, the codecs module needs to be used directly for the bytes <-> bytes codecs and the one str <-> str codec (since those codecs no longer satisfy the constraints of the text model related convenience methods).

After attempting to implement a 2to3 fixer for these non-Unicode codecs in issue 17823, I realised that wouldn't really work properly (since it's a data driven error based on the behaviour of the named codec), so I'm rejecting that proposal and replacing it with this one for additional Py3k warnings in Python 2.7.7.

My proposal is to take the following cases and make them produce warnings under Python 2.7.7 when Py3k warnings are enabled (remember, these are the 2.7 types, not the 3.x ones):

- the str.encode method is called (redirect to codecs.encode to handle arbitrary input types in a forward compatible way)

- the unicode.decode method is called (redirect to codecs.decode to handle arbitrary input types)

- PyUnicode_AsEncodedString produces something other than an 8-bit string (redirect to codecs.encode for arbitrary output types)

- PyUnicode_Decode produces something other than a unicode string (redirect to codecs.decode for arbitrary output types)

For the latter two cases, issue 17828 includes updates to the Python 3 error messages to similarly redirect to the convenience functions in the codecs module. However, the removed convenience methods will continue to simply trigger AttributeError in Python 3 with no special casing.

----------
components: Interpreter Core
messages: 202512
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add -3 warnings for codec convenience method changes
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov 10 17:59:52 2013
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 10 Nov 2013 16:59:52 +0000
Subject: [New-bugs-announce] [issue19544] Port distutils as found in Python
	2.7 to Python 3.x.
Message-ID: <1384102792.62.0.350506434661.issue19544@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

Following from issue7457, in which a single feature was identified to have gone missing in 29a3eda89995, this ticket captures the need to bring the Python 3 codebase up to match Python 2.7.

----------
assignee: eric.araujo
components: Distutils
messages: 202534
nosy: eric.araujo, jason.coombs, tarek
priority: normal
severity: normal
status: open
title: Port distutils as found in Python 2.7 to Python 3.x.
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 10 18:03:45 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 10 Nov 2013 17:03:45 +0000
Subject: [New-bugs-announce] [issue19545] time.strptime exception context
Message-ID: <1384103025.17.0.0483523701082.issue19545@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

time.strptime leaks an IndexError, as seen in the following traceback. 

[root at clnstor /tank/libs/cpython]# ./python
Python 3.4.0a4+ (default:0aa2aedc6a21+, Nov  5 2013, 17:10:42)
[GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd8
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strptime('19', '%Y %')
Traceback (most recent call last):
  File "/tank/libs/cpython/Lib/_strptime.py", line 320, in _strptime
    format_regex = _TimeRE_cache.compile(format)
  File "/tank/libs/cpython/Lib/_strptime.py", line 268, in compile
    return re_compile(self.pattern(format), IGNORECASE)
  File "/tank/libs/cpython/Lib/_strptime.py", line 262, in pattern
    self[format[directive_index]])
IndexError: string index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tank/libs/cpython/Lib/_strptime.py", line 494, in _strptime_time
    tt = _strptime(data_string, format)[0]
  File "/tank/libs/cpython/Lib/_strptime.py", line 332, in _strptime
    raise ValueError("stray %% in format '%s'" % format)
ValueError: stray % in format '%Y %'
>>>

The attached patch suppresses the exception. This issue is similar (and based on) the issue17572.

----------
components: Library (Lib)
files: time_strptime.patch
keywords: patch
messages: 202536
nosy: Claudiu.Popa, belopolsky
priority: normal
severity: normal
status: open
title: time.strptime exception context
versions: Python 3.4
Added file: http://bugs.python.org/file32563/time_strptime.patch

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

From report at bugs.python.org  Sun Nov 10 18:16:52 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 10 Nov 2013 17:16:52 +0000
Subject: [New-bugs-announce] [issue19546] configparser leaks implementation
	detail
Message-ID: <1384103812.47.0.904880324738.issue19546@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Various exceptions raised by configparser module leaks implementation detail, by chaining KeyErrors, as seen below:

Python 3.4.0a4+ (default:0aa2aedc6a21+, Nov  5 2013, 17:10:42)
[GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd8
Type "help", "copyright", "credits" or "license" for more information.
>>> import configparser
>>> parser = configparser.ConfigParser()
>>> parser.remove_option('Section1', 'an_int')
Traceback (most recent call last):
  File "/tank/libs/cpython/Lib/configparser.py", line 935, in remove_option
    sectdict = self._sections[section]
KeyError: 'Section1'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tank/libs/cpython/Lib/configparser.py", line 937, in remove_option
    raise NoSectionError(section)
configparser.NoSectionError: No section: 'Section1'
>>>

There are multiple places where this happens: using basic and extended interpolation, using .options to retrieve non-existent options, using .get or .remove_options for non-existent options/sections. The attached patch tries to fixes all those issues by suppressing the initial exception.

----------
components: Library (Lib)
files: configparser.patch
keywords: patch
messages: 202538
nosy: Claudiu.Popa, lukasz.langa
priority: normal
severity: normal
status: open
title: configparser leaks implementation detail
versions: Python 3.4
Added file: http://bugs.python.org/file32564/configparser.patch

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

From report at bugs.python.org  Sun Nov 10 22:31:55 2013
From: report at bugs.python.org (Stefan Richter)
Date: Sun, 10 Nov 2013 21:31:55 +0000
Subject: [New-bugs-announce] [issue19547] HTTPS proxy support missing
	without warning
Message-ID: <1384119115.17.0.177090288449.issue19547@psf.upfronthosting.co.za>


New submission from Stefan Richter:

When using urllib2 and specifying a HTTPS proxy when setting up a ProxyHandler, the library does not encrypt the traffic sent to the proxy server. This results in unpredictable behavior.

Either the support should be implemented or an error raised

----------
components: Library (Lib)
messages: 202575
nosy: 02strich
priority: normal
severity: normal
status: open
title: HTTPS proxy support missing without warning
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov 11 02:29:13 2013
From: report at bugs.python.org (Jan Kaliszewski)
Date: Mon, 11 Nov 2013 01:29:13 +0000
Subject: [New-bugs-announce] [issue19548] 'codecs' module docs improvements
Message-ID: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za>


New submission from Jan Kaliszewski:

When learning about the 'codecs' module I encountered several places in the docs of the module that, I believe, could be improved to be clearer and easier for codecs-begginers: 

1. Ad `codecs.encode` and `codecs.decode` descriptions: I believe it would be worth to mention that, unlike str.encode()/bytes.decode(), these functions (and all their counterparts in the classes the module contains) support not only "traditional str/bytes encodings", but also bytes-to-bytes as well as str-to-str encodings. 

2. Ad 'codecs.register': in two places there is such a text: `These have to be factory functions providing the following interface: factory([...] errors='strict')` -- `errors='strict'` may be confusing (at the first sight it may suggest that the only valid value is 'strict'; maybe `factory(errors=<error handler label>)` with an appropriate description below would be better?).

3. Ad `codecs.open`: I believe there should be a reference to the built-in open() as an alternative that is better is most cases.

4. Ad `codecs.BOM*`: `These constants define various encodings of the Unicode byte order mark (BOM).` -- the world `encodings` seems to be confusing here; maybe `These constants define various byte sequences being Unicode byte order marks (BOMs) for several encodings. They are used...` would be better?

5. Ad `7.2.1. Codec Base Classes` + `codecs.IncrementalEncoder`/`codecs/IncrementalDecoder`:
  * `Each codec has to define four interfaces to make it usable as codec in Python: stateless encoder, stateless decoder, stream reader and stream writer` -- only four? Not six? What about incremental encoder/decoder???
  * Comparing the fragments (and tables) about error halding methods (Codecs Base Classes, IncrementalEncoder, IncrementalDecoder) with similar fragment in the `codecs.register` description and with the `codecs.register_error` description I was confused: is it the matter of a particular codec implementation or of a registered error handler to implement a particular way of error handling? I believe it would be worth to describe clearly relations between these elements of the API. Also more detailed description of differences beetween error handling for encoding and decoding, and translation would be a good thing. 

6. Ad `7.2.1.6. StreamReaderWriter Objects` and `7.2.1.7. StreamRecoder Objects`: It would be worth to say explicitly that, contrary to previously described abstract classes (IncrementalEncoder/Decoder, StreamReader/Writer), these classes are *concrete* ones (if I understand it correctly).

7. Ad `7.2.4. Python Specific Encodings`:
  * `raw_unicode_encoding` -- see: ticket #19539.
  * `unicode_encoding` -- `Produce a string that is suitable as Unicode literal in Python source code` but it is *not* a string; it's a *bytes* object (which could be used in source code using an `ascii`-compatibile encoding).
  * `bytes-to-bytes` and `str-to-str` encodings -- maybe it would be nice to mention that these encodings cannot be used with str.encode()/bytes.decode() methods (and to mention again they *can* be used with the functions/method provided by the `codecs` module).

----------
assignee: docs at python
components: Documentation
messages: 202593
nosy: docs at python, zuo
priority: normal
severity: normal
status: open
title: 'codecs' module docs improvements
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/issue19548>
_______________________________________

From report at bugs.python.org  Mon Nov 11 05:47:08 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 11 Nov 2013 04:47:08 +0000
Subject: [New-bugs-announce] [issue19549] PKG-INFO is created with CRLF on
	Windows
Message-ID: <1384145228.19.0.594572636685.issue19549@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

When packaging on Windows, sdist creates PKG-INFO, which is different in linefeeds. It will be better if this is consistent between platforms.

----------
assignee: eric.araujo
components: Distutils, Distutils2
messages: 202602
nosy: alexis, eric.araujo, tarek, techtonik
priority: normal
severity: normal
status: open
title: PKG-INFO is created with CRLF on Windows
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Nov 11 11:33:15 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 11 Nov 2013 10:33:15 +0000
Subject: [New-bugs-announce] [issue19550] PEP 453: Windows installer
	integration
Message-ID: <1384165995.98.0.0533035404084.issue19550@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Part of the PEP 453 implementation as tracked in issue 19347.

This issue covers the Windows installer updates:

* new option to choose whether or not to invoke "python -m ensurepip --upgrade" on the just installed Python

* also add the result of calling 'sysconfig.get_path("scripts")' to PATH when PATH modification is enabled in the installer

----------
assignee: loewis
components: Windows
messages: 202610
nosy: larry, loewis, ncoghlan
priority: release blocker
severity: normal
status: open
title: PEP 453: Windows installer integration
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 11 11:34:55 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 11 Nov 2013 10:34:55 +0000
Subject: [New-bugs-announce] [issue19551] PEP 453: Mac OS X installer
	integration
Message-ID: <1384166095.93.0.842869053252.issue19551@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Part of the PEP 453 implementation as tracked in issue 19347.

This issue covers the Mac OS X installer update to include a new option to choose whether or not to invoke "python -m ensurepip --upgrade" on the just installed Python.

----------
assignee: ned.deily
components: Macintosh
messages: 202611
nosy: larry, ncoghlan, ned.deily
priority: release blocker
severity: normal
stage: needs patch
status: open
title: PEP 453: Mac OS X installer integration
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 11 11:46:02 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 11 Nov 2013 10:46:02 +0000
Subject: [New-bugs-announce] [issue19552] PEP 453: venv module and pyvenv
	integration
Message-ID: <1384166762.42.0.483253842263.issue19552@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Part of the PEP 453 implementation as tracked in issue 19347.

This issue covers the venv module and pyvenv CLI updates:

* Add a "with_pip=False" parameter to venv.EnvBuilder and venv.create

* When with_pip is a true value, invoke ensurepip.bootstrap with the root set to the just created venv and default_pip set to True

* update pyvenv to pass with_pip=True by default

* add a --without-pip option to pyvenv to pass with_pip=False instead

----------
messages: 202612
nosy: larry, ncoghlan
priority: release blocker
severity: normal
stage: needs patch
status: open
title: PEP 453: venv module and pyvenv integration
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 11 12:39:39 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 11 Nov 2013 11:39:39 +0000
Subject: [New-bugs-announce] [issue19553] PEP 453: "make install" and "make
	altinstall" integration
Message-ID: <1384169979.63.0.863929512032.issue19553@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Part of the PEP 453 implementation as tracked in issue 19347.

This issue covers the integration of ensurepip with "make install" (running "python -m ensurepip") and "make altinstall" (running "python -m ensurepip --altinstall")

----------
components: Build
messages: 202616
nosy: larry, ncoghlan
priority: release blocker
severity: normal
stage: needs patch
status: open
title: PEP 453: "make install" and "make altinstall" integration
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 11 13:29:49 2013
From: report at bugs.python.org (William Grzybowski)
Date: Mon, 11 Nov 2013 12:29:49 +0000
Subject: [New-bugs-announce] [issue19554] Enable all freebsd* host platforms
Message-ID: <1384172989.4.0.879301350688.issue19554@psf.upfronthosting.co.za>


New submission from William Grzybowski:

Hello,

Currently python setup.py restricts FreeBSD host platform by version, e.g. freebsd7, freebsd8.

It is not only out-of-date (we already are on freebsd11) but also doesn't seem to have a good reason to do so.

Proposed patches replaces it with startswith('freebsd').

Thanks

----------
components: Build
files: tip.patch
keywords: patch
messages: 202621
nosy: wg
priority: normal
severity: normal
status: open
title: Enable all freebsd* host platforms
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file32573/tip.patch

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

From report at bugs.python.org  Mon Nov 11 18:29:57 2013
From: report at bugs.python.org (Marc Abramowitz)
Date: Mon, 11 Nov 2013 17:29:57 +0000
Subject: [New-bugs-announce] [issue19555] "SO" config var not getting set
Message-ID: <1384190997.66.0.0919139722211.issue19555@psf.upfronthosting.co.za>


New submission from Marc Abramowitz:

I just installed Python 3.0a4 from source on an Ubuntu system and noticed that it doesn't seem to set the distutils.sysconfig config var: "SO":

```
vagrant at ubuntu:~/src/Python-3.4.0a4$ python3.4
Python 3.4.0a4 (default, Nov 11 2013, 17:11:59)
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from distutils import sysconfig
>>> sysconfig.get_config_var("SO")
>>> sysconfig.get_config_var("SO") is None
True
```

This worked fine for me in Python 3.3:

```
vagrant at ubuntu:~/src/Python-3.4.0a4$ python3.3
Python 3.3.2 (default, May 16 2013, 18:32:41)
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from distutils import sysconfig
>>> sysconfig.get_config_var("SO")
'.so'
```

----------
assignee: eric.araujo
components: Distutils
messages: 202634
nosy: Marc.Abramowitz, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: "SO" config var not getting set
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 12 01:49:44 2013
From: report at bugs.python.org (Takayuki SHIMIZUKAWA)
Date: Tue, 12 Nov 2013 00:49:44 +0000
Subject: [New-bugs-announce] [issue19556] A missing link to
	Python-2.7.6.tar.bz2 in Download page.
Message-ID: <1384217384.48.0.91002834493.issue19556@psf.upfronthosting.co.za>


New submission from Takayuki SHIMIZUKAWA:

http://python.org/download/ have a link to "Python 2.7.6 bzipped source tarball (for Linux, Unix or Mac OS X, more compressed)", but Python-2.7.6.tar.bz2 that is linked is not exist.

Thanks.

----------
components: Build
messages: 202665
nosy: benjamin.peterson, shimizukawa
priority: normal
severity: normal
status: open
title: A missing link to Python-2.7.6.tar.bz2 in Download page.
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov 12 07:52:24 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 12 Nov 2013 06:52:24 +0000
Subject: [New-bugs-announce] [issue19557] ast - docs for every node type are
	missing
Message-ID: <1384239144.67.0.857427270426.issue19557@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

http://docs.python.org/2/library/ast.html

AST module doc is incomplete. To write node visitor, you need to know possible types of parameters and expected values for every node type. They are different.

http://hg.python.org/cpython/file/1ee45eb6aab9/Parser/Python.asdl

For example, visit_Assign expects:
 Assign(targets, value)
   `targets` can be List, Tuple or Name

When there is List, and when there is Tuple? It should be documented.

----------
assignee: docs at python
components: Devguide, Documentation
messages: 202675
nosy: docs at python, ezio.melotti, techtonik
priority: normal
severity: normal
status: open
title: ast - docs for every node type are missing

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

From report at bugs.python.org  Tue Nov 12 09:25:18 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 12 Nov 2013 08:25:18 +0000
Subject: [New-bugs-announce] [issue19558] Provide Tcl/Tk linkage information
	for extension module	builds
Message-ID: <1384244718.62.0.601132485199.issue19558@psf.upfronthosting.co.za>


New submission from Ned Deily:

In Issue 19490, Piet van Oostrum suggested:
"I think future versions of Python should add the relevant information about how they are linked to Tcl/Tk in sysconfig. This would include the path of the include files, the shared libraries and the tcl files. Or a framework location on OS X if this is used. The setup.py for extensions that need to link to Tcl/Tk can then interrogate this information, and fall back to the current way, if it is not available."

Ned Deily replied:
"Piet, yes, I've been thinking of how to do that.  Unfortunately, it can only be a hint since, in the case of an "installer" Python, there is no guarantee that the header files on the build machine are available on the installed machine in the same location or even at all."

----------
components: Build
messages: 202678
nosy: ned.deily, pietvo
priority: normal
severity: normal
status: open
title: Provide Tcl/Tk linkage information for extension module builds
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Nov 12 14:13:09 2013
From: report at bugs.python.org (Mark Richman)
Date: Tue, 12 Nov 2013 13:13:09 +0000
Subject: [New-bugs-announce] [issue19559] Interactive interpreter crashes
	after any two commands
Message-ID: <1384261989.27.0.967760332041.issue19559@psf.upfronthosting.co.za>


New submission from Mark Richman:

On Mac OS X 10.9 (Mavericks), I open the python3 command line interpreter, enter any two commands (enter after each), and I get a Segmentation Fault: 11. This *could* be an issue with readline, but I'm not sure.

Example:

Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> help
Type help() for interactive help, or help(object) for help about object.
>>> help
Segmentation fault: 11

Attached is the error report.

----------
components: Interpreter Core
files: segfault.txt
messages: 202685
nosy: mrichman
priority: normal
severity: normal
status: open
title: Interactive interpreter crashes after any two commands
type: crash
versions: Python 3.3
Added file: http://bugs.python.org/file32583/segfault.txt

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

From report at bugs.python.org  Tue Nov 12 14:33:52 2013
From: report at bugs.python.org (Tom Lynn)
Date: Tue, 12 Nov 2013 13:33:52 +0000
Subject: [New-bugs-announce] [issue19560] PEP 8 operator precedence across
	parens
Message-ID: <1384263232.23.0.922688589796.issue19560@psf.upfronthosting.co.za>


New submission from Tom Lynn:

PEP 8 currently has::

  Yes::

      ...
      c = (a+b) * (a-b)

  No::

      ...
      c = (a + b) * (a - b)

That looks wrong to me -- surely the parens are a sufficient
precedence hint, and don't need further squashing inside?
This will be worse with any non-trivial example.  I suspect
it may also lead to silly complications in code formatting tools.

This was changed by Guido as part of a reversion in issue 16239,
but I wonder whether that example was intended to be included?

----------
assignee: docs at python
components: Documentation
messages: 202687
nosy: docs at python, tlynn
priority: normal
severity: normal
status: open
title: PEP 8 operator precedence across parens
type: enhancement

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

From report at bugs.python.org  Tue Nov 12 15:39:41 2013
From: report at bugs.python.org (Richard PALO)
Date: Tue, 12 Nov 2013 14:39:41 +0000
Subject: [New-bugs-announce] [issue19561] request to reopen Issue837046 -
	pyport.h redeclares	gethostname() if SOLARIS is defined
Message-ID: <1384267181.39.0.791538142123.issue19561@psf.upfronthosting.co.za>


New submission from Richard PALO:

I'd like to have reopened this previous issue as it is still very much the case.

I believe as well that the common distros (I can easily verify OpenIndiana and OmniOS) patch it out (patch file attached). 
Upstream/oracle/userland-gate seems to as well.

It is time to retire this check, or at least take into consideration the parametrization from unistd.h:

#if defined(_XPG4_2)
extern int gethostname(char *, size_t);
#elif  !defined(__XOPEN_OR_POSIX) || defined(__EXTENSIONS__)
extern int gethostname(char *, int);
#endif

----------
components: Build
files: Python26-10-gethostname.patch
keywords: patch
messages: 202690
nosy: risto3
priority: normal
severity: normal
status: open
title: request to reopen Issue837046 - pyport.h redeclares gethostname() if SOLARIS is defined
type: compile error
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file32584/Python26-10-gethostname.patch

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

From report at bugs.python.org  Tue Nov 12 18:40:59 2013
From: report at bugs.python.org (Srinivas Reddy T)
Date: Tue, 12 Nov 2013 17:40:59 +0000
Subject: [New-bugs-announce] [issue19562] Added description for assert
	statement
Message-ID: <1384278059.69.0.538735147491.issue19562@psf.upfronthosting.co.za>


New submission from Srinivas  Reddy T:

Added descriptive message to assert statement in datetime module.
Since _check_date_fields does the job of data integrity, i did not check for ValueError, TypeError checks in the function.

However, i am not sure of the adding descriptive messages to the other assert statements like, assert seconds == int(seconds). And isn't this too much defensive programming?

----------
components: Library (Lib)
files: datetime.patch
keywords: patch
messages: 202708
nosy: thatiparthy
priority: normal
severity: normal
status: open
title: Added description for assert statement
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file32588/datetime.patch

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

From report at bugs.python.org  Tue Nov 12 20:16:07 2013
From: report at bugs.python.org (Srinivas Reddy T)
Date: Tue, 12 Nov 2013 19:16:07 +0000
Subject: [New-bugs-announce] [issue19563] Changing barry's email to
	barry@python.org
Message-ID: <1384283767.67.0.793092256619.issue19563@psf.upfronthosting.co.za>


New submission from Srinivas  Reddy T:

Updated to barry's new email address.

----------
components: Tests
files: barry_email.patch
keywords: patch
messages: 202714
nosy: thatiparthy
priority: normal
severity: normal
status: open
title: Changing barry's email  to barry at python.org
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file32589/barry_email.patch

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

From report at bugs.python.org  Tue Nov 12 23:06:31 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Nov 2013 22:06:31 +0000
Subject: [New-bugs-announce] [issue19564] test_multiprocessing_spawn
Message-ID: <1384293991.33.0.242857083412.issue19564@psf.upfronthosting.co.za>


New submission from STINNER Victor:

test_multiprocessing_spawn.test_context() hanged on x86 Gentoo Non-Debug 3.x:

    def test_context(self):
        if self.TYPE == 'processes':
            L = list(range(10))
            expected = [sqr(i) for i in L]
            with multiprocessing.Pool(2) as p:
                r = p.map_async(sqr, L)
                self.assertEqual(r.get(), expected)   <=== HERE === 
            self.assertRaises(ValueError, p.map_async, sqr, L)

http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/5424/steps/test/logs/stdio

[ 35/385] test_multiprocessing_spawn
Timeout (1:00:00)!
Thread 0xb27fdb40 (most recent call first):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/connection.py", line 384 in _recv
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/connection.py", line 407 in _recv_bytes
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/connection.py", line 251 in recv
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 415 in _handle_results
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 869 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 921 in _bootstrap_inner
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 889 in _bootstrap

Thread 0xb2ffeb40 (most recent call first):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 290 in wait
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/queue.py", line 167 in get
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 371 in _handle_tasks
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 869 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 921 in _bootstrap_inner
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 889 in _bootstrap

Thread 0xb37ffb40 (most recent call first):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 362 in _handle_workers
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 869 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 921 in _bootstrap_inner
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 889 in _bootstrap

Thread 0xb417fb40 (most recent call first):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/connection.py", line 384 in _recv
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/connection.py", line 407 in _recv_bytes
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/connection.py", line 251 in recv
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 415 in _handle_results
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 869 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 921 in _bootstrap_inner
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 889 in _bootstrap

Thread 0xb520fb40 (most recent call first):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 290 in wait
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/queue.py", line 167 in get
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 371 in _handle_tasks
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 869 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 921 in _bootstrap_inner
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 889 in _bootstrap

Thread 0xb5a10b40 (most recent call first):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 362 in _handle_workers
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 869 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 921 in _bootstrap_inner
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 889 in _bootstrap

Thread 0xb76196c0 (most recent call first):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 290 in wait
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/threading.py", line 553 in wait
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 585 in wait
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/multiprocessing/pool.py", line 588 in get
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/_test_multiprocessing.py", line 1786 in test_context
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/case.py", line 571 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/case.py", line 610 in __call__
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/suite.py", line 117 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/suite.py", line 79 in __call__
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/suite.py", line 117 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/suite.py", line 79 in __call__
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/suite.py", line 117 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/suite.py", line 79 in __call__
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/unittest/runner.py", line 168 in run
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/support/__init__.py", line 1661 in _run_suite
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/support/__init__.py", line 1695 in run_unittest
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/regrtest.py", line 1275 in <lambda>
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/regrtest.py", line 1276 in runtest_inner
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/regrtest.py", line 965 in runtest
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/regrtest.py", line 761 in main
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/regrtest.py", line 1560 in main_in_temp_cwd
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/__main__.py", line 3 in <module>
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/runpy.py", line 73 in _run_code
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/runpy.py", line 160 in _run_module_as_main
make: *** [buildbottest] Error 1

----------
components: Tests
messages: 202724
nosy: haypo, sbt
priority: normal
severity: normal
status: open
title: test_multiprocessing_spawn
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 12 23:11:38 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Nov 2013 22:11:38 +0000
Subject: [New-bugs-announce] [issue19565] test_multiprocessing_spawn:
	RuntimeError and assertion	error on windows xp buildbot
Message-ID: <1384294298.49.0.172308180032.issue19565@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Since the changeset c2a13acd5e2b24560419b93180ee49d1a4839b92 ("Close #19466: Clear the frames of daemon threads earlier during the Python shutdown to call objects destructors"), test_multiprocessing_spawn now show RuntimeError and a child process crashs with an assertion error on windows xp buildbot.

http://buildbot.python.org/all/builders/x86 XP-4 3.x/builds/9538/steps/test/logs/stdio

[ 71/385] test_multiprocessing_spawn
RuntimeError: I/O operations still in flight while destroying Overlapped object, the process may crash
RuntimeError: I/O operations still in flight while destroying Overlapped object, the process may crash
RuntimeError: I/O operations still in flight while destroying Overlapped object, the process may crash
RuntimeError: I/O operations still in flight while destroying Overlapped object, the process may crash
RuntimeError: I/O operations still in flight while destroying Overlapped object, the process may crash
RuntimeError: I/O operations still in flight while destroying Overlapped object, the process may crash
RuntimeError: I/O operations still in flight while destroying Overlapped object, the process may crash
RuntimeError: I/O operations still in flight while destroying Overlapped object, the process may crash
RuntimeError: I/O operations still in flight while destroying Overlapped object, the process may crash
RuntimeError: I/O operations still in flight while destroying Overlapped object, the process may crash
RuntimeError: I/O operations still in flight while destroying Overlapped object, the process may crash
Assertion failed: !PyErr_Occurred(), file ..\Python\ceval.c, line 4077

----------
messages: 202725
nosy: gvanrossum, haypo, neologix, sbt
priority: normal
severity: normal
status: open
title: test_multiprocessing_spawn: RuntimeError and assertion error on windows xp buildbot
versions: Python 3.4

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

From report at bugs.python.org  Wed Nov 13 01:19:37 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Nov 2013 00:19:37 +0000
Subject: [New-bugs-announce] [issue19566] ERROR:
	test_close	(test.test_asyncio.test_unix_events.FastChildWatcherTests)
Message-ID: <1384301977.23.0.703867213373.issue19566@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The following test of test_asyncio failed once. I didn't check if it failed more than once on this buildbot.

The cleanup code is not safe, it should handle errors correctly, so following tests would not fail.

http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/5421/steps/test/logs/stdio

======================================================================
ERROR: test_close (test.test_asyncio.test_unix_events.FastChildWatcherTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/asyncio/unix_events.py", line 662, in _do_waitpid_all
    callback, args = self._callbacks.pop(pid)
KeyError: 7673

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_asyncio/test_unix_events.py", line 723, in setUp
    self.watcher = self.create_watcher(self.loop)
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_asyncio/test_unix_events.py", line 1466, in create_watcher
    return unix_events.FastChildWatcher(loop)
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/asyncio/unix_events.py", line 596, in __init__
    super().__init__(loop)
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/asyncio/unix_events.py", line 474, in __init__
    self.set_loop(loop)
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/asyncio/unix_events.py", line 498, in set_loop
    self._do_waitpid_all()
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/asyncio/unix_events.py", line 665, in _do_waitpid_all
    with self._lock:
AttributeError: 'FastChildWatcher' object has no attribute '_lock'


Following tests fail like that:

======================================================================
FAIL: test_create_watcher (test.test_asyncio.test_unix_events.FastChildWatcherTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_asyncio/test_unix_events.py", line 718, in setUp
    assert ChildWatcherTestsMixin.instance is None
AssertionError

----------
messages: 202727
nosy: gvanrossum, haypo
priority: normal
severity: normal
status: open
title: ERROR: test_close (test.test_asyncio.test_unix_events.FastChildWatcherTests)
versions: Python 3.4

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

From report at bugs.python.org  Wed Nov 13 06:20:58 2013
From: report at bugs.python.org (adamhj)
Date: Wed, 13 Nov 2013 05:20:58 +0000
Subject: [New-bugs-announce] [issue19567] mimetypes.init() raise unhandled
	excption in windows
Message-ID: <1384320058.03.0.631626483584.issue19567@psf.upfronthosting.co.za>


New submission from adamhj:

my system is windows 2k3 sp2, python version is 2.7.6

i found this bug when trying to install the newest setuptools

------------------------------------------------------------------------
X:\xxx>ez_setup.py
Extracting in d:\docume~1\xxx\locals~1\temp\tmpcyxs8s
Now working in d:\docume~1\xxx\locals~1\temp\tmpcyxs8s\setuptools-1.3.2
Installing Setuptools
Traceback (most recent call last):
  File "setup.py", line 17, in <module>
    exec(init_file.read(), command_ns)
  File "<string>", line 8, in <module>
  File "d:\docume~1\xxx\locals~1\temp\tmpcyxs8s\setuptools-1.3.2\setuptools\__init__.py", line 11, in <module>
    from setuptools.extension import Extension
  File "d:\docume~1\xxx\locals~1\temp\tmpcyxs8s\setuptools-1.3.2\setuptools\extension.py", line 5, in <module>
    from setuptools.dist import _get_unpatched
  File "d:\docume~1\xxx\locals~1\temp\tmpcyxs8s\setuptools-1.3.2\setuptools\dist.py", line 15, in <module>
    from setuptools.compat import numeric_types, basestring
  File "d:\docume~1\xxx\locals~1\temp\tmpcyxs8s\setuptools-1.3.2\setuptools\compat.py", line 19, in <module>
    from SimpleHTTPServer import SimpleHTTPRequestHandler
  File "D:\Python27\lib\SimpleHTTPServer.py", line 27, in <module>
    class SimpleHTTPRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler):
  File "D:\Python27\lib\SimpleHTTPServer.py", line 208, in SimpleHTTPRequestHandler
    mimetypes.init() # try to read system mime.types
  File "D:\Python27\lib\mimetypes.py", line 358, in init
    db.read_windows_registry()
  File "D:\Python27\lib\mimetypes.py", line 258, in read_windows_registry
    for subkeyname in enum_types(hkcr):
  File "D:\Python27\lib\mimetypes.py", line 249, in enum_types
    ctype = ctype.encode(default_encoding) # omit in 3.x!
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 33: ordinal not in range(128)
Something went wrong during the installation.
See the error message above.
------------------------------------------------------------------------

then i see into the code, the exception is raised in this function

------------------------------------------------------------------------
        def enum_types(mimedb):
            i = 0
            while True:
                try:
                    ctype = _winreg.EnumKey(mimedb, i)
                except EnvironmentError:
                    break
                try:
                    ctype = ctype.encode(default_encoding) # omit in 3.x!
                except UnicodeEncodeError:
                    pass
                else:
                    yield ctype
                i += 1
------------------------------------------------------------------------

i checked my registry, there is an key in HKCR whose name is in Chinese(encoding GBK), which causes this problem(btw, the default_encoding is 'ascii', assigned from sys.getdefaultencoding())

i don't know is it legal to use a non-ascii string as the name of a registry key in windows, but i think there is some problem in these piece of code. why the variable ctype need to be decoded here? i checked the _winreg.EnumKey() function, it returns byte string:

>>> _winreg.EnumKey(key,8911)
'\xbb\xad\xb0\xe5\xa1\xa3\xce\xc4\xb5\xb5'
#this is the problem key which cause the exception

so python tries to encode it(with ascii encoding) first, and then the exception is raised(and unhandled)

shouldn't we just remove the try..encode..except paragraph?

----------
components: Library (Lib)
messages: 202731
nosy: adamhj
priority: normal
severity: normal
status: open
title: mimetypes.init() raise unhandled excption in windows
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 13 13:20:40 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Nov 2013 12:20:40 +0000
Subject: [New-bugs-announce] [issue19568] bytearray_setslice_linear() leaves
	the bytearray in an	inconsistent state on memory allocation failure
Message-ID: <1384345240.98.0.498941020154.issue19568@psf.upfronthosting.co.za>


New submission from STINNER Victor:

When bytearray_setslice_linear() is called to shrink the buffer with lo=0 and PyByteArray_Resize() fails because of a memory error, the bytearray is leaved in an inconsistent state: ob_start has been updated but not the size.

I found the issue using failmalloc: test_nonblock_pipe_write_smallbuf() of test_io does fail with an assertion error when testing the _pyio module which uses bytearray for the write buffer.

Attached patch restores the bytearray in its previous state if PyByteArray_Resize() failed.

I prefer to only fix the issue in Python 3.4 because it is unlikely and I prefer to not introduce regressions in previous Python versions.


I made a similar fix for list:

changeset:   84717:3f25a7dd8346
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Fri Jul 19 23:06:21 2013 +0200
files:       Objects/listobject.c
description:
Issue #18408: Fix list_ass_slice(), handle list_resize() failure

I tested the patch manually by injecting a fault using gdb: list items are correctly restored on failure.

----------
files: bytearray_setslice_mem_error.patch
keywords: patch
messages: 202736
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: bytearray_setslice_linear() leaves the bytearray in an inconsistent state on memory allocation failure
versions: Python 3.4
Added file: http://bugs.python.org/file32593/bytearray_setslice_mem_error.patch

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

From report at bugs.python.org  Wed Nov 13 14:11:16 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Nov 2013 13:11:16 +0000
Subject: [New-bugs-announce] [issue19569] Use __attribute__((deprecated)) to
	warn usage of	deprecated functions and macros
Message-ID: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Python C API evolves. For example, the Unicode type has been rewriten for scratch to use a more efficient design. Would it be possible to mark deprecated functions as deprecated, so users will be noticed that the API evolved and Python has better functions?

For example, PyUnicode_GET_SIZE() is deprecated and returns a different value than PyUnicode_GET_LENGTH() if wchar_t size is 16-bit (ex: Windows and AIX).

GCC has an nice __attribute__((deprecated)) to tag functions.

----------
messages: 202740
nosy: haypo
priority: normal
severity: normal
status: open
title: Use __attribute__((deprecated)) to warn usage of deprecated functions and macros
versions: Python 3.4

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

From report at bugs.python.org  Wed Nov 13 14:11:57 2013
From: report at bugs.python.org (Sascha Peilicke)
Date: Wed, 13 Nov 2013 13:11:57 +0000
Subject: [New-bugs-announce] [issue19570] distutils' Command.ensure_dirname
	fails on Unicode
Message-ID: <1384348317.37.0.567121673163.issue19570@psf.upfronthosting.co.za>


New submission from Sascha Peilicke:

Encountered an isssue with Unicode paths when invoking Sphinx' distutils command (i.e. 'setup.py build_sphinx'): 

$ python setup.py build_sphinx
running build_sphinx
error: 'source_dir' must be a directory name (got `doc/source`)

...
(Pdb) l
 96                 for root, dirnames, filenames in os.walk(guess):
 97                     if 'conf.py' in filenames:
 98                         return root
 99             return None
100     
101  ->     def finalize_options(self):
102             if self.source_dir is None:
103                 self.source_dir = self._guess_source_dir()
104                 self.announce('Using source directory %s' % self.source_dir)
105             self.ensure_dirname('source_dir')
106             if self.source_dir is None:
(Pdb) n
> /usr/lib/python2.7/site-packages/sphinx/setup_command.py(102)finalize_options()
-> if self.source_dir is None:
(Pdb) n
> /usr/lib/python2.7/site-packages/sphinx/setup_command.py(105)finalize_options()
-> self.ensure_dirname('source_dir')
(Pdb) s
--Call--
> /usr/lib64/python2.7/distutils/cmd.py(266)ensure_dirname()
-> def ensure_dirname(self, option):
(Pdb) s
...
--Call--
> /usr/lib64/python2.7/distutils/cmd.py(253)_ensure_tested_string()
-> def _ensure_tested_string(self, option, tester,
(Pdb) 
> /usr/lib64/python2.7/distutils/cmd.py(255)_ensure_tested_string()
-> val = self._ensure_stringlike(option, what, default)


Command.ensure_dirname (likewise ensure_filename) fails because _ensure_stringlike only tests for isistance(..., str) rather than isinstance(..., types.StringTypes).

----------
components: Distutils
files: distutils-ensure_stringlike-unicode.patch
keywords: patch
messages: 202741
nosy: saschpe
priority: normal
severity: normal
status: open
title: distutils' Command.ensure_dirname fails on Unicode
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file32594/distutils-ensure_stringlike-unicode.patch

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

From report at bugs.python.org  Wed Nov 13 15:07:14 2013
From: report at bugs.python.org (stutiredboy)
Date: Wed, 13 Nov 2013 14:07:14 +0000
Subject: [New-bugs-announce] [issue19571] urlparse.parse_qs with empty string
Message-ID: <1384351634.39.0.133564903051.issue19571@psf.upfronthosting.co.za>


New submission from stutiredboy:

>>> import urlparse
>>> urlparse.parse_qs('a=&b=1')
{'b': ['1']}
>>> 

why not:

{'a' : [''], 'b' : ['1']}

is this a bug?

----------
components: Library (Lib)
messages: 202751
nosy: stutiredboy
priority: normal
severity: normal
status: open
title: urlparse.parse_qs with empty string
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 13 18:18:58 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 13 Nov 2013 17:18:58 +0000
Subject: [New-bugs-announce] [issue19572] Report more silently skipped tests
	as skipped
Message-ID: <1384363138.24.0.069015771908.issue19572@psf.upfronthosting.co.za>


New submission from Zachary Ware:

(Nosy list copied from #18702)

Grepping for "^\s+return$" and "^\s+pass$" in Lib/test turned up several more tests that are silently skipped (along with many legitimate uses of each).  The attached patch turns each into a skip in a few various ways, including splitting a test into two tests in a couple of cases.

I'll make a few comments on Rietveld myself to point out places where I would really like some extra scrutiny.

----------
components: Tests
files: skiptest_not_return_or_pass.diff
keywords: patch
messages: 202762
nosy: ezio.melotti, haypo, michael.foord, ned.deily, pitrou, serhiy.storchaka, terry.reedy, vajrasky, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Report more silently skipped tests as skipped
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32599/skiptest_not_return_or_pass.diff

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

From report at bugs.python.org  Wed Nov 13 20:33:43 2013
From: report at bugs.python.org (Antony Lee)
Date: Wed, 13 Nov 2013 19:33:43 +0000
Subject: [New-bugs-announce] [issue19573] Fix the docstring of
	inspect.Parameter and the	implementation of _ParameterKind
Message-ID: <1384371223.06.0.467962768293.issue19573@psf.upfronthosting.co.za>


New submission from Antony Lee:

The following patch corrects the docstring of `inspect.Parameter`, as the `default` and `annotation` attributes are in fact set to `empty` if no value is provided, and the `kind` attribute is in fact an `int` (more precisely, a `_ParameterKind`).  It also reimplements the `_ParameterKind` type as an `IntEnum`, as the previous implementation (which predates stdlib enums) was more or less a hand-rolled `IntEnum`.

----------
assignee: docs at python
components: Documentation
files: inspect.py.diff
keywords: patch
messages: 202773
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Fix the docstring of inspect.Parameter and the implementation of _ParameterKind
type: enhancement
Added file: http://bugs.python.org/file32600/inspect.py.diff

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

From report at bugs.python.org  Wed Nov 13 22:01:28 2013
From: report at bugs.python.org (Vatroslav Suton)
Date: Wed, 13 Nov 2013 21:01:28 +0000
Subject: [New-bugs-announce] [issue19574] Negative integer division error
Message-ID: <1384376488.65.0.288336541103.issue19574@psf.upfronthosting.co.za>


New submission from Vatroslav Suton:

integer division obviously uses float division with math.floor, which produces invalid result when result is less than 0, simply try the following 5/2 versus -5/2. Please use math.ceil function for results less than 0.
btw is there any way to patch that in __builtins__ ?

----------
components: Library (Lib)
messages: 202778
nosy: vatroslavsuton
priority: normal
severity: normal
status: open
title: Negative integer division error
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 13 22:02:53 2013
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Wed, 13 Nov 2013 21:02:53 +0000
Subject: [New-bugs-announce] [issue19575] subprocess.Popen with multiple
	threads: Redirected	stdout/stderr files still open after
	process close
Message-ID: <1384376573.19.0.824450606517.issue19575@psf.upfronthosting.co.za>


New submission from Bernt R?skar Brenna:

Running the following task using concurrent.futures.ThreadPoolExecutor works with max_workers == 1 and fails when max_workers > 1 :

def task():
    dirname = tempfile.mkdtemp()
    f_w =  open(os.path.join(dirname, "stdout.txt"), "w")
    f_r = open(os.path.join(dirname, "stdout.txt"), "r")
    e_w =  open(os.path.join(dirname, "stderr.txt"), "w")
    e_r = open(os.path.join(dirname, "stderr.txt"), "r")

    with subprocess.Popen("dir", shell=True, stdout=f_w, stderr=e_w) as p:
        pass

    f_w.close()
    f_r.close()
    e_w.close()
    e_r.close()

    shutil.rmtree(dirname)

The exception is raised by shutil.rmtree when max_workers > 1: "The process cannot access the file because it is being used by another process"

See also this Stack Overflow question about what seems to bee a similar problem: http://stackoverflow.com/questions/15966418/python-popen-on-windows-with-multithreading-cant-delete-stdout-stderr-logs  The discussion on SO indicates that this might be an XP problem only.

The attached file reproduces the problem on my Windows XP VM.

----------
components: Library (Lib), Windows
files: repro.py
messages: 202779
nosy: Bernt.R?skar.Brenna
priority: normal
severity: normal
status: open
title: subprocess.Popen with multiple threads: Redirected stdout/stderr files still open after process close
versions: Python 3.3
Added file: http://bugs.python.org/file32602/repro.py

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

From report at bugs.python.org  Wed Nov 13 22:49:30 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Nov 2013 21:49:30 +0000
Subject: [New-bugs-announce] [issue19576] "Non-Python created threads"
	documentation doesn't	mention PyEval_InitThreads()
Message-ID: <1384379370.85.0.232061958171.issue19576@psf.upfronthosting.co.za>


New submission from STINNER Victor:

While working on a unit test for the issue #14432, I hit a bug. My C thread got the GIL with PyGILState_Ensure(), but it was strange because the main Python thread also had the GIL...

Then I saw that gil_created() returned false. The solution is to call PyEval_InitThreads() to create the GIL.

I was reading "Non-Python created threads" documentation, but this section doesn't mention PyEval_InitThreads().

I don't know if it's something new in Python 3.2 with the new GIL.

----------
assignee: docs at python
components: Documentation
messages: 202787
nosy: christian.heimes, docs at python, haypo, pitrou
priority: normal
severity: normal
status: open
title: "Non-Python created threads" documentation doesn't mention PyEval_InitThreads()
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov 14 01:39:17 2013
From: report at bugs.python.org (mpb)
Date: Thu, 14 Nov 2013 00:39:17 +0000
Subject: [New-bugs-announce] [issue19577] memoryview bind (the opposite of
	release)
Message-ID: <1384389557.7.0.405119332815.issue19577@psf.upfronthosting.co.za>


New submission from mpb:

I'm writing Python code to parse binary (byte oriented) data.

I am (at least somewhat) aware of the performance implications of various approaches to doing the parsing.  With performance in mind, I would like to avoid unnecessary creation/destruction/copying of memory/objects.

An example:

Let's say I am parsing b'0123456789'.
I want to extract and return the substring b'234'.

Now let's say I do this with memoryviews, to avoid unnecessary creation and copying of memory.

m0 = memoryview (b'0123456789')
m1 = m0[2:5]    # m1 == b'234'

Let's say I do this 1000 times.  Each time I use readinto to load the next data into m0.  So I can create m0 only once and reuse it.

But if the relative position of m1 inside m0 changes with each parse, then I need to create a new m1 for each parse.

In the context of the above example, I think it might be nice if I could rebind an existing memoryview to a new object.  For example:

m0 = memoryview (b'0123456789')
m1.bind (m0, 2, 5)    # m1 == b'234'

Is this an idea worth considering?

(Possibly related: Issue 9789, 9757, 3506; PEP 3118)

----------
messages: 202806
nosy: mpb
priority: normal
severity: normal
status: open
title: memoryview bind (the opposite of release)
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Nov 14 01:42:00 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2013 00:42:00 +0000
Subject: [New-bugs-announce] [issue19578] del list[a:b:c] doesn't handle
	correctly list_resize()	failure
Message-ID: <1384389720.61.0.338181274078.issue19578@psf.upfronthosting.co.za>


New submission from STINNER Victor:

"del list[start:stop:step]" instruction doesn't handle list_resize() failure when step != 1.

Attached patch notifies the caller that list_resize() fails. On case of failure, the list is modified (items are deleted), it's just that list buffer could be smaller (it wastes memory).

See also issue #19568 which is similar for bytearray.

----------
files: list_ass_subscript.patch
keywords: patch
messages: 202808
nosy: haypo
priority: normal
severity: normal
status: open
title: del list[a:b:c] doesn't handle correctly list_resize() failure
versions: Python 3.4
Added file: http://bugs.python.org/file32607/list_ass_subscript.patch

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

From report at bugs.python.org  Thu Nov 14 02:00:00 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2013 01:00:00 +0000
Subject: [New-bugs-announce] [issue19579] test_asyncio: test__run_once
	timings should be relaxed
Message-ID: <1384390800.99.0.143827109941.issue19579@psf.upfronthosting.co.za>


New submission from STINNER Victor:

On Windows, the monotonic timer has a resolution of 15 ms in the worst case. The timing should accept a greater error.

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

======================================================================
FAIL: test__run_once (test.test_asyncio.test_base_events.BaseEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_asyncio\test_base_events.py", line 184, in test__run_once
    self.assertTrue(9.99 < t < 10.1, t)
AssertionError: False is not true : 9.989999999990687

----------
messages: 202813
nosy: gvanrossum, haypo
priority: normal
severity: normal
status: open
title: test_asyncio: test__run_once timings should be relaxed
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov 14 09:08:56 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Thu, 14 Nov 2013 08:08:56 +0000
Subject: [New-bugs-announce] [issue19580] Got resource warning when running
	test_base_events	(test_asyncio)
Message-ID: <1384416536.42.0.501877379944.issue19580@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

$ ./python Lib/test/test_asyncio/test_base_events.py 
............................./home/ethan/Documents/code/python/cpython3.4/Lib/unittest/case.py:158: ResourceWarning: unclosed <socket.socket fd=10, family=AddressFamily.AF_INET, type=SocketType.SOCK_STREAM, proto=0, laddr=('0.0.0.0', 0)>
  callable_obj(*args, **kwargs)
..............
----------------------------------------------------------------------
Ran 43 tests in 0.219s

OK
sys:1: ResourceWarning: unclosed <socket.socket fd=8, family=AddressFamily.AF_INET, type=2049, proto=6, laddr=('0.0.0.0', 0)>
sys:1: ResourceWarning: unclosed <socket.socket fd=7, family=AddressFamily.AF_INET, type=2049, proto=6, laddr=('0.0.0.0', 0)>
sys:1: ResourceWarning: unclosed <socket.socket fd=9, family=AddressFamily.AF_INET, type=2049, proto=6, laddr=('0.0.0.0', 0)>

Attached the patch to close the leak in the test.

----------
components: Tests
files: resource_warning_test_base_events_asyncio.patch
keywords: patch
messages: 202820
nosy: vajrasky
priority: normal
severity: normal
status: open
title: Got resource warning when running test_base_events (test_asyncio)
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file32608/resource_warning_test_base_events_asyncio.patch

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

From report at bugs.python.org  Thu Nov 14 10:37:25 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Nov 2013 09:37:25 +0000
Subject: [New-bugs-announce] [issue19581] PyUnicodeWriter: change the
	overallocation factor for	Windows
Message-ID: <1384421845.71.0.644153662303.issue19581@psf.upfronthosting.co.za>


New submission from STINNER Victor:

PyUnicodeWriter currently overallocates the internal buffer by 25%. On Windows, PyUnicodeWriter is slower than PyAccu API. With an overallocation factor of 50%, PyUnicodeWriter is fastter.

See this message for the benchmark:
http://bugs.python.org/issue19513#msg202312

We might also change the factor on all platform, performances are almost the same with a factor of 25% or 50% on Linux.

----------
components: Windows
files: writer_overallocate_factor.patch
keywords: patch
messages: 202823
nosy: haypo, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: PyUnicodeWriter: change the overallocation factor for Windows
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file32610/writer_overallocate_factor.patch

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

From report at bugs.python.org  Thu Nov 14 12:12:35 2013
From: report at bugs.python.org (Debarshi Goswami)
Date: Thu, 14 Nov 2013 11:12:35 +0000
Subject: [New-bugs-announce] [issue19582] Tkinter is not working with
	Py_SetPath
Message-ID: <1384427555.71.0.261717374261.issue19582@psf.upfronthosting.co.za>


New submission from Debarshi Goswami:

Tkinter is not working when I set PYTHONPATH using Py_SetPath before Initialization in an application embedding Python interpreter.

Any call to Py_SetPath is screwing up Tkinter with an error traceback -
-----------------------------------------------------
'Line 1789: Traceback (most recent call last):
  File "TestTK.py", line 33, in <module>
  File "C:\Python33\Lib\tkinter\__init__.py", line 1789, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following directories: 
    C:/Python33/lib/tcl8.5 .... and so on

This probably means that Tcl wasn't installed properly. 
-------------------------------------------------------------
But if set the 2 environment variable it works fine
set TCL_LIBRARY=C:\Python33\tcl\tcl8.5\
set TK_LIBRARY=C:\tcl\tk8.5\

If Py_SetPath is not called tkinter works well and tkwindow can be launched.

I am using Windows7 64 and Python 3.3.2

----------
components: Tkinter
messages: 202825
nosy: Debarshi.Goswami
priority: normal
severity: normal
status: open
title: Tkinter is not working with Py_SetPath
versions: Python 3.3

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

From report at bugs.python.org  Thu Nov 14 15:51:55 2013
From: report at bugs.python.org (Mathieu Dupuy)
Date: Thu, 14 Nov 2013 14:51:55 +0000
Subject: [New-bugs-announce] [issue19583] time.strftime fails to use %:z
	time formatter of the	underlying C library
Message-ID: <1384440715.52.0.843709066707.issue19583@psf.upfronthosting.co.za>


New submission from Mathieu Dupuy:

function time.strftime fails to use '%:z' time formatter of the underlying library. Passing it does not format time accordingly but returns it as if it was a non-formatting string.

Simple reproduction, on Linux:
$ date +%:z
+01:00
$ python -c 'import time;print time.strftime("%:z")'
%:z

%z works fine, any of the other middle-colon variant (glibc also have %::z, %:::z) have the same problem.

Reproduced with python 2.7 and 3.3

----------
components: Library (Lib)
messages: 202845
nosy: mdupuy
priority: normal
severity: normal
status: open
title: time.strftime fails to use %:z time formatter of the underlying C library
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Nov 14 17:30:00 2013
From: report at bugs.python.org (Bob Wake)
Date: Thu, 14 Nov 2013 16:30:00 +0000
Subject: [New-bugs-announce] [issue19584] IDLE fails - Python V2.7.6 - 64b
	on Win7 64b
Message-ID: <1384446600.97.0.293760172402.issue19584@psf.upfronthosting.co.za>


New submission from Bob Wake:

IDLE won't start on Python 2.7.6, 64 bit running on Windows 7, 64 bit.  It crashes in less than 1 second, before opening a window.  Python appears to work from the command line.  The CPU is a quad core i7 with 8GB memory and 2TB disk space.

----------
components: IDLE
messages: 202856
nosy: bob7wake
priority: normal
severity: normal
status: open
title: IDLE fails - Python V2.7.6 - 64b on Win7 64b
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 14 18:09:30 2013
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Thu, 14 Nov 2013 17:09:30 +0000
Subject: [New-bugs-announce] [issue19585] Frame annotation
Message-ID: <1384448970.46.0.460613881183.issue19585@psf.upfronthosting.co.za>


New submission from Walter D?rwald:

This patch adds frame annotations, i.e. it adds an attribute f_annotation to frame objects, a decorator to set this attribute on exceptions and extensions to the traceback machinery that display the annotation in the traceback.

----------
components: Interpreter Core
files: frame-annotation.diff
hgrepos: 214
keywords: patch
messages: 202862
nosy: doerwalter
priority: normal
severity: normal
status: open
title: Frame annotation
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file32614/frame-annotation.diff

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

From report at bugs.python.org  Thu Nov 14 18:27:58 2013
From: report at bugs.python.org (Gregory Salvan)
Date: Thu, 14 Nov 2013 17:27:58 +0000
Subject: [New-bugs-announce] [issue19586] Remove assertEquals and assert_
	deprecation warnings
Message-ID: <1384450078.17.0.0106605796399.issue19586@psf.upfronthosting.co.za>


New submission from Gregory Salvan:

Replace assertEquals by assertEqual and assert_ by assertTrue to remove tests deprecation warning.

It's few, but it's a first step to make contributions.

----------
components: Distutils, Distutils2
files: distutil.patch
keywords: patch
messages: 202863
nosy: Gregory.Salvan, alexis
priority: normal
severity: normal
status: open
title: Remove assertEquals and assert_ deprecation warnings
type: compile error
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file32615/distutil.patch

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

From report at bugs.python.org  Thu Nov 14 18:47:22 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Nov 2013 17:47:22 +0000
Subject: [New-bugs-announce] [issue19587] Remove test_bytes.FixedStringTest
Message-ID: <1384451242.84.0.0741219651505.issue19587@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The attached patch removes test_bytes.FixedStringTest and its subclasses, as they report success when they don't actually test anything at all.

----------
components: Tests
files: test_bytes.diff
keywords: patch
messages: 202866
nosy: serhiy.storchaka, zach.ware
priority: normal
severity: normal
status: open
title: Remove test_bytes.FixedStringTest
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32616/test_bytes.diff

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

From report at bugs.python.org  Thu Nov 14 21:34:48 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Nov 2013 20:34:48 +0000
Subject: [New-bugs-announce] [issue19588] Silently skipped test in
	test_random
Message-ID: <1384461288.76.0.822218822712.issue19588@psf.upfronthosting.co.za>


New submission from Zachary Ware:

See: http://hg.python.org/cpython/file/87099/Lib/test/test_random.py#l241

This test (and its match in MersenneTwister_TestBasicOps) is nearly always skipped by the 'if stop <= start: return' check; in a test with adding "print('skipped', i)" before the return and running test_random via regrtest with -F, i was 40 when the test returned about 21 out of 25 times.  It seems to have been this way since the test was added.

Was this intended?  It looks to me like perhaps the start and stop assignments are swapped; Serhiy suggested that perhaps stop was meant to have been added to start.  How is this test meant to work?

----------
components: Tests
messages: 202879
nosy: rhettinger, serhiy.storchaka, zach.ware
priority: normal
severity: normal
status: open
title: Silently skipped test in test_random
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov 14 21:40:50 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Nov 2013 20:40:50 +0000
Subject: [New-bugs-announce] [issue19589] Use specific asserts in
	test_asyncio
Message-ID: <1384461650.67.0.185273921474.issue19589@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes test_asyncio use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_asyncio_asserts.patch
keywords: patch
messages: 202880
nosy: gvanrossum, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in test_asyncio
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32618/test_asyncio_asserts.patch

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

From report at bugs.python.org  Thu Nov 14 21:44:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Nov 2013 20:44:02 +0000
Subject: [New-bugs-announce] [issue19590] Use specific asserts in test_email
Message-ID: <1384461842.17.0.928919651646.issue19590@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes test_email use more specific asserts. This will provide more useful failure report.

----------
components: Tests, email
files: test_email_asserts.patch
keywords: patch
messages: 202881
nosy: barry, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in test_email
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32619/test_email_asserts.patch

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

From report at bugs.python.org  Thu Nov 14 21:49:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Nov 2013 20:49:52 +0000
Subject: [New-bugs-announce] [issue19591] Use specific asserts in ctype tests
Message-ID: <1384462192.45.0.696464665582.issue19591@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the ctypes package tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests, ctypes
files: test_ctypes_asserts.patch
keywords: patch
messages: 202883
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in ctype tests
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32620/test_ctypes_asserts.patch

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

From report at bugs.python.org  Thu Nov 14 21:53:52 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Nov 2013 20:53:52 +0000
Subject: [New-bugs-announce] [issue19592] Use specific asserts in lib2to3
	tests
Message-ID: <1384462432.63.0.387609657134.issue19592@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the lib2to3 package tests use more specific asserts. This will provide more useful failure report.

----------
components: 2to3 (2.x to 3.x conversion tool), Tests
files: test_lib2to3_asserts.patch
keywords: patch
messages: 202884
nosy: benjamin.peterson, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in lib2to3 tests
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32621/test_lib2to3_asserts.patch

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

From report at bugs.python.org  Thu Nov 14 21:56:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Nov 2013 20:56:23 +0000
Subject: [New-bugs-announce] [issue19593] Use specific asserts in importlib
	tests
Message-ID: <1384462583.85.0.490812724335.issue19593@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the importlib package tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_importlib_asserts.patch
keywords: patch
messages: 202885
nosy: brett.cannon, eric.snow, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in importlib tests
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32622/test_importlib_asserts.patch

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

From report at bugs.python.org  Thu Nov 14 21:58:30 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Nov 2013 20:58:30 +0000
Subject: [New-bugs-announce] [issue19594] Use specific asserts in unittest
	tests
Message-ID: <1384462710.0.0.524948910788.issue19594@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the unittest package tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_unittest_asserts.patch
keywords: patch
messages: 202886
nosy: ezio.melotti, michael.foord, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in unittest tests
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32623/test_unittest_asserts.patch

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

From report at bugs.python.org  Thu Nov 14 22:00:56 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Nov 2013 21:00:56 +0000
Subject: [New-bugs-announce] [issue19595] Silently skipped test in
	test_winsound
Message-ID: <1384462856.95.0.594659229823.issue19595@psf.upfronthosting.co.za>


New submission from Zachary Ware:

In test_winsound, PlaySoundTest.test_alias_fallback has been commented out for quite some time but has been reported as 'ok' ever since.  Does anyone know what the current status of the test is?  Should it still be skipped (explicitly)?  Should it be marked as an expected failure?  Would it be dangerous to enable?  My own testing shows it to be harmless on my machine, but my range of test configurations is sorely limited at present.  My own suggestion is to mark it as an expected failure (or just enable it wholesale, and mark it if it does prove flaky) and see what the buildbots make of it, but I don't want to do that if it could cause anything worse than an exception.

Thoughts?

----------
components: Tests, Windows
messages: 202887
nosy: brian.curtin, serhiy.storchaka, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Silently skipped test in test_winsound
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov 14 22:12:22 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Nov 2013 21:12:22 +0000
Subject: [New-bugs-announce] [issue19596] Silently skipped tests in
	test_importlib
Message-ID: <1384463542.16.0.0206714723077.issue19596@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Several tests in test_importlib are skipped by way of the test method consisting of a comment and a 'pass' statement.  The attached patch makes the skips explicit, using the removed comment as the reason.  Ideally these skipped tests should be removed from being 'tested' at all, since most of them are impossible to test, but I'm not sure how easy that would be to do.

----------
components: Tests
files: skipped_importlib_tests.diff
keywords: patch
messages: 202890
nosy: brett.cannon, serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Silently skipped tests in test_importlib
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32624/skipped_importlib_tests.diff

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

From report at bugs.python.org  Thu Nov 14 23:33:12 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Nov 2013 22:33:12 +0000
Subject: [New-bugs-announce] [issue19597] Add decorator for tests not yet
	implemented
Message-ID: <1384468392.3.0.701563221168.issue19597@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Some tests in the test suite are not implemented for one reason or another, and most of these are defined simply as "def test_thats_not_implemented(self): pass", possibly with a comment meant to be a reminder to implement it.  This patch adds a decorator to test.support which turns the non-test into an expected failure with a docstring.  This means that when run in verbose mode, instead of showing:

"""
test_thats_not_implemented (test.test_sometest.TestClass) ... ok
"""

it will instead show:

"""
Not Implemented: TestClass.test_thats_not_implemented ... expected failure
"""

This should make it more obvious that such a test needs some work.  The patch also applies the decorator in test_minidom as an example; there are a few other places that could use it as well.

----------
components: Tests
files: support.not_implemented.diff
keywords: patch
messages: 202907
nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Add decorator for tests not yet implemented
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32626/support.not_implemented.diff

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

From report at bugs.python.org  Fri Nov 15 01:55:57 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Nov 2013 00:55:57 +0000
Subject: [New-bugs-announce] [issue19598] Timeout in test_popen()
	of	test_asyncio.test_windows_utils.PopenTests
Message-ID: <1384476957.48.0.494965760116.issue19598@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/7528/steps/test/logs/stdio

...
test_popen (test.test_asyncio.test_windows_utils.PopenTests) ... FAIL
test_winsocketpair (test.test_asyncio.test_windows_utils.WinsocketpairTests) ... ok
test_winsocketpair_exc (test.test_asyncio.test_windows_utils.WinsocketpairTests) ... ok

======================================================================
FAIL: test_popen (test.test_asyncio.test_windows_utils.PopenTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_windows_utils.py", line 123, in test_popen
    self.assertEqual(res, _winapi.WAIT_OBJECT_0)
AssertionError: 258 != 0

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

258 is the Windows error code for timeout: WAIT_TIMEOUT.

The timeout of 2 seconds if maybe too short for busy and slow Windows buildbots?

----------
messages: 202913
nosy: gvanrossum, haypo
priority: normal
severity: normal
status: open
title: Timeout in test_popen() of test_asyncio.test_windows_utils.PopenTests
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 15 02:01:20 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Nov 2013 01:01:20 +0000
Subject: [New-bugs-announce] [issue19599] Failure of test_async_timeout()
	of	test_multiprocessing_spawn: TimeoutError not raised
Message-ID: <1384477280.87.0.276347613255.issue19599@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%203.x/builds/1716/steps/test/logs/stdio
and
http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/7529/steps/test/logs/stdio

======================================================================
FAIL: test_async_timeout (test.test_multiprocessing_spawn.WithManagerTestPool)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\test\_test_multiprocessing.py", line 1726, in test_async_timeout
    self.assertRaises(multiprocessing.TimeoutError, get, timeout=TIMEOUT2)
AssertionError: TimeoutError not raised by <test._test_multiprocessing.TimingWrapper object at 0x09FE0930>

----------
components: Tests
messages: 202914
nosy: haypo, sbt
priority: normal
severity: normal
status: open
title: Failure of test_async_timeout() of test_multiprocessing_spawn: TimeoutError not raised
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 15 09:06:48 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Nov 2013 08:06:48 +0000
Subject: [New-bugs-announce] [issue19600] Use specific asserts in distutils
	tests
Message-ID: <1384502808.59.0.591173639176.issue19600@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the distutils package tests use more specific asserts. This will provide more useful failure report.

----------
components: Distutils
files: test_distutils_asserts.patch
keywords: patch
messages: 202922
nosy: eric.araujo, serhiy.storchaka, tarek
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in distutils tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32631/test_distutils_asserts.patch

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

From report at bugs.python.org  Fri Nov 15 09:08:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Nov 2013 08:08:31 +0000
Subject: [New-bugs-announce] [issue19601] Use specific asserts in sqlite3
	tests
Message-ID: <1384502911.7.0.613780921305.issue19601@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the sqlite3 package tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_sqlite3_asserts.patch
keywords: patch
messages: 202923
nosy: ghaering, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in sqlite3 tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32632/test_sqlite3_asserts.patch

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

From report at bugs.python.org  Fri Nov 15 09:09:59 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Nov 2013 08:09:59 +0000
Subject: [New-bugs-announce] [issue19602] Use specific asserts in tkinter
	tests
Message-ID: <1384502999.03.0.730675393841.issue19602@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the tkinter package tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests, Tkinter
files: test_tkinter_asserts.patch
keywords: patch
messages: 202924
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in tkinter tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32633/test_tkinter_asserts.patch

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

From report at bugs.python.org  Fri Nov 15 09:12:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Nov 2013 08:12:07 +0000
Subject: [New-bugs-announce] [issue19603] Use specific asserts in test_decr
Message-ID: <1384503127.94.0.904619557147.issue19603@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes test_descr use more specific asserts. This will provide more useful failure report.

This is the largest patch in the series.

----------
components: Tests
messages: 202925
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in test_decr
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov 15 10:51:29 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Nov 2013 09:51:29 +0000
Subject: [New-bugs-announce] [issue19604] Use specific asserts in array tests
Message-ID: <1384509089.55.0.263530897465.issue19604@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the array module tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_array_asserts.patch
keywords: patch
messages: 202929
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in array tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32635/test_array_asserts.patch

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

From report at bugs.python.org  Fri Nov 15 10:53:35 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Nov 2013 09:53:35 +0000
Subject: [New-bugs-announce] [issue19605] Use specific asserts in datetime
	tests
Message-ID: <1384509215.73.0.873700234251.issue19605@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the datetime module tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_datetime_asserts.patch
keywords: patch
messages: 202930
nosy: belopolsky, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in datetime tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32636/test_datetime_asserts.patch

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

From report at bugs.python.org  Fri Nov 15 10:55:20 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Nov 2013 09:55:20 +0000
Subject: [New-bugs-announce] [issue19606] Use specific asserts in
	http.cookiejar tests
Message-ID: <1384509320.61.0.0425135546952.issue19606@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the http.cookiejar module tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_http_cookiejar_asserts.patch
keywords: patch
messages: 202931
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in http.cookiejar tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32637/test_http_cookiejar_asserts.patch

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

From report at bugs.python.org  Fri Nov 15 10:57:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Nov 2013 09:57:17 +0000
Subject: [New-bugs-announce] [issue19607] Use specific asserts in weakref
	tests
Message-ID: <1384509437.64.0.236253006497.issue19607@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch makes the weakref module tests use more specific asserts. This will provide more useful failure report.

----------
components: Tests
files: test_weakref_asserts.patch
keywords: patch
messages: 202932
nosy: fdrake, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use specific asserts in weakref tests
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32638/test_weakref_asserts.patch

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

From report at bugs.python.org  Fri Nov 15 11:13:10 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 15 Nov 2013 10:13:10 +0000
Subject: [New-bugs-announce] [issue19608] devguide needs pictures
Message-ID: <1384510390.93.0.961404476169.issue19608@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

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

it covers pretty much complicated stuff, which takes a lot of time to grasp. Pictures help to save hours if not weeks. There needs to be some immediate intro picture at the top of front page illustrating transformation of Python code through the toolchain to machine execution instructions.

----------
components: Devguide
messages: 202933
nosy: ezio.melotti, techtonik
priority: normal
severity: normal
status: open
title: devguide needs pictures

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

From report at bugs.python.org  Fri Nov 15 12:10:29 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 15 Nov 2013 11:10:29 +0000
Subject: [New-bugs-announce] [issue19609] Codec exception chaining shouldn't
	cover the initial	codec lookup
Message-ID: <1384513829.85.0.540008765744.issue19609@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The exception chaining from issue 17828 is triggering for the initial codec lookup. This is less than helpful:

====================
Failed example:
    str(result)
Expected:
    Traceback (most recent call last):
      ...
    LookupError: unknown encoding: UCS4
Got:
    LookupError: unknown encoding: UCS4
    <BLANKLINE>
    The above exception was the direct cause of the following exception:
    <BLANKLINE>
    Traceback (most recent call last):
      File ".../py3km/python/lib/python3.4/doctest.py", line 1291, in __run
        compileflags, 1), test.globs)
      File "<doctest xpathxslt.txt[89]>", line 1, in <module>
        str(result)
      File "xslt.pxi", line 727, in lxml.etree._XSLTResultTree.__str__
(src/lxml/lxml.etree.c:143584)
      File "xslt.pxi", line 750, in lxml.etree._XSLTResultTree.__unicode__
(src/lxml/lxml.etree.c:143853)
    LookupError: decoding with 'UCS4' codec failed (LookupError: unknown
encoding: UCS4)
====================

----------
assignee: ncoghlan
messages: 202937
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Codec exception chaining shouldn't cover the initial codec lookup
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 15 12:24:52 2013
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 15 Nov 2013 11:24:52 +0000
Subject: [New-bugs-announce] [issue19610] TypeError in
	distutils.command.upload
Message-ID: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za>


New submission from Berker Peksag:

Python 3.4:

$ ../cpython/./python setup.py sdist upload -r test --show-response
...
...
Traceback (most recent call last):
  File "setup.py", line 24, in <module>
    'License :: OSI Approved :: Mozilla Public License 2.0 (MPL 2.0)',
  File "/home/berker/projects/cpython/Lib/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/home/berker/projects/cpython/Lib/distutils/dist.py", line 930, in run_commands
    self.run_command(cmd)
  File "/home/berker/projects/cpython/Lib/distutils/dist.py", line 949, in run_command
    cmd_obj.run()
  File "/home/berker/projects/cpython/Lib/distutils/command/upload.py", line 65, in run
    self.upload_file(command, pyversion, filename)
  File "/home/berker/projects/cpython/Lib/distutils/command/upload.py", line 165, in upload_file
    body.write(value)
TypeError: 'str' does not support the buffer interface


Python 3.3:

$ python3.3 setup.py sdist upload -r test --show-response
...
...
Traceback (most recent call last):
  File "setup.py", line 24, in <module>
    'License :: OSI Approved :: Mozilla Public License 2.0 (MPL 2.0)',
  File "/usr/local/lib/python3.3/distutils/core.py", line 148, in setup
    dist.run_commands()
  File "/usr/local/lib/python3.3/distutils/dist.py", line 917, in run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python3.3/distutils/dist.py", line 936, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python3.3/distutils/command/upload.py", line 66, in run
    self.upload_file(command, pyversion, filename)
  File "/usr/local/lib/python3.3/distutils/command/upload.py", line 155, in upload_file
    body.write(value)
TypeError: 'str' does not support the buffer interface

I also attached my setup.py.

----------
components: Distutils
files: setup.py
messages: 202938
nosy: berker.peksag
priority: normal
severity: normal
stage: patch review
status: open
title: TypeError in distutils.command.upload
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32641/setup.py

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

From report at bugs.python.org  Fri Nov 15 13:03:03 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Fri, 15 Nov 2013 12:03:03 +0000
Subject: [New-bugs-announce] [issue19611] inspect.getcallargs doesn't
	properly interpret set	comprehension code objects.
Message-ID: <1384516983.26.0.0584971052865.issue19611@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

In 2.7, set comprehensions are compiled to code objects expecting an argument named ".0".  This convention is also used for the unnamed arguments needed by tuple arguments.  inspect.getcallargs understands the tuple argument case, but not the set comprehension case, and throws errors for correct arguments.

This is also true for generator expressions and dictionary comprehensions.

Demonstration:

#-----
import inspect
import sys
import types

def make_set():
    return {z*z for z in range(5)}

print(make_set())

# The set comprehension is turned into a code object expecting a single
# argument called ".0" with should be an iterator over range(5).
if sys.version_info < (3,):
    setcomp_code = make_set.func_code.co_consts[1]
else:
    setcomp_code = make_set.__code__.co_consts[1]
setcomp_func = types.FunctionType(setcomp_code, {})

# We can successfully call the function with the argument it expects.
print(setcomp_func(iter(range(5))))

# But inspect can't figure that out, because the ".0" argument also means
# tuple arguments, which this code object doesn't expect.
print(inspect.getcallargs(setcomp_func, iter(range(5))))

#-----



When run on Python 3.3, this produces:

    {0, 1, 4, 16, 9} 
    {0, 1, 4, 16, 9}
    {'.0': <range_iterator object at 0x10834be70>}

When run on Python 2.7, it produces:

    set([0, 1, 4, 16, 9])
    set([0, 1, 4, 16, 9])
    Traceback (most recent call last):
      File "foo.py", line 17, in <module>
        print(inspect.getcallargs(setcomp_func, iter(range(5))))
      File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/inspect.py", line 935, in getcallargs
        assign(arg, value)
      File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/inspect.py", line 922, in assign
        raise ValueError('too many values to unpack')
    ValueError: too many values to unpack

----------
components: Library (Lib)
messages: 202944
nosy: nedbat
priority: normal
severity: normal
status: open
title: inspect.getcallargs doesn't properly interpret set comprehension code objects.
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 15 17:29:59 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Nov 2013 16:29:59 +0000
Subject: [New-bugs-announce] [issue19612] test_subprocess: sporadic failure
	of	test_communicate_epipe()
Message-ID: <1384532999.66.0.279652262495.issue19612@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The test failed on a buildbot, see the message below. By the way, the test should use a value based on test.support.PIPE_MAX_SIZE rather than an hardcoded size of 2**20 bytes.


http://buildbot.python.org/all/builders/x86%20Windows%20Server%202008%20%5BSB%5D%203.x/builds/1661/steps/test/logs/stdio

test_communicate_epipe (test.test_subprocess.ProcessTestCase) ... ERROR
test_communicate_epipe_only_stdin (test.test_subprocess.ProcessTestCase) ... ok


======================================================================
ERROR: test_communicate_epipe (test.test_subprocess.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\test\test_subprocess.py", line 1095, in test_communicate_epipe
    p.communicate(b"x" * 2**20)
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\subprocess.py", line 952, in communicate
    stdout, stderr = self._communicate(input, endtime, timeout)
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\subprocess.py", line 1188, in _communicate
    self.stdin.write(input)
OSError: [Errno 22] Invalid argument

----------------------------------------------------------------------
(...)
test_communicate_epipe (test.test_subprocess.ProcessTestCase) ... ok
test_communicate_epipe_only_stdin (test.test_subprocess.ProcessTestCase) ... ok

----------
components: Tests, Windows
keywords: buildbot
messages: 202959
nosy: haypo
priority: normal
severity: normal
status: open
title: test_subprocess: sporadic failure of test_communicate_epipe()
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 15 18:30:45 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Nov 2013 17:30:45 +0000
Subject: [New-bugs-announce] [issue19613] test_nntplib: sporadic failures,
	test_article_head_body()
Message-ID: <1384536645.9.0.862907413915.issue19613@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/3024/steps/test/logs/stdio

======================================================================
ERROR: test_article_head_body (test.test_nntplib.NetworkedNNTP_SSLTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_nntplib.py", line 251, in wrapped
    meth(self)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_nntplib.py", line 178, in test_article_head_body
    self.check_article_resp(resp, body, art_num)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_nntplib.py", line 158, in check_article_resp
    self.assertNotIn(article.lines[-1], (b".", b".\n", b".\r\n"))
IndexError: list index out of range

(...)
Re-running failed tests in verbose mode
Re-running test 'test_nntplib' in verbose mode
(...)
test_article_head_body (test.test_nntplib.NetworkedNNTPTests) ... ok

----------
components: Tests
messages: 202961
nosy: haypo
priority: normal
severity: normal
status: open
title: test_nntplib: sporadic failures, test_article_head_body()
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 15 18:44:46 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Nov 2013 17:44:46 +0000
Subject: [New-bugs-announce] [issue19614] support.temp_cwd should use
	support.rmtree
Message-ID: <1384537486.79.0.657999884373.issue19614@psf.upfronthosting.co.za>


New submission from R. David Murray:

Based on this error on one of the buildbots, it is clear that support.temp_cwd should be calling support.rmtree, and not shutil.rmtree, during cleanup:

[...]
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py", line 1585, in <module>
    main_in_temp_cwd()
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py", line 1560, in main_in_temp_cwd
    main()
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\contextlib.py", line 77, in __exit__
    self.gen.throw(type, value, traceback)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 868, in temp_cwd
    yield cwd_dir
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\contextlib.py", line 77, in __exit__
    self.gen.throw(type, value, traceback)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 822, in temp_dir
    shutil.rmtree(path)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 477, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 376, in _rmtree_unsafe
    onerror(os.rmdir, path, sys.exc_info())
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 374, in _rmtree_unsafe
    os.rmdir(path)
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'C:\\buildbot.python.org\\3.x.kloth-win64\\build\\build\\test_python_4744'
[...]

----------
components: Tests
keywords: buildbot, easy
messages: 202962
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: support.temp_cwd should use support.rmtree
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov 15 18:53:53 2013
From: report at bugs.python.org (Edward Catmur)
Date: Fri, 15 Nov 2013 17:53:53 +0000
Subject: [New-bugs-announce] [issue19615] "ImportError: dynamic module does
	not define init	function" when deleting and recreating .so
	files from different	machines over NFS
Message-ID: <1384538033.67.0.422579002875.issue19615@psf.upfronthosting.co.za>


New submission from Edward Catmur:

foo.c:

#include <Python.h>
static PyMethodDef mth[] = { {NULL, NULL, 0, NULL} };
static struct PyModuleDef mod = { PyModuleDef_HEAD_INIT, "foo", NULL, -1, mth };
PyMODINIT_FUNC PyInit_foo(void) { return PyModule_Create(&mod); }

bar.c:

#include <Python.h>
static PyMethodDef mth[] = { {NULL, NULL, 0, NULL} };
static struct PyModuleDef mod = { PyModuleDef_HEAD_INIT, "bar", NULL, -1, mth };
PyMODINIT_FUNC PyInit_bar(void) { return PyModule_Create(&mod); }

setup.py:

from distutils.core import setup, Extension
setup(name='PackageName',
      ext_modules=[Extension('foo', sources=['foo.c']),
                   Extension('bar', sources=['bar.c'])])

In an NFS mount:

host1$ python setup.py build
host1$ rm *.so; cp build/lib.*/foo*.so .; cp build/lib.*/bar*.so .
host1$ python -c 'import foo; input(); import bar'

While python is waiting for input, on another host in the same directory:

host2$ rm *.so; cp build/lib.*/bar*.so .; cp build/lib.*/foo*.so .

Back on host1:
<Enter>
ImportError: dynamic module does not define init function (PyInit_bar)

Attaching a debugger to Python after the ImportError and calling dlerror() shows the problem:

(gdb) print (char *)dlerror()
$1 = 0xe495210 "/<...>/foo.cpython-34dm.so: undefined symbol: PyInit_bar"

This is because dynload_shlib.c[1] caches dlopen handles by (device and) inode number; but NFS will reuse inode numbers even if a process on a client host has the file open; running lsof on Python, before:

python  16475 ecatmur  mem    REG    0,36    14000 55321147 /<...>/foo.cpython-34dm.so (nfs:/export/user)

and after:

python  16475 ecatmur  mem    REG    0,36          55321147 /<...>/foo.cpython-34dm.so (nfs:/export/user) (path inode=55321161)

Indeed, bar.cpython-34dm.so now has the inode number that Python originally opened foo.cpython-34dm.so under:

host1$ stat -c '%n %i' *.so
bar.cpython-34dm.so 55321147
foo.cpython-34dm.so 55321161

Obviously, this can only happen on a filesystem like NFS where inode numbers can be reused even while a process still has a file open (or mapped).

We encountered this problem in a fairly pathological situation; multiple processes running in two virtualenvs with different copies of a zipped egg (of the same version!) were contending over the ~/.python-eggs directory created by pkg_resources[2] to cache .so files extracted from eggs.  We are working around the situation by setting PYTHON_EGG_CACHE to a virtualenv-specific location, which also fixes the contention issue.  (We should probably work out why the eggs are different, but fixing that is bound into our build/deployment system.)

I'm not sure exactly how to solve or even detect this issue; perhaps looking at the mtime of the .so might work?

If it is decided not to fix the issue it would be useful if _PyImport_GetDynLoadFunc could report the actual dlerror(); this would have saved us quite some time debugging it.  I'll work on a patch to do that.

  1. http://hg.python.org/cpython/file/tip/Python/dynload_shlib.c
  2. https://bitbucket.org/pypa/setuptools/src/ac127a3f46be3037c79f2c4076c7ab221cde21b2/pkg_resources.py?at=default#cl-1040

----------
components: Interpreter Core
messages: 202963
nosy: ecatmur
priority: normal
severity: normal
status: open
title: "ImportError: dynamic module does not define init function" when deleting and recreating .so files from different machines over NFS
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov 15 23:06:54 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Nov 2013 22:06:54 +0000
Subject: [New-bugs-announce] [issue19616] Fix
	test.test_importlib.util.test_both() to set	__module__
Message-ID: <1384553214.36.0.335433521852.issue19616@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Should help with traceback/test failure reporting.

----------
assignee: brett.cannon
messages: 202971
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Fix test.test_importlib.util.test_both() to set __module__
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 16 00:08:07 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Nov 2013 23:08:07 +0000
Subject: [New-bugs-announce] [issue19617] Fix usage of Py_ssize_t type in
	Python/compile.c
Message-ID: <1384556887.78.0.0801644931994.issue19617@psf.upfronthosting.co.za>


New submission from STINNER Victor:

On Windows 64-bit, Visual Studio generates a lot of warnings because Py_ssize_t values are downcasted to int.

Attached patch fixes all warnings and move the final downcast into compiler_addop_i(). This function uses an assertion to check that integer parameter fits into an C int type. I don't know if it's safe to "return 0" on overflow error.

The patch fixes also some indentation issues seen was I wrote the patch.

Nobody complained before, I don't know if the bugs can be seen in practice, so I prefer to not touch Python 2.7 nor 3.2.

----------
files: compile_ssize_t.patch
keywords: patch
messages: 202976
nosy: benjamin.peterson, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix usage of Py_ssize_t type in Python/compile.c
versions: Python 3.4
Added file: http://bugs.python.org/file32644/compile_ssize_t.patch

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

From report at bugs.python.org  Sat Nov 16 01:37:03 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 16 Nov 2013 00:37:03 +0000
Subject: [New-bugs-announce] [issue19618] test_sysconfig_module fails on
	Ubuntu 12.04
Message-ID: <1384562223.55.0.434561574175.issue19618@psf.upfronthosting.co.za>


New submission from Berker Peksag:

This is probably related to issue 17679.

======================================================================
FAIL: test_sysconfig_module (distutils.tests.test_sysconfig.SysconfigTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/berker/projects/cpython/Lib/distutils/tests/test_sysconfig.py", line 132, in test_sysconfig_module
    self.assertEqual(global_sysconfig.get_config_var('CFLAGS'), sysconfig.get_config_var('CFLAGS'))
AssertionError: '-Wno-unused-result -g -O0 -Wall -Wstrict-prototypes' != '-Wno-unused-result -Werror=declaration-after-statement -g -O0[22 chars]ypes'
- -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes
+ -Wno-unused-result -Werror=declaration-after-statement -g -O0 -Wall -Wstrict-prototypes

----------
components: Distutils, Tests
messages: 202994
nosy: berker.peksag
priority: normal
severity: normal
status: open
title: test_sysconfig_module fails on Ubuntu 12.04
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Nov 16 01:47:09 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Nov 2013 00:47:09 +0000
Subject: [New-bugs-announce] [issue19619] Blacklist base64, hex,
	... codecs from bytes.decode() and str.encode()
Message-ID: <1384562829.72.0.617857672471.issue19619@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I propose to add new input_type and output_type to CodecInfo. These attributes would only be defined for base64, hex, ... codecs which are not the classic encode: str=>bytes, decode: bytes=>str codecs.

I also propose to modify str.encode() and bytes.encode() to only accept codecs using the right types. If the type doesn't match, the codec raises a LookupError.

This issue should avoid the denial of service attack when a compression codec is used, see:
https://mail.python.org/pipermail/python-dev/2013-November/130188.html

----------
messages: 202996
nosy: haypo, lemburg, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Blacklist base64, hex, ... codecs from bytes.decode() and str.encode()
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 16 03:31:52 2013
From: report at bugs.python.org (Christopher Welborn)
Date: Sat, 16 Nov 2013 02:31:52 +0000
Subject: [New-bugs-announce] [issue19620] tokenize documentation contains
	typos (argment instead	of argument)
Message-ID: <1384569112.62.0.796047767365.issue19620@psf.upfronthosting.co.za>


New submission from Christopher Welborn:

Documentation for tokenize contains typos, functions detect_encoding() and tokenize() at least. The lines are:

The tokenize() generator requires one argment, readline,...

It requires one argment, readline,

...where argment is supposed to be 'argument' i'm sure. Things like that bug me in my own code/docs, and since it's been there since 2.7 (Also in 3.3 and 3.4), I figured no one had noticed.

----------
assignee: docs at python
components: Documentation
messages: 203005
nosy: cjwelborn, docs at python
priority: normal
severity: normal
status: open
title: tokenize documentation contains typos (argment instead of argument)
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Nov 16 05:46:43 2013
From: report at bugs.python.org (Chris Angelico)
Date: Sat, 16 Nov 2013 04:46:43 +0000
Subject: [New-bugs-announce] [issue19621] Reimporting this and
	str.translate()
Message-ID: <1384577203.93.0.74432815372.issue19621@psf.upfronthosting.co.za>


New submission from Chris Angelico:

In an interactive session, typing 'import this' a second time doesn't produce output (as the module's already imported). Peeking into the module shows a string and what looks like a translation dictionary, but doing the obvious thing:

>>> this.s.translate(this.d)

doesn't work, because str.translate() expects a dictionary that maps Unicode ordinals, not one-character strings.

Attached is a patch which makes Lib/this.py use s.translate() instead of the wordier comprehension. Dare I ask, is there any possible code that this change could break? :)

----------
components: Library (Lib)
files: this-translate.patch
keywords: patch
messages: 203008
nosy: Rosuav
priority: normal
severity: normal
status: open
title: Reimporting this and str.translate()
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file32645/this-translate.patch

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

From report at bugs.python.org  Sat Nov 16 06:22:14 2013
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Nov 2013 05:22:14 +0000
Subject: [New-bugs-announce] [issue19622] Default buffering for input and
	output pipes in	subprocess module
Message-ID: <1384579334.66.0.612676075589.issue19622@psf.upfronthosting.co.za>


New submission from Martin Panter:

Currently the documentation for the ?bufsize? parameter in the ?subprocess? module says:

"""
Changed in version 3.2.4,: 3.3.1

bufsize now defaults to -1 to enable buffering by default to match the behavior that most code expects. In 3.2.0 through 3.2.3 and 3.3.0 it incorrectly defaulted to 0 which was unbuffered and allowed short reads. This was unintentional and did not match the behavior of Python 2 as most code expected.
"""

First of all the formatting is a bit screwy. There?s a colon in the wrong place, so it?s not obvious that the ?changed in version? heading applies to the following paragraph.

The main issue is that I got the impression the default of 0 was a regression, and that Python 3.1 and Python 2 defaulted to -1. However, as far as I can tell the default was actually 0 in 3.1 and 2.

The change to -1 was for Issue 17488, which seems to be focussed on the behaviour of reading from a subprocess?s output pipe. In Python 2, file.read() blocks to read as much as possible, even when buffering is disabled. In Python 3, you end up with either a FileIO or a BufferedIOBase object, and they have different read() behaviours.

Perhaps the documentation should say something like

"""
The ?bufsize? argument now defaults to -1 to enable buffering. In 3.2.3, 3.3.0, and earlier, it defaulted to 0 which was unbuffered and allowed short reads.
"""

I would take out the ?most code expects buffering? bits. Maybe most code expects the greedy read behaviour from output pipes, but I would say most code writing to an input pipe expects unbuffered behaviour. The big issue with buffering for me is that BufferedWriter.close() may raise a broken pipe condition.

If you want to mention Python 2, maybe say that Python 2 did not use buffering by default, but that file.read() always had blocking read behaviour, which can be emulated by using buffered reading in Python 3.

----------
assignee: docs at python
components: Documentation
messages: 203010
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: Default buffering for input and output pipes in subprocess module
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Nov 16 12:44:40 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Nov 2013 11:44:40 +0000
Subject: [New-bugs-announce] [issue19623] Support for writing aifc to
	unseekable file
Message-ID: <1384602280.29.0.166311165953.issue19623@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The aifc module documentation mentions that underlying file can be unseekable if the number of frames are specified.

   When
   used for writing, the file object should be seekable, unless you know ahead of
   time how many samples you are going to write in total and use
   :meth:`writeframesraw` and :meth:`setnframes`.

But this doesn't work.

>>> import aifc
>>> f = aifc.open('/dev/stdout', 'w')
>>> f.setnchannels(1)
>>> f.setsampwidth(1)
>>> f.setframerate(8000)
>>> f.setcomptype(b'NONE', b'not compressed')
>>> f.setnframes(1)
>>> f.writeframesraw(b'\0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/aifc.py", line 695, in writeframesraw
    self._ensure_header_written(len(data))
  File "/home/serhiy/py/cpython/Lib/aifc.py", line 763, in _ensure_header_written
    self._write_header(datasize)
  File "/home/serhiy/py/cpython/Lib/aifc.py", line 791, in _write_header
    self._form_length_pos = self._file.tell()
OSError: [Errno 29] Illegal seek

Here is a patch which makes the code to conform with the documentation.

----------
components: Library (Lib)
files: aifc_write_unseekable.patch
keywords: patch
messages: 203026
nosy: r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Support for writing aifc to unseekable file
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32649/aifc_write_unseekable.patch

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

From report at bugs.python.org  Sat Nov 16 13:21:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Nov 2013 12:21:47 +0000
Subject: [New-bugs-announce] [issue19624] Switch constants in the errno
	module to IntEnum
Message-ID: <1384604507.4.0.390717114428.issue19624@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

It will be good to switch constants in the errno module to IntEnum.

----------
components: Extension Modules, Library (Lib)
messages: 203035
nosy: barry, eli.bendersky, ethan.furman, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Switch constants in the errno module to IntEnum
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 16 15:53:51 2013
From: report at bugs.python.org (irdb)
Date: Sat, 16 Nov 2013 14:53:51 +0000
Subject: [New-bugs-announce] [issue19625] IDLE should use UTF-8 as it's
	default encoding
Message-ID: <1384613631.52.0.52309466252.issue19625@psf.upfronthosting.co.za>


New submission from irdb:

>>> s = '?'
Unsupported characters in input

I'm using windows 8 and Python 2.7.6.

The same line works perfectly if I save it in a module with encoding set to UTF-8; but it's really annoying that I can't test my code directly in IDLE.

----------
components: IDLE
messages: 203047
nosy: irdb
priority: normal
severity: normal
status: open
title: IDLE should use UTF-8 as it's default encoding
versions: Python 2.7

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

From report at bugs.python.org  Sat Nov 16 19:21:09 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 16 Nov 2013 18:21:09 +0000
Subject: [New-bugs-announce] [issue19626] test_email and
	Lib/email/_policybase.py failures with -OO
Message-ID: <1384626069.77.0.304780424813.issue19626@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

>From #19535:
$ ./python -OO -m test -v test_email 

[...]

======================================================================
ERROR: test_policy (unittest.loader.ModuleImportFailure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wolf/dev/py/py3k/Lib/unittest/case.py", line 57, in testPartExecutor
    yield
  File "/home/wolf/dev/py/py3k/Lib/unittest/case.py", line 571, in run
    testMethod()
  File "/home/wolf/dev/py/py3k/Lib/unittest/loader.py", line 32, in testFailure
    raise exception
ImportError: Failed to import test module: test_policy
Traceback (most recent call last):
  File "/home/wolf/dev/py/py3k/Lib/unittest/loader.py", line 272, in _find_tests
    module = self._get_module_from_name(name)
  File "/home/wolf/dev/py/py3k/Lib/unittest/loader.py", line 250, in _get_module_from_name
    __import__(name)
  File "/home/wolf/dev/py/py3k/Lib/test/test_email/test_policy.py", line 5, in <module>
    import email.policy
  File "/home/wolf/dev/py/py3k/Lib/email/policy.py", line 22, in <module>
    class EmailPolicy(Policy):
  File "/home/wolf/dev/py/py3k/Lib/email/_policybase.py", line 101, in _extend_docstrings
    cls.__doc__ = _append_doc(cls.__bases__[0].__doc__, cls.__doc__)
  File "/home/wolf/dev/py/py3k/Lib/email/_policybase.py", line 95, in _append_doc
    doc = doc.rsplit('\n', 1)[0]
AttributeError: 'NoneType' object has no attribute 'rsplit'

----------------------------------------------------------------------
Ran 68 tests in 0.028s

FAILED (errors=11)
Warning -- sys.path was modified by test_email
test test_email failed
1 test failed:
    test_email

----------
components: Library (Lib)
keywords: easy
messages: 203072
nosy: barry, ezio.melotti, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: test_email and Lib/email/_policybase.py failures with -OO
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 16 19:53:01 2013
From: report at bugs.python.org (Bulwersator)
Date: Sat, 16 Nov 2013 18:53:01 +0000
Subject: [New-bugs-announce] [issue19627] python open built-in function -
	"updating" is not defined
Message-ID: <1384627981.21.0.789966534785.issue19627@psf.upfronthosting.co.za>


New submission from Bulwersator:

see http://stackoverflow.com/questions/1466000/python-open-built-in-function-difference-between-modes-a-a-w-w-and-r - "The Python docs conveniently leave out the crucial explanation that "open the file for updating" means "opens the file for both reading and writing", which answers my question."

----------
assignee: docs at python
components: Documentation
messages: 203075
nosy: Bulwersator, docs at python
priority: normal
severity: normal
status: open
title: python open built-in function - "updating" is not defined

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

From report at bugs.python.org  Sat Nov 16 21:40:50 2013
From: report at bugs.python.org (Sworddragon)
Date: Sat, 16 Nov 2013 20:40:50 +0000
Subject: [New-bugs-announce] [issue19628] maxlevels -1 on compileall for
	unlimited recursion
Message-ID: <1384634450.77.0.212426893492.issue19628@psf.upfronthosting.co.za>


New submission from Sworddragon:

All functions of compileall are providing a maxlevels argument which defaults to 10. But it is currently not possible to disable this recursion limitation. Maybe it would be useful to have a special value like -1 to disable this limitation and allow to compile in an infinite amount of subdirectories.

Also I'm noticing maxlevels is the only argument which is not available on command line. Does it default there to 10 too? Maybe it would be useful if it could be configured too (in this case it could theoretically replace -l).

----------
components: Library (Lib)
messages: 203081
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: maxlevels -1 on compileall for unlimited recursion
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Sat Nov 16 22:23:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Nov 2013 21:23:12 +0000
Subject: [New-bugs-announce] [issue19629] support.rmtree fails on symlinks
	under Windows
Message-ID: <1384636992.45.0.350630415261.issue19629@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

support.rmtree doesn't work under Windows when there are symlinks (the symlinks aren't deleted anymore), while shutil.rmtree() works fine:

>>> support.rmtree("@test_2160_tmp")
>>> os.listdir("@test_2160_tmp")
['dirA', 'dirB', 'dirC', 'fileA', 'linkA', 'linkB']
>>> shutil.rmtree("@test_2160_tmp")
>>> os.listdir("@test_2160_tmp")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
FileNotFoundError: [WinError 3] The system cannot find the path specified: '@test_2160_tmp'

This breaks the pathlib tests under Windows with symlink privileges held.

----------
assignee: brian.curtin
components: Library (Lib), Tests
messages: 203085
nosy: brian.curtin, pitrou, tim.golden
priority: normal
severity: normal
stage: needs patch
status: open
title: support.rmtree fails on symlinks under Windows
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Nov 17 09:09:50 2013
From: report at bugs.python.org (Lukasz Mielicki)
Date: Sun, 17 Nov 2013 08:09:50 +0000
Subject: [New-bugs-announce] [issue19630] marshal.dump cannot write to
	temporary file
Message-ID: <1384675790.16.0.0477801542512.issue19630@psf.upfronthosting.co.za>


New submission from Lukasz Mielicki:

marshal.dump yields error when temporary file is given as a second argument.

import tempfile
import marshal
tmpfile = tempfile.TemporaryFile(mode='w+b')
# TypeError: marshal.dump() 2nd arg must be file
marshal.dump({}, tmpfile)

----------
components: Library (Lib)
messages: 203125
nosy: lm1
priority: normal
severity: normal
status: open
title: marshal.dump cannot write to temporary file
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov 17 14:35:47 2013
From: report at bugs.python.org (engelbert gruber)
Date: Sun, 17 Nov 2013 13:35:47 +0000
Subject: [New-bugs-announce] [issue19631] "exec" BNF in simple statements
Message-ID: <1384695347.39.0.482466517942.issue19631@psf.upfronthosting.co.za>


New submission from engelbert gruber:

the doc says::

  exec_stmt ::= "exec" or_expr ["in" expression ["," expression]]

imho it should read ::

  exec_stmt ::= "exec" expression ["in" expression ["," expression]]
                | "exec(" expression [ ", expression" [ ", expression" ]] ")"

----------
assignee: docs at python
components: Documentation
messages: 203146
nosy: docs at python, grubert
priority: normal
severity: normal
status: open
title: "exec" BNF in simple statements
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sun Nov 17 15:37:44 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Nov 2013 14:37:44 +0000
Subject: [New-bugs-announce] [issue19632] doc build warning
Message-ID: <1384699064.41.0.714714605877.issue19632@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

This is on 2.7:

reading sources... [100%] whatsnew/index                                                                                                              
/home/antoine/cpython/27/Doc/library/functions.rst:1186: WARNING: duplicate object description of repr, other instance in /home/antoine/cpython/27/Doc/library/repr.rst, use :noindex: for one of them
looking for now-outdated files... none found

----------
assignee: docs at python
components: Documentation
messages: 203180
nosy: docs at python, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: doc build warning
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov 17 23:26:57 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Nov 2013 22:26:57 +0000
Subject: [New-bugs-announce] [issue19633] test_wave: failures on PPC64
	buildbot
Message-ID: <1384727217.05.0.199132089753.issue19633@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Some test_wave are failing, but only on PPC64 (big endian, right?).

It may be related to issue #1575020.

http://buildbot.python.org/all/builders/PPC64%20PowerLinux%203.x/builds/1099/steps/test/logs/stdio


======================================================================
ERROR: test_unseekable_incompleted_write (test.test_wave.WavePCM16Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/audiotests.py", line 243, in test_unseekable_incompleted_write
    self.check_file(testfile, self.nframes + 1, self.frames)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/audiotests.py", line 84, in check_file
    self.assertEqual(f.readframes(nframes), frames)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/wave.py", line 257, in readframes
    data.fromfile(chunk.file.file, nitems)
EOFError: read() didn't return enough bytes

======================================================================
ERROR: test_unseekable_incompleted_write (test.test_wave.WavePCM32Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/audiotests.py", line 243, in test_unseekable_incompleted_write
    self.check_file(testfile, self.nframes + 1, self.frames)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/audiotests.py", line 84, in check_file
    self.assertEqual(f.readframes(nframes), frames)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/wave.py", line 257, in readframes
    data.fromfile(chunk.file.file, nitems)
EOFError: read() didn't return enough bytes

======================================================================
FAIL: test_write_array (test.test_wave.WavePCM16Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/audiotests.py", line 163, in test_write_array
    self.check_file(TESTFN, self.nframes, self.frames)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/audiotests.py", line 83, in check_file
    self.assertEqual(f.getnframes(), nframes)
AssertionError: 96 != 48

======================================================================
FAIL: test_write_memoryview (test.test_wave.WavePCM16Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/audiotests.py", line 171, in test_write_memoryview
    self.check_file(TESTFN, self.nframes, self.frames)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/audiotests.py", line 83, in check_file
    self.assertEqual(f.getnframes(), nframes)
AssertionError: 96 != 48

======================================================================
FAIL: test_write_array (test.test_wave.WavePCM32Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/audiotests.py", line 163, in test_write_array
    self.check_file(TESTFN, self.nframes, self.frames)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/audiotests.py", line 83, in check_file
    self.assertEqual(f.getnframes(), nframes)
AssertionError: 192 != 48

======================================================================
FAIL: test_write_memoryview (test.test_wave.WavePCM32Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/audiotests.py", line 171, in test_write_memoryview
    self.check_file(TESTFN, self.nframes, self.frames)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/audiotests.py", line 83, in check_file
    self.assertEqual(f.getnframes(), nframes)
AssertionError: 192 != 48

----------
components: Tests
messages: 203217
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_wave: failures on PPC64 buildbot
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 17 23:33:29 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Nov 2013 22:33:29 +0000
Subject: [New-bugs-announce] [issue19634]
	test_strftime.test_y_before_1900_nonwin() fails on AIX
Message-ID: <1384727609.57.0.295695955819.issue19634@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The isuse #13674 added tests on strftime() for %y format with year < 1900 on Windows. It looks like AIX doesn't support them.

http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/1039/steps/test/logs/stdio

======================================================================
FAIL: test_y_before_1900_nonwin (test.test_strftime.Y1900Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_strftime.py", line 193, in test_y_before_1900_nonwin
    time.strftime("%y", (1899, 1, 1, 0, 0, 0, 0, 0, 0)), "99")
AssertionError: '0/' != '99'
- 0/
+ 99

----------
components: Tests
messages: 203218
nosy: haypo, tim.golden
priority: normal
severity: normal
status: open
title: test_strftime.test_y_before_1900_nonwin() fails on AIX
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 17 23:53:22 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Nov 2013 22:53:22 +0000
Subject: [New-bugs-announce] [issue19635] asyncio should not depend on
	concurrent.futures, it is not always available
Message-ID: <1384728802.8.0.137912295354.issue19635@psf.upfronthosting.co.za>


New submission from STINNER Victor:

On old FreeBSD versions, concurrent.futures cannot be used. I don't remember why, it's probably related to semaphores (something like a low hardcoded limit). See for example first lines of Lib/test/test_concurrent_futures.py:
---
# Skip tests if _multiprocessing wasn't built.            
test.support.import_module('_multiprocessing')   
# Skip tests if sem_open implementation is broken.                        
test.support.import_module('multiprocessing.synchronize')
# import threading after _multiprocessing to raise a more revelant error  
# message: "No module named _multiprocessing". _multiprocessing is not compiled
# without thread support.
test.support.import_module('threading')
---

The problem is that asyncio always try to import concurrent.futures. Example: 

http://buildbot.python.org/all/builders/x86%20FreeBSD%206.4%203.x/builds/4213/steps/test/logs/stdio

test test_asyncio crashed -- Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/regrtest.py", line 1276, in runtest_inner
    test_runner()
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_asyncio/__init__.py", line 31, in test_main
    run_unittest(suite())
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_asyncio/__init__.py", line 21, in suite
    __import__(mod_name)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_asyncio/test_base_events.py", line 11, in <module>
    from asyncio import base_events
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/asyncio/__init__.py", line 21, in <module>
    from .futures import *
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/asyncio/futures.py", line 21, in <module>
    Error = concurrent.futures._base.Error
AttributeError: 'module' object has no attribute 'futures'

----------
messages: 203222
nosy: gvanrossum, haypo
priority: normal
severity: normal
status: open
title: asyncio should not depend on concurrent.futures, it is not always available
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 18 00:45:50 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Nov 2013 23:45:50 +0000
Subject: [New-bugs-announce] [issue19636] Fix usage of MAX_PATH in
	posixmodule.c
Message-ID: <1384731950.1.0.229673291292.issue19636@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The length of a path is not always correctly handled in posixmodule.c, the worst case is posix__getvolumepathname() which pass a length two times smaller than the buffer (GetVolumePathNameW() expects a number of WCHAR characters, not a number of bytes).

MAX_PATH includes the final null character, so no need to write MAX_PATH+1, especially when the function supports path longer than MAX_PATH-1 wide characters by allocating a larget buffer.

http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx
"
Maximum Path Length Limitation

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string<NUL>" where "<NUL>" represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)"

Attached patch fixes usage of MAX_PATH in posixmodule.c.

----------
files: win_max_path.patch
keywords: patch
messages: 203231
nosy: haypo
priority: normal
severity: normal
status: open
title: Fix usage of MAX_PATH in posixmodule.c
Added file: http://bugs.python.org/file32675/win_max_path.patch

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

From report at bugs.python.org  Mon Nov 18 02:16:33 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2013 01:16:33 +0000
Subject: [New-bugs-announce] [issue19637]
	test_subprocess.test_undecodable_env() failure on AIX
Message-ID: <1384737393.4.0.145203729418.issue19637@psf.upfronthosting.co.za>


New submission from STINNER Victor:

To analyze the following issue, I would like to know which locale encoding is used on AIX with the C locale. Example:

$ LC_ALL=C python -c 'import locale; print(locale.getpreferredencoding(False))'
ANSI_X3.4-1968

http://buildbot.python.org/all/builders/PPC64%20AIX%203.x

======================================================================
FAIL: test_undecodable_env (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_subprocess.py", line 1696, in test_undecodable_env
    self.assertEqual(stdout.decode('ascii'), ascii(value))
AssertionError: "'abc\\xff'" != "'abc\\udcff'"
- 'abc\xff'
?      ^
+ 'abc\udcff'
?      ^^^

----------
components: Tests
keywords: buildbot
messages: 203241
nosy: David.Edelsohn, haypo
priority: normal
severity: normal
status: open
title: test_subprocess.test_undecodable_env() failure on AIX
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 18 10:23:20 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 18 Nov 2013 09:23:20 +0000
Subject: [New-bugs-announce] [issue19638] dtoa: conversion from '__int64' to
	'int', possible loss of data
Message-ID: <1384766600.77.0.898971015118.issue19638@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch silences three compiler warnings on Win64

----------
components: Windows
files: dtoa.patch
keywords: patch
messages: 203264
nosy: christian.heimes, haypo, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: dtoa: conversion from '__int64' to 'int', possible loss of data
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file32683/dtoa.patch

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

From report at bugs.python.org  Mon Nov 18 10:35:16 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Mon, 18 Nov 2013 09:35:16 +0000
Subject: [New-bugs-announce] [issue19639] Improve re match objects display
Message-ID: <1384767316.36.0.259346591403.issue19639@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

When issue17087 was accepted, the documentation wasn't changed to reflect the new changes. The attached patch fixes this, replacing the old <_sre.Match object ...> with the deterministic repr of the match object.

----------
assignee: docs at python
components: Documentation
files: re_doc.patch
keywords: patch
messages: 203268
nosy: Claudiu.Popa, docs at python
priority: normal
severity: normal
status: open
title: Improve re match objects display
versions: Python 3.4
Added file: http://bugs.python.org/file32684/re_doc.patch

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

From report at bugs.python.org  Mon Nov 18 10:42:10 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2013 09:42:10 +0000
Subject: [New-bugs-announce] [issue19640] Drop _source attribute of
	namedtuple
Message-ID: <1384767730.42.0.112147293599.issue19640@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The definition of a new nametuple creates a large Python script to create the new type. The code stores the code in a private attribute:

    namespace = dict(__name__='namedtuple_%s' % typename)
    exec(class_definition, namespace)
    result = namespace[typename]
    result._source = class_definition

This attribute wastes memory, I don't understand the purpose of the attribute. It was not discussed in an issue, so I guess that there is no real use case:

changeset:   68879:bffdd7e9265c
user:        Raymond Hettinger <python at rcn.com>
date:        Wed Mar 23 12:52:23 2011 -0700
files:       Doc/library/collections.rst Lib/collections/__init__.py Lib/test/test_collections.py
description:
Expose the namedtuple source with a _source attribute.

Can we just drop this attribute to reduce the Python memory footprint?

----------
messages: 203270
nosy: haypo, rhettinger
priority: normal
severity: normal
status: open
title: Drop _source attribute of namedtuple
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 18 11:25:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Nov 2013 10:25:07 +0000
Subject: [New-bugs-announce] [issue19641] Add audioop.byteswap()
Message-ID: <1384770307.37.0.611849831444.issue19641@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The audio modules often need convert between little endian and big endian data. The array module can be used to byteswap 16- and 32-bit samples, but it can't help with 24-bit samples. Python implemented function for swapping bytes is not very efficient. In any case the use of array is not so simple (see issue19276, issue19633).

The proposed patch adds efficient byteswap() function in the audioop module. byteswap(fragment, width) byteswaps every "width"-byte sample in the fragment and returns modified data.

----------
components: Library (Lib)
files: audioop_byteswap.patch
keywords: patch
messages: 203273
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add audioop.byteswap()
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32686/audioop_byteswap.patch

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

From report at bugs.python.org  Mon Nov 18 12:45:26 2013
From: report at bugs.python.org (Ivan Radic)
Date: Mon, 18 Nov 2013 11:45:26 +0000
Subject: [New-bugs-announce] [issue19642] shutil to support equivalent of:
	rm -f /dir/*
Message-ID: <1384775126.27.0.181995142425.issue19642@psf.upfronthosting.co.za>


New submission from Ivan Radic:

Shutil supports deleting of files and directories but it offers no way to delete directory content (without deleting directory itself). Shell programming includes a lot of "rm -rf /dir" and "rm -f /dir/*", and there is no direct equivalent of these commands in Python. Educate me if I am wrong on this claim.

Sure, I can write a quick for loop, and delete each subfile and subdirectory manually, but adding such ability to shutil would greatly enhance readability and simplicity of Python file handling scripts.

Implementation could be as simply as :
import os
for root, dirs, files in os.walk(top, topdown=False):
    for name in files:
        os.remove(os.path.join(root, name))
    for name in dirs:
        os.rmdir(os.path.join(root, name))

(example taken from http://docs.python.org/2/library/os.html#os.walk)

----------
components: IO
messages: 203283
nosy: ivan.radic
priority: normal
severity: normal
status: open
title: shutil to support equivalent of: rm -f /dir/*
type: enhancement
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Mon Nov 18 13:11:11 2013
From: report at bugs.python.org (Ivan Radic)
Date: Mon, 18 Nov 2013 12:11:11 +0000
Subject: [New-bugs-announce] [issue19643] shutil rmtree fails on readonly
	files in Windows
Message-ID: <1384776671.66.0.696428447361.issue19643@psf.upfronthosting.co.za>


New submission from Ivan Radic:

shutil.rmtree works nice on Windows until it hits file with read only attribute set. Workaround is to provide a onerror parameter as a function that checks and removes file attribute before attempting to delete it. Can option to delete read_only files be integrated in shutil.rmtree?

Example output in In Python 2.7:
shutil.rmtree("C:\\2")

Traceback (most recent call last):
  File "<pyshell#60>", line 1, in <module>
    shutil.rmtree("C:\\2")
  File "C:\Program Files (x86)\Python.2.7.3\lib\shutil.py", line 250, in rmtree
    onerror(os.remove, fullname, sys.exc_info())
  File "C:\Program Files (x86)\Python.2.7.3\lib\shutil.py", line 248, in rmtree
    os.remove(fullname)
WindowsError: [Error 5] Access is denied: 'C:\\2\\read_only_file.txt'

Example output in In Python 3.3:
shutil.rmtree("C:\\2")
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    shutil.rmtree("C:\\2")
  File "C:\Program Files (x86)\Python.3.3.0\lib\shutil.py", line 460, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "C:\Program Files (x86)\Python.3.3.0\lib\shutil.py", line 367, in _rmtree_unsafe
    onerror(os.unlink, fullname, sys.exc_info())
  File "C:\Program Files (x86)\Python.3.3.0\lib\shutil.py", line 365, in _rmtree_unsafe
    os.unlink(fullname)
PermissionError: [WinError 5] Access is denied: 'C:\\2\\read_only_file.txt'

----------
components: IO
messages: 203285
nosy: ivan.radic
priority: normal
severity: normal
status: open
title: shutil rmtree fails on readonly files in Windows
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Nov 18 13:43:50 2013
From: report at bugs.python.org (Dmitry)
Date: Mon, 18 Nov 2013 12:43:50 +0000
Subject: [New-bugs-announce] [issue19644] Failing of interpreter when
	slicing a string in MacOS X	Maverics
Message-ID: <1384778630.66.0.716752649372.issue19644@psf.upfronthosting.co.za>


New submission from Dmitry:

I launch python3 on MacOS X Maverics and do the following things:
a = '12345'
a[:-0]
And the interpreter (application python3) crashes with sigfault. Everything is OK with python2 on this computer (the same code returnes '') and with the same version of Python on linux computer

----------
assignee: ronaldoussoren
components: Macintosh
files: ?????? ?????? 2013-11-18 ? 16.39.46.png
messages: 203289
nosy: ronaldoussoren, torbad
priority: normal
severity: normal
status: open
title: Failing of interpreter when slicing a string in MacOS X Maverics
versions: Python 3.3
Added file: http://bugs.python.org/file32690/?????? ?????? 2013-11-18 ? 16.39.46.png

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

From report at bugs.python.org  Mon Nov 18 15:38:14 2013
From: report at bugs.python.org (Gregory Salvan)
Date: Mon, 18 Nov 2013 14:38:14 +0000
Subject: [New-bugs-announce] [issue19645] Improving unittest assertions
Message-ID: <1384785494.56.0.149196031493.issue19645@psf.upfronthosting.co.za>


New submission from Gregory Salvan:

Actually unittest assertions depends on testcase class forcing us to extend it to add assertions and to use it to make assertions outside tests.

Seeing interests in rethinking the way assertions are done in unittest, this issue first intent to collect feedback in order to suggest an implementation that fit the most.

Some notes from private discussions:
- it was briefly discussed here #18054.
- taking care of popular solutions like py.test's rich assert
statements and the testtools matcher objects.
- avoid unnecessary complexity, staying focused on value

My opinion:
- must not change unittest api
- may be put in a seperate package (splitting "unittest" in "unittest" and "assertions")
- Open to hide assertions exceptions in optimized mode or providing a simple way to change default behaviour (log, skip... instead of throwing unhandled exception).

----------
components: Tests
messages: 203295
nosy: Gregory.Salvan, michael.foord, ncoghlan, rbcollins
priority: normal
severity: normal
status: open
title: Improving unittest assertions
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Nov 18 22:15:06 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Nov 2013 21:15:06 +0000
Subject: [New-bugs-announce] [issue19646] Use PyUnicodeWriter in repr(dict)
Message-ID: <1384809306.12.0.437955519329.issue19646@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch modify dict_repr() function to use the _PyUnicodeWriter API instead of building a list of short strings with PyUnicode_AppendAndDel() and calling PyUnicode_Join() at the end to join the list. PyUnicode_Append() is inefficient because it has to allocate a new string instead of reusing the same buffer.

_PyUnicodeWriter API has a different design. It overallocates a buffer to write Unicode characters and shrink the buffer at the end. It is faster according to my micro benchmark.


$ ./python ~/prog/HG/misc/python/benchmark.py compare_to pyaccu writer
Common platform:
CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Python unicode implementation: PEP 393
CFLAGS: -Wno-unused-result -Werror=declaration-after-statement -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
Timer precision: 40 ns
Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09)
Platform: Linux-3.9.4-200.fc18.x86_64-x86_64-with-fedora-18-Spherical_Cow
Bits: int=32, long=64, long long=64, size_t=64, void*=64
Timer: time.perf_counter

Platform of campaign pyaccu:
Date: 2013-11-18 21:37:44
Python version: 3.4.0a4+ (default:fc7ceb001eec, Nov 18 2013, 21:29:41) [GCC 4.7.2 20121109 (Red Hat 4.7.2-8)]
SCM: hg revision=fc7ceb001eec tag=tip branch=default date="2013-11-18 21:11 +0100"

Platform of campaign writer:
Date: 2013-11-18 22:10:40
Python version: 3.4.0a4+ (default:fc7ceb001eec+, Nov 18 2013, 22:10:12) [GCC 4.7.2 20121109 (Red Hat 4.7.2-8)]
SCM: hg revision=fc7ceb001eec+ tag=tip branch=default date="2013-11-18 21:11 +0100"

--------------------------------------+-------------+--------------
Tests???????????????????????????????? | ?????pyaccu | ???????writer
--------------------------------------+-------------+--------------
{"a": 1}????????????????????????????? | ?603 ns (*) | 496 ns (-18%)
dict(zip("abc", range(3)))??????????? | 1.05 us (*) | 904 ns (-14%)
{"%03d":"abc" for k in range(10)}???? | ?631 ns (*) | 501 ns (-21%)
{"%100d":"abc" for k in range(10)}??? | ?660 ns (*) | 484 ns (-27%)
{k:"a" for k in range(10**3)}???????? | ?235 us (*) | 166 us (-30%)
{k:"abc" for k in range(10**3)}?????? | ?245 us (*) | 177 us (-28%)
{"%100d":"abc" for k in range(10**3)} | ?668 ns (*) | 478 ns (-28%)
{k:"a" for k in range(10**6)}???????? | ?258 ms (*) | 186 ms (-28%)
{k:"abc" for k in range(10**6)}?????? | ?265 ms (*) | 184 ms (-31%)
{"%100d":"abc" for k in range(10**6)} | ?652 ns (*) | 489 ns (-25%)
--------------------------------------+-------------+--------------
Total???????????????????????????????? | ?523 ms (*) | 369 ms (-29%)
--------------------------------------+-------------+--------------

----------
components: Unicode
files: dict_repr_writer.patch
keywords: patch
messages: 203322
nosy: ezio.melotti, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use PyUnicodeWriter in repr(dict)
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32694/dict_repr_writer.patch

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

From report at bugs.python.org  Mon Nov 18 22:35:56 2013
From: report at bugs.python.org (Stefan Holek)
Date: Mon, 18 Nov 2013 21:35:56 +0000
Subject: [New-bugs-announce] [issue19647] unittest.TestSuite consumes tests
Message-ID: <1384810556.81.0.647879257341.issue19647@psf.upfronthosting.co.za>


New submission from Stefan Holek:

This test passed in Python <= 3.3 but fails in 3.4:

    def testTestSuiteConsumesTest(self):
        class MyTestCase(unittest.TestCase):
            def testMethod(self):
                pass
        test = MyTestCase('testMethod')
        suite = unittest.TestSuite((test,))
        result = unittest.TestResult()
        self.assertEqual(next(iter(suite)), test)
        suite.run(result)
        self.assertEqual(next(iter(suite)), test)

The suite contains None after it has been run in Python 3.4.

----------
components: Library (Lib)
messages: 203325
nosy: stefanholek
priority: normal
severity: normal
status: open
title: unittest.TestSuite consumes tests
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 19 05:10:17 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 19 Nov 2013 04:10:17 +0000
Subject: [New-bugs-announce] [issue19648] Empty tests in pickletester need
	to be implemented or	removed
Message-ID: <1384834217.52.0.300793745392.issue19648@psf.upfronthosting.co.za>


New submission from Zachary Ware:

There are a couple of tests in pickletester that should either be implemented or removed, namely test_reduce and test_getinitargs of AbstractPickleTests.

I don't know enough about pickling to suggest which route should be taken or how, so I'll leave that up to anyone who wants to write a patch :)

----------
components: Tests
keywords: easy
messages: 203338
nosy: alexandre.vassalotti, pitrou, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Empty tests in pickletester need to be implemented or removed
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Nov 19 08:44:40 2013
From: report at bugs.python.org (Ned Deily)
Date: Tue, 19 Nov 2013 07:44:40 +0000
Subject: [New-bugs-announce] [issue19649] Clean up OS X framework and
	universal bin directories
Message-ID: <1384847080.69.0.0507465882105.issue19649@psf.upfronthosting.co.za>


New submission from Ned Deily:

There are currently various differences in the files installed by "make altinstall" and "make install" for OS X framework (./configure --enable-framework) and/or OS X universal (--with-universal-archs) configurations.  Some of the differences are cosmetic; some are just wrong (e.g. broken symlinks).  This issue proposes to fix the differences such that the same set of file names will be installed to the $exec_prefix/bin directory for non-framework ("unix" or "shared") configures, and to the framework bin and unixtools directories for framework configurations.  The current standard altinstall and install non-framework configurations are the baselines.

For framework configurations:

- "make altinstall" creates a complete set of symlinks in the unixtools directory ($prefix/bin, default /usr/local/bin) to each file/link installed to the framework bin directory. (fixed)

- "make install" creates symlinks to the additional (unversioned) files/links created in the framework bin directory. (fixed)

- The obsolete and undocumented pythonw* symlinks will no longer be installed anywhere.  Currently, these are all linked to or copies of their python* counterparts; there is no difference in behavior between them on OS X and hasn't been for many years and releases.  (Note, these are not to be confused with the unchanged "pythonw.c" executable which is what is executed to "boostrap" from the command line into the Python app bundle within a framework install.)

- pythonX.Ym will be fixed to be replaced by a link to "python.c" executable; currently it is a copy of the python interpreter. (bug)

For OS X universal non-framework build configurations with a combination of 32-bit and 64-bit architectures, "make altinstall" will now additionally install a 32-bit-only Python executable as pythonX.Y-32, like the universal framework configurations currently do (new).  (Actually, the framework build installs a 32-bit-only "pythonw.c" bootstrap executable ... but that's not important now).  This ensures that users have a consistent and reliable way to invoke universal 64-/32-bit Pythons in 32-bit mode.

FTR, using "arch -i386 python3" is not reliable in that any subprocesses created by the interpreter will revert to the system's default mode which is 64-bit (where possible) for 10.6+.  With "python3-32", 32-bit mode is maintained in subprocesses if sys.executable is used to supply the interpreter name for the subprocess, as of Python 3.3+.

For reference, here are current 3.3 bin layouts: left side is the baseline, right side indicates variances from the baseline with "X.Y" and "X" referring to the Python version ("3.4" and "3"), "(..)" indicating a missing file, directory, or Makefile target, and "m" referring to the PEP 3149 ABI identifier:

=================   =========================
install             framework install
    altinstall          framework altinstall
=================   =========================
2to3
    2to3-X.Y

idleX
    idleX.Y

pydocX
    pydocX.Y

pythonX             pythonwX
    pythonX.Y           pythonX,pythonwX.Y
    pythonX.Ym

pythonX-config
pythonX.Y-config
    pythonX.Ym-config

pyvenv
    pyvenv-X.Y
-----------------   -------------------------
(for universal builds)
                    pythonX.Y-32,pythonX-32,
                    pythonwX.Y-32,pythonwX-32
=================   =========================


=================   =========================
install             (framework unixtools)
    altinstall          framework altunixtools
=================   =========================
2to3
    2to3-X.Y

idleX
    idleX.Y

pydocX
    pydocX.Y

pythonX             pythonwX
    pythonX.Y           pythonwX.Y
    pythonX.Ym          (pythonX.Ym)

pythonX-config
pythonX.Y-config
    pythonX.Ym-config   (pythonX.Ym-config)

pyvenv
    pyvenv-X.Y
-----------------   -------------------------
(for universal builds)
                    pythonX.Y-32,pythonX-32,
                    pythonwX.Y-32,pythonwX-32
=================   =========================



Proposed for 3.4 - for non-framework, framework bin, and framework unixtools directories:

=================
install          
    altinstall   
=================
2to3
    2to3-X.Y

idleX
    idleX.Y

pydocX
    pydocX.Y

pythonX
    pythonX.Y
    pythonX.Ym

pythonX-config
pythonX.Y-config
    pythonX.Ym-config

pyvenv
    pyvenv-X.Y
-----------------
(for universal builds) 
pythonX-32
    pythonX.Y-32
=================

----------
assignee: ned.deily
components: Build, Macintosh
messages: 203342
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: patch review
status: open
title: Clean up OS X framework and universal bin directories
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 19 10:53:29 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Nov 2013 09:53:29 +0000
Subject: [New-bugs-announce] [issue19650]
	test_multiprocessing_spawn.test_mymanager_context()	crashed
	with STATUS_ACCESS_VIOLATION
Message-ID: <1384854809.52.0.780579914331.issue19650@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The following failure may be related to #19466. I failed to reproduce it on my Windows 7 VM (I compiled Python in 32-bit mode).

http://buildbot.python.org/all/builders/x86%20Windows%20Server%202008%20%5BSB%5D%203.x/builds/1697/steps/test/logs/stdio

======================================================================
FAIL: test_mymanager_context (test.test_multiprocessing_spawn.WithManagerTestMyManager)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\test\_test_multiprocessing.py", line 1960, in test_mymanager_context
    self.assertEqual(manager._process.exitcode, 0)
AssertionError: 3221225477 != 0


3221225477 is 0xC0000005 in hex, Windows error code:
#define STATUS_ACCESS_VIOLATION  ((NTSTATUS)0xC0000005L)

----------
components: Windows
messages: 203346
nosy: haypo, sbt
priority: normal
severity: normal
status: open
title: test_multiprocessing_spawn.test_mymanager_context() crashed with STATUS_ACCESS_VIOLATION

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

From report at bugs.python.org  Tue Nov 19 11:05:20 2013
From: report at bugs.python.org (John Dobson)
Date: Tue, 19 Nov 2013 10:05:20 +0000
Subject: [New-bugs-announce] [issue19651] Mac OSX 10.9 segmentation fault 11
	with Python 3.3.3
Message-ID: <1384855520.97.0.361030514177.issue19651@psf.upfronthosting.co.za>


New submission from John Dobson:

2 consecutive commands into interactive shell still results in segmentation fault 11, patch 18458 reports skipped as patch not needed for 3.3

----------
assignee: ronaldoussoren
components: Macintosh
messages: 203347
nosy: johndobson, ronaldoussoren
priority: normal
severity: normal
status: open
title: Mac OSX 10.9 segmentation fault 11 with Python 3.3.3
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Tue Nov 19 12:20:25 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Nov 2013 11:20:25 +0000
Subject: [New-bugs-announce] [issue19652] test_asyncio:
	test_subprocess_send_signal() hangs on	buildbot "AMD64 Snow
	Leop 3.x"
Message-ID: <1384860025.78.0.97947017549.issue19652@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I didn't understand the purpose of the issue #19334: it doesn't mention the OS nor the test. I prefer to create a more specific issue, so here you have one specific hang.

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

[385/385] test_asyncio
Timeout (1:00:00)!
Thread 0x00007fff71296cc0 (most recent call first):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/selectors.py", line 291 in select
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/base_events.py", line 614 in _run_once
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/base_events.py", line 153 in run_forever
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/asyncio/base_events.py", line 172 in run_until_complete
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_asyncio/test_events.py", line 1155 in test_subprocess_send_signal
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/case.py", line 571 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/case.py", line 610 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 117 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 79 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 117 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 79 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 117 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 79 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/runner.py", line 168 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/support/__init__.py", line 1685 in _run_suite
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/support/__init__.py", line 1719 in run_unittest
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_asyncio/__init__.py", line 31 in test_main
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 1276 in runtest_inner
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 965 in runtest
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 532 in main
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 1560 in main_in_temp_cwd
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 1585 in <module>
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/runpy.py", line 73 in _run_code
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/runpy.py", line 160 in _run_module_as_main
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/__main__.py", line 3, in <module>
    regrtest.main_in_temp_cwd()
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 1560, in main_in_temp_cwd
    main()
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 736, in main
    raise Exception("Child error on {}: {}".format(test, result[1]))
Exception: Child error on test_asyncio: Exit code 1
make: *** [buildbottest] Error 1

----------
messages: 203358
nosy: David.Edelsohn, db3l, gvanrossum, haypo, koobs, larry, ncoghlan, neologix, pitrou, python-dev, sbt, skrah
priority: normal
severity: normal
status: open
title: test_asyncio: test_subprocess_send_signal() hangs on buildbot "AMD64 Snow Leop 3.x"
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 19 14:00:58 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Nov 2013 13:00:58 +0000
Subject: [New-bugs-announce] [issue19653] Generalize usage of
	_PyUnicodeWriter for repr(obj): add	_PyObject_ReprWriter()
Message-ID: <1384866058.1.0.245171525218.issue19653@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The _PyUnicodeWriter API avoids creation of temporary Unicode strings and has very good performances to build Unicode strings with the PEP 393 (compact unicode string).

Attached patch adds a _PyObject_ReprWriter() function to avoid creation of tempory Unicode string while calling repr(obj) on containers like tuple, list or dict.

I did something similar for str%args and str.format(args).

To avoid the following code, we might add something to PyTypeObject, maybe a new tp_repr_writer field.

+    if (PyLong_CheckExact(v)) {
+        return _PyLong_FormatWriter(writer, v, 10, 0);
+    }
+    if (PyUnicode_CheckExact(v)) {
+        return _PyUnicode_ReprWriter(writer, v);
+    }
+    if (PyList_CheckExact(v)) {
+        return _PyList_ReprWriter(writer, v);
+    }
+    if (PyTuple_CheckExact(v)) {
+        return _PyTuple_ReprWriter(writer, v);
+    }
+    if (PyList_CheckExact(v)) {
+        return _PyList_ReprWriter(writer, v);
+    }
+    if (PyDict_CheckExact(v)) {
+        return _PyDict_ReprWriter(writer, v);
+    }

For example, repr(list(range(10))) ('[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]')  should only allocate one buffer of 37 bytes and then shink it to 30 bytes.

I guess that benchmarks are required to justify such changes.

----------
files: repr_writer.patch
keywords: patch
messages: 203371
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Generalize usage of _PyUnicodeWriter for repr(obj): add _PyObject_ReprWriter()
versions: Python 3.4
Added file: http://bugs.python.org/file32701/repr_writer.patch

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

From report at bugs.python.org  Tue Nov 19 14:44:01 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Nov 2013 13:44:01 +0000
Subject: [New-bugs-announce] [issue19654] test_tkinter sporadic failures on
	"x86 Tiger 3.x"	buildbot
Message-ID: <1384868641.08.0.388268151531.issue19654@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/7331/steps/test/logs/stdio

======================================================================
FAIL: test_debug (tkinter.test.test_tkinter.test_text.TextTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/tkinter/test/test_tkinter/test_text.py", line 22, in test_debug
    self.assertEqual(text.debug(), 0)
AssertionError: '0' != 0

======================================================================
FAIL: test_insertborderwidth (tkinter.test.test_tkinter.test_widgets.EntryTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/tkinter/test/test_tkinter/test_widgets.py", line 329, in test_insertborderwidth
    self.checkPixelsParam(widget, 'insertborderwidth', 0, 1.3, -2)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/tkinter/test/widget_tests.py", line 167, in checkPixelsParam
    conv=conv1, **kwargs)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/tkinter/test/widget_tests.py", line 57, in checkParam
    self.assertEqual2(widget[name], expected, eq=eq)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/tkinter/test/widget_tests.py", line 41, in assertEqual2
    self.assertEqual(actual, expected, msg)
AssertionError: 0 != 1

======================================================================
FAIL: test_insertborderwidth (tkinter.test.test_tkinter.test_widgets.SpinboxTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/tkinter/test/test_tkinter/test_widgets.py", line 329, in test_insertborderwidth
    self.checkPixelsParam(widget, 'insertborderwidth', 0, 1.3, -2)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/tkinter/test/widget_tests.py", line 167, in checkPixelsParam
    conv=conv1, **kwargs)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/tkinter/test/widget_tests.py", line 57, in checkParam
    self.assertEqual2(widget[name], expected, eq=eq)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/tkinter/test/widget_tests.py", line 41, in assertEqual2
    self.assertEqual(actual, expected, msg)
AssertionError: 0 != 1

----------
assignee: ronaldoussoren
components: Macintosh, Tkinter
keywords: buildbot
messages: 203374
nosy: haypo, ronaldoussoren
priority: normal
severity: normal
status: open
title: test_tkinter sporadic failures on "x86 Tiger 3.x" buildbot
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 19 15:01:36 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 19 Nov 2013 14:01:36 +0000
Subject: [New-bugs-announce] [issue19655] Replace the ASDL parser carried
	with CPython
Message-ID: <1384869696.09.0.547082157855.issue19655@psf.upfronthosting.co.za>


New submission from Eli Bendersky:

It was mentioned in one of the recent python-dev threads that making the Python code-base simpler to encourage involvement of contributors is a goal, so I figured this may be relevant.

I've recently written a new parser for the ASDL specification language from scratch and think it may be beneficial to replace the existing parser we use:

* The existing parser uses an external parser-generator (Spark) that we carry around in the Parser/ directory; the new parser is a very simple stand-alone recursive descent, which makes it easier to maintain and doesn't require a familiarity with Spark.
* The new code is significantly smaller. ~400 LOC for the whole stand-alone parser (asdl.py) as opposed to >1200 LOC for the existing parser+Spark.
* The existing asdl.py is old code and was only superficially ported to Python 3.x - this shows, and isn't a good example of using modern Python techniques. My asdl.py uses Python 3.4 with modern idioms like dict comprehensions, generators and enums.

For a start, it may be easier to review the parser separately and not as a patch file. I split it to a stand-alone project here: https://github.com/eliben/asdl_parser

The asdl.py there is a drop-in replacement for Parser/asdl.py; asdl_c.py is for Parser/asdl_c.py - with tiny modifications to interface the new parser (mainly getting rid of some Spark-induced quirks). The AST .c and .h files produced are identical. The repo also has some tests for the parser, which we may find useful in adding to the test suite or the Parser directory.

----------
assignee: eli.bendersky
components: Build
messages: 203376
nosy: brett.cannon, eli.bendersky, ncoghlan
priority: normal
severity: normal
stage: patch review
status: open
title: Replace the ASDL parser carried with CPython
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Nov 19 19:09:47 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Nov 2013 18:09:47 +0000
Subject: [New-bugs-announce] [issue19656] Add Py3k warning for non-ascii
	bytes literals
Message-ID: <1384884587.46.0.636196916046.issue19656@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

PEP 3112 had added bytes literals in 2.6. But bytes literals in 2.x are just synonyms to 8-bit string literals and allow non-ascii characters, while bytes literals in 3.x allows only ascii characters. For better forward compatibility with 3.x the proposed patch adds Py3k syntax warning for non-ascii bytes literals in 2.7.

----------
components: Interpreter Core
files: py3kwarn_nonascii_bytes_literals.patch
keywords: patch
messages: 203406
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add Py3k warning for non-ascii bytes literals
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file32705/py3kwarn_nonascii_bytes_literals.patch

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

From report at bugs.python.org  Tue Nov 19 19:26:54 2013
From: report at bugs.python.org (Garrett Cooper)
Date: Tue, 19 Nov 2013 18:26:54 +0000
Subject: [New-bugs-announce] [issue19657] List comprehension conditional
	evaluation order seems	backwards
Message-ID: <1384885614.87.0.844122195952.issue19657@psf.upfronthosting.co.za>


New submission from Garrett Cooper:

I was a bit surprised when I ran into this issue when porting some nose tests from Windows to Linux:

#!/usr/bin/env python
with open('/etc/services') as fd:
    lines = fd.readlines()
lines.append('')
SERVICES = [line.split()[0] for line in lines
                                if (line and not line.startswith('#'))]

$ python list_comprehension.py
Traceback (most recent call last):
  File "list_comprehension.py", line 5, in <module>
    if (line and not line.startswith('#'))]
IndexError: list index out of range
$ python3.2 list_comprehension.py
Traceback (most recent call last):
  File "list_comprehension.py", line 4, in <module>
    SERVICES = [line.split()[0] for line in lines
  File "list_comprehension.py", line 5, in <listcomp>
    if (line and not line.startswith('#'))]
IndexError: list index out of range
$ python -V
Python 2.7.5
$ python3.2 -V
Python 3.2.5

This is occurring of course because the .split() is being done on an empty line.

The docs don't note (at least in the list comprehension section [*]) that if-statements are evaluated after the value is generated for the current index in the loop. This seems very backwards because generating a value could in fact be very expensive, whereas determining whether or not a precondition has been met should be less expensive.

What could/should be done is one of two things: 1. evaluation order should be clearly spelled out in the docs, or 2. the list comprehension handling code should be changed to support evaluating the conditional statements before calculating a result. Otherwise discouraging use of [map+]filter (at least pylint does that) seems incredibly unwise as I can get the functionality I want in a single line as opposed to an unrolled loop.

[*] http://docs.python.org/2/tutorial/datastructures.html#list-comprehensions

----------
messages: 203409
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: List comprehension conditional evaluation order seems backwards

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

From report at bugs.python.org  Tue Nov 19 22:25:43 2013
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Tue, 19 Nov 2013 21:25:43 +0000
Subject: [New-bugs-announce] [issue19658] inspect.getsource weird case
Message-ID: <1384896343.05.0.723899962428.issue19658@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt:

got:
>>> l = {}
>>> import inspect
>>> exec(compile('def fun(): pass', '', 'exec'), l, l)
>>> inspect.getsource(l['fun'])
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "/home/private/.local/lib/python3.3/inspect.py", line 726, in getsource
    lines, lnum = getsourcelines(object)
  File "/home/private/.local/lib/python3.3/inspect.py", line 715, in getsourcelines
    lines, lnum = findsource(object)
  File "/home/private/.local/lib/python3.3/inspect.py", line 553, in findsource
    if not sourcefile and file[0] + file[-1] != '<>':
IndexError: string index out of range


expected:
>>> l = {}
>>> import inspect
>>> exec(compile('def fun(): pass', '', 'exec'), l, l)
>>> inspect.getsource(l['fun'])
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "/home/private/.local/lib/python3.3/inspect.py", line 726, in getsource
    lines, lnum = getsourcelines(object)
  File "/home/private/.local/lib/python3.3/inspect.py", line 715, in getsourcelines
    lines, lnum = findsource(object)
  File "/home/private/.local/lib/python3.3/inspect.py", line 563, in findsource
    raise IOError('could not get source code')
OSError: could not get source code

this is a extraction, it appears that python in certein circumstances creates code objects with that setup on its own,
im still further investigating

----------
messages: 203426
nosy: Ronny.Pfannschmidt
priority: normal
severity: normal
status: open
title: inspect.getsource weird case
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Nov 20 01:24:40 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Nov 2013 00:24:40 +0000
Subject: [New-bugs-announce] [issue19659] Document Argument Clinic?
Message-ID: <1384907080.98.0.430269997716.issue19659@psf.upfronthosting.co.za>


New submission from STINNER Victor:

While modifying zlibmodule.c, Serhiy told me that argument clinic is now used in zlibmodule.c. Running "./python Tools/clinic/clinic.py -f Modules/zlibmodule.c" does modify the file, so I misuse argument clinic.

I saw Argument Clinic on Youtube but it didn't help...
http://www.youtube.com/watch?v=kQFKtI6gn9Y

Would it be possible to explain how to use clinic.py, explain the format, etc. in the Python documentation? Somewhere near Doc/c-api/.

----------
messages: 203452
nosy: haypo, larry
priority: normal
severity: normal
status: open
title: Document Argument Clinic?
versions: Python 3.4

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

From report at bugs.python.org  Wed Nov 20 02:27:05 2013
From: report at bugs.python.org (James Powell)
Date: Wed, 20 Nov 2013 01:27:05 +0000
Subject: [New-bugs-announce] [issue19660] decorator syntax: allow testlist
	instead of just	dotted_name
Message-ID: <1384910825.18.0.00604679093295.issue19660@psf.upfronthosting.co.za>


New submission from James Powell:

Decorator syntax currently allows only a dotted_name after the @. As far as I can tell, this was a gut-feeling decision made by Guido. [1]

I spoke with Nick Coghlan at PyTexas about this, and he suggested that if someone did the work, there might be interest in revisiting this restriction.

The attached patch allows any testlist to follow the @.

The following are now valid:

@(lambda x:x)
def f():
    pass

@(spam if p else eggs)
def f():
    pass

@spam().ham().eggs()
def f():
    pass

[1] http://mail.python.org/pipermail/python-dev/2004-August/046711.html

----------
components: Interpreter Core
messages: 203456
nosy: james
priority: normal
severity: normal
status: open
title: decorator syntax: allow testlist instead of just dotted_name
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Nov 20 10:45:07 2013
From: report at bugs.python.org (dellair jie)
Date: Wed, 20 Nov 2013 09:45:07 +0000
Subject: [New-bugs-announce] [issue19661] Python: RuntimeError: invalid slot
	offset when importing	a module
Message-ID: <1384940707.67.0.629503813291.issue19661@psf.upfronthosting.co.za>


New submission from dellair jie:

Dear all,

I am getting above error when trying to import ssl module. In fact, the error showed up during the build and _ssl module was added to the failed module list. However, the compilation and link went well. 

There was no error on compilation and link phases, only some warnings. However, during Python build, there is an import phase right after the link, which shows the same error as stated.
building '_ssl' extension 
xlc_r -DNDEBUG -O -IInclude -I. -I/usr/local/include -c /aix/Modules/_ssl.c -o build/temp.aix-6.1-3.3/aix/Modules/_ssl.o
 "/aix/Modules/_ssl.c", line 262.17: 1506-196 (W) Initialization between types "void*" and "struct _object*(*)(struct {...}*)" is not allowed.
 /aix/Modules/ld_so_aix xlc_r -bI:/aix/Modules/python.exp build/temp.aix-6.1-3.3/aix/Modules/_ssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.aix-6.1-3.3/_ssl.so
 ld: 0711-224 WARNING: Duplicate symbol: .bcopy 
ld: 0711-224 WARNING: Duplicate symbol: .memcpy 
ld: 0711-224 WARNING: Duplicate symbol: .memmove 
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. 
*** WARNING: importing extension "_ssl" failed with build/lib.aix-6.1-3.3/_ssl.so: <class 'RuntimeError'>: invalid slot offset: <traceback object at 0x3017e9e0>

I went through google to search for similar issue/solution however no succeeds. Hence I suppose it is a bug.

Env: Python: 3.3.2 
OpenSSL: 0.9.8y (also tried 0.9.7) 
OS: AIX 6.1 (also tried on HPUX_1131_IA, same problem)

----------
components: Build
messages: 203465
nosy: dellair.jie
priority: normal
severity: normal
status: open
title: Python: RuntimeError: invalid slot offset when importing a module
type: compile error
versions: Python 3.3

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

From report at bugs.python.org  Wed Nov 20 11:51:43 2013
From: report at bugs.python.org (Leslie P. Polzer)
Date: Wed, 20 Nov 2013 10:51:43 +0000
Subject: [New-bugs-announce] [issue19662] smtpd.py should not decode utf-8
Message-ID: <1384944703.82.0.967643613195.issue19662@psf.upfronthosting.co.za>


New submission from Leslie P. Polzer:

http://hg.python.org/cpython/file/3.3/Lib/smtpd.py#l289

as of now decodes incoming bytes as UTF-8.

An SMTP server must not attempt to interpret characters beyond ASCII, however. Originally mail servers were not 8-bit clean, meaning they would only guarantee the lower 7 bits of each octet to be preserved.
However even then they were not expected to choke on any input because of attempts to decode it into a specific extended charset. Whenever a mail server does not need to interpret data (like base64-encoded auth information) it is simply left alone and passed through.

I am not aware of the reasons that caused the current state, but to correct this behavior and make it possible to support the 8BITMIME feature I suggest decoding received bytes as latin1, leaving it to the user to reinterpret it as UTF-8 or whatever charset they need. Any other simple extended encoding could be used for this, but latin1 is the default in asynchat.

The documentation should also mention charset handling. I'll be happy to submit a patch for both code and docs.

----------
components: Library (Lib)
messages: 203467
nosy: skypher
priority: normal
severity: normal
status: open
title: smtpd.py should not decode utf-8
type: enhancement
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/issue19662>
_______________________________________

From report at bugs.python.org  Wed Nov 20 17:25:45 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Wed, 20 Nov 2013 16:25:45 +0000
Subject: [New-bugs-announce] [issue19663] Not so correct error message when
	initializing	defaultdict
Message-ID: <1384964745.34.0.550819526657.issue19663@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

>>> from collections import defaultdict
>>> defaultdict('')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: first argument must be callable
>>> defaultdict(None)
defaultdict(None, {})
>>> None()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object is not callable

After patch:

>>> from collections import defaultdict
>>> defaultdict('')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: first argument must be callable or None

----------
components: Extension Modules
files: fix_error_message_default_dict.patch
keywords: patch
messages: 203500
nosy: rhettinger, vajrasky
priority: normal
severity: normal
status: open
title: Not so correct error message when initializing defaultdict
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32722/fix_error_message_default_dict.patch

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

From report at bugs.python.org  Wed Nov 20 18:09:42 2013
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 20 Nov 2013 17:09:42 +0000
Subject: [New-bugs-announce] [issue19664] UserDict test assumes ordered dict
	repr
Message-ID: <1384967382.38.0.811715737768.issue19664@psf.upfronthosting.co.za>


New submission from Larry Hastings:

If you run Lib/test/test_userdict.py enough times, sooner or later it'll produce a spurious error.  I wrote a shell script that ran "./python -m test test_userdict" a zillion times; here's a snippet of output from running that script:

[...]
1 test OK.
[1/1] test_userdict
1 test OK.
[1/1] test_userdict
1 test OK.
[1/1] test_userdict
test test_userdict failed -- Traceback (most recent call last):
  File "/home/larry/src/python/clinic/Lib/test/test_userdict.py", line 48, in test_all
    self.assertEqual(repr(u2), repr(d2))
AssertionError: "{'one': 1, 'two': 2}" != "{'two': 2, 'one': 1}"
- {'one': 1, 'two': 2}
+ {'two': 2, 'one': 1}


1 test failed:
    test_userdict
[1/1] test_userdict
1 test OK.
[1/1] test_userdict
1 test OK.
[...]

Line 48 reads as follows:
    self.assertEqual(repr(u2), repr(d2))

I realize this code is ancient--but it seems to rely on repr of a dict producing consistent output, which is silly and has always been wrong.

Raymond, you want to take this?

----------
components: Library (Lib)
messages: 203509
nosy: larry, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: UserDict test assumes ordered dict repr
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Nov 20 19:02:46 2013
From: report at bugs.python.org (Mark Wolf)
Date: Wed, 20 Nov 2013 18:02:46 +0000
Subject: [New-bugs-announce] [issue19665] test_logging fails with
	SMTPHandler timeout
Message-ID: <1384970566.07.0.397875675827.issue19665@psf.upfronthosting.co.za>


New submission from Mark Wolf:

Similar to http://bugs.python.org/issue14644 but with Arch Linux instead of OS X. I built python according the dev guide then ran the test suite with `./python -m test -vj3 test_logging` and failed in the SMTPHandlerTest. `self.handled.is_set()` returns false after a 5 second timeout. In one of the comments in the OS X bug linked above, it suggests changing the timeout to 15 seconds. This causes the test to pass (actually anything slightly over 5 sec seems to be okay). Not sure if this is a fragile test or a bug in Lib.logging. The patch ups the timeout by a second, which passes on my machine but might still fail on others if it actually is a fragile test issue. The failing test runner output for test_logging can be found here: https://gist.github.com/m3wolf/7563541

I'm just jumping into python dev for the first time; any constructive comments are appreciated.

----------
components: Tests
files: test_logging.patch
keywords: patch
messages: 203515
nosy: canisdirus
priority: normal
severity: normal
status: open
title: test_logging fails with SMTPHandler timeout
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32726/test_logging.patch

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

From report at bugs.python.org  Wed Nov 20 19:14:16 2013
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 20 Nov 2013 18:14:16 +0000
Subject: [New-bugs-announce] [issue19666] Format string for ASCII unicode or
	bytes-like object as	readonly buffer
Message-ID: <1384971256.72.0.0181602551145.issue19666@psf.upfronthosting.co.za>


New submission from Christian Heimes:

I could use a format string for either ASCII unicode or bytes buffer in a few places, e.g. 

a* (bytes, bytearray, bytes-like object or ASCII unicode) [Py_buffer]

Like y* it should handle PyBUF_SIMPLE with 'C' contiguous but it should only accept one dimensional buffers. In case the object is an ASCII PyUnicode_Object it should return its ASCII data as Py_buffer.

----------
components: Interpreter Core
messages: 203516
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: Format string for ASCII unicode or bytes-like object as readonly buffer
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Nov 20 19:19:36 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Nov 2013 18:19:36 +0000
Subject: [New-bugs-announce] [issue19667] Add the "htmlcharrefreplace" error
	handler
Message-ID: <1384971576.04.0.0704268767649.issue19667@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds the htmlcharrefreplace_errors() function which implements the "htmlcharrefreplace" error handler in the html module. This error handler is almost same as the "xmlcharrefreplace" error handler, but first try to replace an unencodable character to HTML named character reference. Result is a little more human-readable than with "xmlcharrefreplace".

See also a discussion on Python-Ideas: http://comments.gmane.org/gmane.comp.python.ideas/21307 .

----------
components: Library (Lib)
files: htmlcharrefreplace.patch
keywords: patch
messages: 203517
nosy: ezio.melotti, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add the "htmlcharrefreplace" error handler
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32727/htmlcharrefreplace.patch

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

From report at bugs.python.org  Wed Nov 20 20:35:02 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Nov 2013 19:35:02 +0000
Subject: [New-bugs-announce] [issue19668] Add support of the cp1125 encoding
Message-ID: <1384976102.43.0.570343368296.issue19668@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds support of the CP1125 encoding.

The CP1125 encoding (also known as IBM866, CP866U (in Microsoft), 866nav (in TeX), RUSCII) is standard DOS encoding for Ukrainian language. It is only one DOS encoding (or at least most popular) suitable for Ukrainian. It is Ukrainian government standard for DOS. The CP1125 encoding differs from CP866 encoding only in 6 codes for Ukrainian letters.

http://www-03.ibm.com/systems/resources/systems_i_software_globalization_pdf_cp01125z.pdf
http://cp866u.codeplex.com/
ftp://tug.org/texlive/Contents/live/texmf-dist/tex/latex/cyrillic/cp866nav.def
http://segfault.kiev.ua/cyrillic-encodings/#ruscii

----------
components: Unicode
files: encoding_cp1125.patch
keywords: patch
messages: 203523
nosy: doerwalter, ezio.melotti, haypo, lemburg, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add support of the cp1125 encoding
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32733/encoding_cp1125.patch

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

From report at bugs.python.org  Wed Nov 20 21:20:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Nov 2013 20:20:25 +0000
Subject: [New-bugs-announce] [issue19669] remove mention of the old LaTeX
	docs
Message-ID: <1384978825.66.0.587760682432.issue19669@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The devguide mentions the old LaTeX doc format:
http://docs.python.org/devguide/documenting.html#differences-to-the-latex-markup

This doesn't really sound useful anymore, so many years later.

----------
assignee: docs at python
components: Devguide, Documentation
messages: 203527
nosy: docs at python, ezio.melotti, fdrake, georg.brandl, pitrou
priority: low
severity: normal
status: open
title: remove mention of the old LaTeX docs

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

From report at bugs.python.org  Wed Nov 20 21:23:24 2013
From: report at bugs.python.org (Patrick Bogen)
Date: Wed, 20 Nov 2013 20:23:24 +0000
Subject: [New-bugs-announce] [issue19670] SimpleCookie Generates
	Non-RFC6265-Compliant Cookies
Message-ID: <1384979004.61.0.0353093814459.issue19670@psf.upfronthosting.co.za>


New submission from Patrick Bogen:

SimpleCookie uses _quote to quote cookie values, which converts special characters to \OCTAL notation. This is not RFC6265 compliance, which requires- in part- that cookie values do not contain backslashes:

 cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
 cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
                       ; US-ASCII characters excluding CTLs,
                       ; whitespace DQUOTE, comma, semicolon,
                       ; and backslash

----------
components: Library (Lib)
messages: 203529
nosy: pdbogen
priority: normal
severity: normal
status: open
title: SimpleCookie Generates Non-RFC6265-Compliant Cookies
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov 20 22:29:40 2013
From: report at bugs.python.org (Sworddragon)
Date: Wed, 20 Nov 2013 21:29:40 +0000
Subject: [New-bugs-announce] [issue19671] Option to select the optimization
	level on compileall
Message-ID: <1384982980.31.0.989044075216.issue19671@psf.upfronthosting.co.za>


New submission from Sworddragon:

Currently on calling one of the compileall functions it is not possible to pass the optimization level as argument. The bytecode will be created depending of the optimization level of the current script instance. But if a script wants to compile .pyc files for one destination and .pyo files for another destination this will be a little tricky.

----------
components: Library (Lib)
messages: 203533
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Option to select the optimization level on compileall
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Nov 20 22:49:29 2013
From: report at bugs.python.org (Sworddragon)
Date: Wed, 20 Nov 2013 21:49:29 +0000
Subject: [New-bugs-announce] [issue19672] Listing of all exceptions for
	every function
Message-ID: <1384984169.87.0.182568254733.issue19672@psf.upfronthosting.co.za>


New submission from Sworddragon:

Currently the documentation does sometimes say about specific exceptions but most times not. As I'm often catching exceptions to ensure a high stability this gets a little difficult. For example print() can trigger a BrokenPipeError and the most file functions like flush() can trigger other related IOError's.

So I would like to see something like a listing on every function which contains all exceptions that may appear. Also there are some special cases like close(). For example it can trigger an IOError too if there are pending write operations due to an implicit call of flush(). But if the file object is opened in read-only mode or there are no write operations this can't happen. Maybe such additional information can be added too.

----------
assignee: docs at python
components: Documentation
messages: 203535
nosy: Sworddragon, docs at python
priority: normal
severity: normal
status: open
title: Listing of all exceptions for every function
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Nov 20 23:20:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Nov 2013 22:20:45 +0000
Subject: [New-bugs-announce] [issue19673] PEP 428 implementation
Message-ID: <1384986045.13.0.536884886996.issue19673@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Here is a patch integrating pathlib and its docs.
Note that this was already briefly reviewed by Guido.

----------
components: Library (Lib)
files: pathlib.patch
keywords: patch
messages: 203540
nosy: larry, pitrou
priority: release blocker
severity: normal
stage: patch review
status: open
title: PEP 428 implementation
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32736/pathlib.patch

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

From report at bugs.python.org  Thu Nov 21 00:52:26 2013
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 20 Nov 2013 23:52:26 +0000
Subject: [New-bugs-announce] [issue19674] Add introspection information for
	builtins
Message-ID: <1384991546.24.0.134873558554.issue19674@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Let's see if we can get introspection information for builtins using the Clinic for 3.4.

Georg suggested part of the approach while we were hanging out in Tokyo.  I'd considered it previously before but dispensed with the idea because it seemed too loopy.  Actually it seems to work great.  

The approach:

* Clinic generates an extra first line for the docstring, that looks like "def (...)\n".  (Note: no function name!)

* The PyCFunctionObject __doc__ getter detects this line and skips it if present.

* Add a new getter to PyCFunctionObject, which I've called "__textsig__", that returns this first line if present in the docstring.  (It skips the "def " at the front, and clips it at the newline.)

* inspect now notices if it's passed in a PyCFunctionObject.  If it gets one, it checks to see if it has a valid __textsig__.  If it does, it parses it (using ast.parse) and produces a valid signature.

Advantages of this approach:
* It was easy to do and took very few lines of code.

* For signatures that are impossible to convert to Clinic, we can
  write the metadata by hand.

Disadvantages of this approach:
* Uh, nothing, really!

The next step is probably to convert pydoc to use inspect.signature instead of the manky old methods it currently uses.  After that, clean up the patch, and add a unit test or two.

What do you think?

----------
assignee: larry
components: Interpreter Core
files: larry.introspection.for.builtins.patch.1.txt
messages: 203549
nosy: brett.cannon, georg.brandl, gvanrossum, larry
priority: normal
severity: normal
stage: patch review
status: open
title: Add introspection information for builtins
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32739/larry.introspection.for.builtins.patch.1.txt

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

From report at bugs.python.org  Thu Nov 21 02:52:19 2013
From: report at bugs.python.org (Dustin Oprea)
Date: Thu, 21 Nov 2013 01:52:19 +0000
Subject: [New-bugs-announce] [issue19675] Pool dies with excessive workers,
	but does not cleanup
Message-ID: <1384998739.89.0.441869255184.issue19675@psf.upfronthosting.co.za>


New submission from Dustin Oprea:

If you provide a number of processes to a Pool that the OS can't fulfill, Pool will raise an OSError and die, but does not cleanup any of the processes that it has forked.

This is a session in Python where I can allocate a large, but fulfillable, number of processes (just to exhibit what's possible in my current system):

>>> from multiprocessing import Pool
>>> p = Pool(500)
>>> p.close()
>>> p.join()

Now, this is a request that will fail. However, even after this fails, I can't allocate even a single worker:

>>> p = Pool(700)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/__init__.py", line 232, in Pool
    return Pool(processes, initializer, initargs, maxtasksperchild)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/pool.py", line 159, in __init__
    self._repopulate_pool()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/pool.py", line 222, in _repopulate_pool
    w.start()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/process.py", line 130, in start
    self._popen = Popen(self)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/forking.py", line 121, in __init__
    self.pid = os.fork()
OSError: [Errno 35] Resource temporarily unavailable

>>> p = Pool(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/__init__.py", line 232, in Pool
    return Pool(processes, initializer, initargs, maxtasksperchild)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/pool.py", line 159, in __init__
    self._repopulate_pool()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/pool.py", line 222, in _repopulate_pool
    w.start()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/process.py", line 130, in start
    self._popen = Popen(self)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/forking.py", line 121, in __init__
    self.pid = os.fork()
OSError: [Errno 35] Resource temporarily unavailable

The only way to clean this up is to close the parent (the interpreter).

I'm submitting a patch for 2.7.6 that intercepts exceptions and cleans-up the workers before bubbling. The affected method is _repopulate_pool(), and appears to be the same in 2.7.6, 3.3.3, and probably every other recent version of Python.

This is the old version:

        for i in range(self._processes - len(self._pool)):
            w = self.Process(target=worker,
                             args=(self._inqueue, self._outqueue,
                                   self._initializer,
                                   self._initargs, self._maxtasksperchild)
                            )
            self._pool.append(w)
            w.name = w.name.replace('Process', 'PoolWorker')
            w.daemon = True
            w.start()
            debug('added worker')

This is the new version:

        try:
            for i in range(self._processes - len(self._pool)):
                w = self.Process(target=worker,
                                 args=(self._inqueue, self._outqueue,
                                       self._initializer,
                                       self._initargs, self._maxtasksperchild)
                                )
                self._pool.append(w)
                w.name = w.name.replace('Process', 'PoolWorker')
                w.daemon = True
                w.start()
                debug('added worker')
        except:
            debug("Process creation error. Cleaning-up (%d) workers." % (len(self._pool)))

            for process in self._pool:
                if process.is_alive() is False:
                    continue

                process.terminate()
                process.join()

            debug("Processing cleaning-up. Bubbling error.")
            raise

This is what happens, now: I can go from requesting a number that's too high to immediately requesting one that's also high but within limits, and there's now no problem as all resources have been freed:

>>> from multiprocessing import Pool
>>> p = Pool(700)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/__init__.py", line 232, in Pool
    return Pool(processes, initializer, initargs, maxtasksperchild)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/pool.py", line 159, in __init__
    self._repopulate_pool()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/pool.py", line 224, in _repopulate_pool
    w.start()
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/process.py", line 130, in start
    self._popen = Popen(self)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/multiprocessing/forking.py", line 121, in __init__
    self.pid = os.fork()
OSError: [Errno 35] Resource temporarily unavailable
>>> p = Pool(500)
>>> p.close()
>>> p.join()

----------
components: Library (Lib)
files: pool.py.patch_2.7.6_20131120-1959
messages: 203556
nosy: dsoprea
priority: normal
severity: normal
status: open
title: Pool dies with excessive workers, but does not cleanup
type: resource usage
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file32742/pool.py.patch_2.7.6_20131120-1959

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

From report at bugs.python.org  Thu Nov 21 08:41:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Nov 2013 07:41:46 +0000
Subject: [New-bugs-announce] [issue19676] Add the "namereplace" error handler
Message-ID: <1385019706.69.0.579937406555.issue19676@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch adds the "namereplace" error handler. This error handler is almost same as the "backslashreplace" error handler, but use \N{...} escape sequences if there is a character name in Unicode database. Result is a little more human-readable (but less portable) than with "backslashreplace".

>>> '? x??'.encode('ascii', 'namereplace')
b'\\N{FOR ALL} x\\N{ELEMENT OF}\\N{BLACK-LETTER CAPITAL R}'

The proposition was discussed and bikeshedded on Python-Ideas: http://comments.gmane.org/gmane.comp.python.ideas/21296 .

----------
components: Unicode
files: namereplace_errors.patch
keywords: patch
messages: 203579
nosy: ezio.melotti, haypo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add the "namereplace" error handler
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32748/namereplace_errors.patch

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

From report at bugs.python.org  Thu Nov 21 09:54:34 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 Nov 2013 08:54:34 +0000
Subject: [New-bugs-announce] [issue19677] IDLE displaying a CoreAnimation
	warning
Message-ID: <1385024074.44.0.183399663193.issue19677@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

When running IDLE on a fresh 2.7.6 install on OS X 10.9, I'm seeing the following message generated periodically:

CoreAnimation: warning, deleted thread with uncommitted CATransaction; set CA_DEBUG_TRANSACTIONS=1 in environment to log backtraces.

----------
components: IDLE
messages: 203588
nosy: rhettinger
priority: low
severity: normal
status: open
title: IDLE displaying a CoreAnimation warning
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 21 11:56:50 2013
From: report at bugs.python.org (Leslie P. Polzer)
Date: Thu, 21 Nov 2013 10:56:50 +0000
Subject: [New-bugs-announce] [issue19678] smtpd.py: channel should be passed
	to process_message
Message-ID: <1385031410.17.0.520349427654.issue19678@psf.upfronthosting.co.za>


New submission from Leslie P. Polzer:

process_message needs to have access to the channel state since it needs to make decisions based on the authentication or transport associated with the channel. It should be either the first or the last arg.

I can provide a patch for this. Should backwards compatibility be achieved by using the inspect module to check the signature of process_message and call it accordingly?

----------
components: Library (Lib), email
messages: 203609
nosy: barry, lpolzer, r.david.murray
priority: normal
severity: normal
status: open
title: smtpd.py: channel should be passed to process_message
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov 21 11:59:58 2013
From: report at bugs.python.org (Leslie P. Polzer)
Date: Thu, 21 Nov 2013 10:59:58 +0000
Subject: [New-bugs-announce] [issue19679] smtpd.py: implement ESMTP status
	messages
Message-ID: <1385031598.99.0.0454554803988.issue19679@psf.upfronthosting.co.za>


New submission from Leslie P. Polzer:

ESMTP status messages (of the form "xab x.y.z test") can be added easily to the current status message strings emitted by the SMTP server and channel classes. They are not harmful if the user's server only intends to support plain HELO-SMTP

I will provide a patch within due time unless someone disagrees.

----------
components: Library (Lib), email
messages: 203610
nosy: barry, lpolzer, r.david.murray
priority: normal
severity: normal
status: open
title: smtpd.py: implement ESMTP status messages
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov 21 13:29:45 2013
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Thu, 21 Nov 2013 12:29:45 +0000
Subject: [New-bugs-announce] [issue19680] Help missing for exec and print
Message-ID: <1385036985.98.0.128644104733.issue19680@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

Steps to reproduce:

[bkabrda at zizalka python]$ python
>>> help()
help> keywords
<snip>
# prints lots of keywords including "print" and "exec"
</snip>
help> print
no documentation found for 'print'


So either keywords should not list "print" and "exec" or the documentation for them should be built. IIUC, the help for these should be part of pydoc_data/topics.py, which gets generated by Doc/tools/sphinxext/pyspecific.py. However, in revision [1] some topics got removed ("print" and "exec" amongst them) without the commit message saying anything helpful. Either way, this is inconsistent and should be fixed (assuming that Python 2.7 is still supposed to get this sort of fixes).

Thanks.

[1] http://hg.python.org/cpython/rev/76aa98f69251

----------
assignee: docs at python
components: Documentation
messages: 203625
nosy: bkabrda, docs at python
priority: normal
severity: normal
status: open
title: Help missing for exec and print
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 21 15:34:36 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 21 Nov 2013 14:34:36 +0000
Subject: [New-bugs-announce] [issue19681] test_repr
	(test.test_functools.TestPartialC) failures
Message-ID: <1385044476.32.0.977131973544.issue19681@psf.upfronthosting.co.za>


New submission from Christian Heimes:

test_repr of test.test_functools.TestPartialC fails sometimes because the test scenario depends on the order of items in a Python dict. The order is not stable and may change. Before PEP 456 was committed the order of items was stable most of the time. Nowadays the random seed has an impact on the order.

http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/9609

======================================================================
FAIL: test_repr (test.test_functools.TestPartialC)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_functools.py", line 174, in test_repr
    repr(f))
AssertionError: 'func[43 chars]D8>, b=<object object at 0x09D08B48>, a=<objec[20 chars]28>)' != 'func[43 chars]D8>, a=<object object at 0x09D08B28>, b=<objec[20 chars]48>)'
- functools.partial(<function capture at 0x0A2A72D8>, b=<object object at 0x09D08B48>, a=<object object at 0x09D08B28>)
+ functools.partial(<function capture at 0x0A2A72D8>, a=<object object at 0x09D08B28>, b=<object object at 0x09D08B48>)


======================================================================
FAIL: test_repr (test.test_functools.TestPartialCSubclass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_functools.py", line 174, in test_repr
    repr(f))
AssertionError: 'Part[41 chars]D8>, b=<object object at 0x09D08DC8>, a=<objec[20 chars]A8>)' != 'Part[41 chars]D8>, a=<object object at 0x09D08BA8>, b=<objec[20 chars]C8>)'
- PartialSubclass(<function capture at 0x0A2A72D8>, b=<object object at 0x09D08DC8>, a=<object object at 0x09D08BA8>)
+ PartialSubclass(<function capture at 0x0A2A72D8>, a=<object object at 0x09D08BA8>, b=<object object at 0x09D08DC8>)

----------
components: Tests
messages: 203632
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: test_repr (test.test_functools.TestPartialC) failures
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov 21 16:09:42 2013
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 21 Nov 2013 15:09:42 +0000
Subject: [New-bugs-announce] [issue19682] _ssl won't compile with OSX 10.9
	SDK
Message-ID: <1385046582.33.0.832181733081.issue19682@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

I get a compilation error for _ssl when building on OSX 10.9 using the 10.9 SDK, the relevant error:

/Users/ronald/Projects/python/rw/default/Modules/_ssl.c:1029:24: error: no member named 'crldp' in 'struct x509_st'
    dps = certificate->crldp;
          ~~~~~~~~~~~  ^

Looking at /usr/include/openssl/x509.h in the 10.9 SDK that does not have a crldp member:

struct x509_st
        {
        X509_CINF *cert_info;
        X509_ALGOR *sig_alg;
        ASN1_BIT_STRING *signature;
        int valid;
        int references;
        char *name;
        CRYPTO_EX_DATA ex_data;
        /* These contain copies of various extension values */
        long ex_pathlen;
        long ex_pcpathlen;
        unsigned long ex_flags;
        unsigned long ex_kusage;
        unsigned long ex_xkusage;
        unsigned long ex_nscert;
        ASN1_OCTET_STRING *skid;
        struct AUTHORITY_KEYID_st *akid;
        X509_POLICY_CACHE *policy_cache;
#ifndef OPENSSL_NO_RFC3779
        STACK_OF(IPAddressFamily) *rfc3779_addr;
        struct ASIdentifiers_st *rfc3779_asid;
#endif
#ifndef OPENSSL_NO_SHA
        unsigned char sha1_hash[SHA_DIGEST_LENGTH];
#endif
        X509_CERT_AUX *aux;
        } /* X509 */;

Note that OSX ships a fairly ancient version of OpenSSL, libssl.dylib is 0.9.8. 

(Marked as a regression because 3.3 and 2.7 can be build with the system version of OpenSSL).

----------
assignee: ronaldoussoren
components: Extension Modules, Macintosh
keywords: 3.3regression
messages: 203634
nosy: ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: _ssl won't compile with OSX 10.9 SDK
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov 21 16:17:39 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 21 Nov 2013 15:17:39 +0000
Subject: [New-bugs-announce] [issue19683] test_minidom has many empty tests
Message-ID: <1385047059.66.0.790496754317.issue19683@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Many of the tests in test_minidom on 2.7 are empty, that is they are defined as "def testSomeFunction(self): pass".

I've marked this issue as "easy" since I suspect a lot of the tests can be either backported from 3.x, or removed if they don't exist in 3.x.

----------
components: Tests
keywords: easy
messages: 203637
nosy: zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: test_minidom has many empty tests
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 21 18:36:55 2013
From: report at bugs.python.org (Will Adams)
Date: Thu, 21 Nov 2013 17:36:55 +0000
Subject: [New-bugs-announce] [issue19684] OS X 10.6.8 Crash when opening a
	file
Message-ID: <1385055415.68.0.92413833052.issue19684@psf.upfronthosting.co.za>


New submission from Will Adams:

Apologies in advance if I am posting incorrectly.  This is my first post here.  

IDLE crashes when I open a *.py file on my old mac pro from IDLE.  I haven't seen this on version 3.3.2, but I need to do some work in version 2.7 today so I downloaded 2.7.6 and ran into this system dump:


Process:         Python [1832]
Path:            /Applications/Python 2.7/IDLE.app/Contents/MacOS/Python
Identifier:      org.python.IDLE
Version:         2.7.6 (2.7.6)
Code Type:       X86 (Native)
Parent Process:  launchd [143]

Date/Time:       2013-11-21 11:24:30.080 -0600
OS Version:      Mac OS X 10.6.8 (10K549)
Report Version:  6


Interval Since Last Report:          3154609 sec
Crashes Since Last Report:           42
Per-App Interval Since Last Report:  642 sec
Per-App Crashes Since Last Report:   5
Anonymous UUID:                      3134C4C6-DD18-4049-8638-9A3C0FBC6343

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000044014000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Application Specific Information:
objc_msgSend() selector name: release


Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib               	0x91b97f8b objc_msgSend + 27
1   com.apple.CoreFoundation      	0x95f57bcd _CFAutoreleasePoolPop + 253
2   com.apple.Foundation          	0x94287976 NSPopAutoreleasePool + 76
3   com.apple.Foundation          	0x9428789e -[NSAutoreleasePool drain] + 130
4   Tk                            	0x0072df18 XQueryPointer + 2393
5   Tk                            	0x0072e219 Tk_MacOSXSetupTkNotifier + 634
6   Tcl                           	0x005f5ab4 Tcl_DoOneEvent + 310
7   _tkinter.so                   	0x002f1322 Tkapp_MainLoop + 450
8   org.python.python             	0x000c4230 PyEval_EvalFrameEx + 25344
9   org.python.python             	0x000c6a2c PyEval_EvalCodeEx + 2012
10  org.python.python             	0x000c4825 PyEval_EvalFrameEx + 26869
11  org.python.python             	0x000c554c PyEval_EvalFrameEx + 30236
12  org.python.python             	0x000c6a2c PyEval_EvalCodeEx + 2012
13  org.python.python             	0x000c6b77 PyEval_EvalCode + 87
14  org.python.python             	0x000eaf5c PyRun_FileExFlags + 172
15  org.python.python             	0x000eb284 PyRun_SimpleFileExFlags + 532
16  org.python.python             	0x00103412 Py_Main + 3410
17  Python                        	0x00001f65 start + 53

Thread 1:  Dispatch queue: com.apple.libdispatch-manager
0   libSystem.B.dylib             	0x9196a382 kevent + 10
1   libSystem.B.dylib             	0x9196aa9c _dispatch_mgr_invoke + 215
2   libSystem.B.dylib             	0x91969f59 _dispatch_queue_invoke + 163
3   libSystem.B.dylib             	0x91969cfe _dispatch_worker_thread2 + 240
4   libSystem.B.dylib             	0x91969781 _pthread_wqthread + 390
5   libSystem.B.dylib             	0x919695c6 start_wqthread + 30

Thread 2:
0   libSystem.B.dylib             	0x91962ac6 select$DARWIN_EXTSN + 10
1   Tcl                           	0x0062b737 Tcl_InitNotifier + 1643
2   libSystem.B.dylib             	0x91971259 _pthread_start + 345
3   libSystem.B.dylib             	0x919710de thread_start + 34

Thread 3:
0   libSystem.B.dylib             	0x91969412 __workq_kernreturn + 10
1   libSystem.B.dylib             	0x919699a8 _pthread_wqthread + 941
2   libSystem.B.dylib             	0x919695c6 start_wqthread + 30

Thread 4:  com.apple.CFSocket.private
0   libSystem.B.dylib             	0x91962ac6 select$DARWIN_EXTSN + 10
1   com.apple.CoreFoundation      	0x95f9ac53 __CFSocketManager + 1091
2   libSystem.B.dylib             	0x91971259 _pthread_start + 345
3   libSystem.B.dylib             	0x919710de thread_start + 34

Thread 5:
0   libSystem.B.dylib             	0x91943afa mach_msg_trap + 10
1   libSystem.B.dylib             	0x91944267 mach_msg + 68
2   com.apple.CoreFoundation      	0x95f5b2df __CFRunLoopRun + 2079
3   com.apple.CoreFoundation      	0x95f5a3c4 CFRunLoopRunSpecific + 452
4   com.apple.CoreFoundation      	0x95f60304 CFRunLoopRun + 84
5   com.apple.DesktopServices     	0x947b1b3d TSystemNotificationTask::SystemNotificationTaskProc(void*) + 643
6   ...ple.CoreServices.CarbonCore	0x97ac554a PrivateMPEntryPoint + 68
7   libSystem.B.dylib             	0x91971259 _pthread_start + 345
8   libSystem.B.dylib             	0x919710de thread_start + 34

Thread 6:
0   libSystem.B.dylib             	0x91969412 __workq_kernreturn + 10
1   libSystem.B.dylib             	0x919699a8 _pthread_wqthread + 941
2   libSystem.B.dylib             	0x919695c6 start_wqthread + 30

Thread 7:
0   libSystem.B.dylib             	0x91969412 __workq_kernreturn + 10
1   libSystem.B.dylib             	0x919699a8 _pthread_wqthread + 941
2   libSystem.B.dylib             	0x919695c6 start_wqthread + 30

Thread 8:
0   libSystem.B.dylib             	0x91969412 __workq_kernreturn + 10
1   libSystem.B.dylib             	0x919699a8 _pthread_wqthread + 941
2   libSystem.B.dylib             	0x919695c6 start_wqthread + 30

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x15f39ea0  ebx: 0x95f2ae2d  ecx: 0x95c3b8b4  edx: 0x15f42110
  edi: 0x44014000  esi: 0x15f39ea0  ebp: 0xbfffeb58  esp: 0xbfffeb34
   ss: 0x0000001f  efl: 0x00010206  eip: 0x91b97f8b   cs: 0x00000017
   ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
  cr2: 0x44014000

Binary Images:
    0x1000 -     0x1ff7 +Python ??? (???) <5E42C8AF-4D60-8991-99DF-D9F7D9BE5018> /Applications/Python 2.7/IDLE.app/Contents/MacOS/Python
    0x4000 -   0x146fff +org.python.python 2.7.6, (c) 2004-2013 Python Software Foundation. (2.7.6) <9C0C57BD-C006-1A8D-90F5-422FD3D05652> /Library/Frameworks/Python.framework/Versions/2.7/Python
  0x2ed000 -   0x2f4ff7 +_tkinter.so ??? (???) <7DDA96E8-45E2-2385-2045-37F603882100> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_tkinter.so
  0x577000 -   0x649fe7  Tcl 8.5.7 (8.5.7) <39BA8680-BB16-CC3D-15AC-B32ECE556FC6> /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
  0x662000 -   0x75bff7  Tk 8.5.7 (8.5.7) <17E7216E-45B5-BAFE-6F87-79AC9A3937D1> /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk
  0x7e3000 -   0x7e6ff7 +strop.so ??? (???) <099FF8EE-ED78-C47B-C64F-6B0510025DEF> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/strop.so
  0x7eb000 -   0x7f4ff7 +_socket.so ??? (???) <B989F71D-43D0-8163-05EE-29462ABD15A8> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_socket.so
 0x1300000 -  0x1301ff7 +_functools.so ??? (???) <A69F8971-17DD-6EF8-4ACB-ACADE9A3001B> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_functools.so
 0x1304000 -  0x1308ff7 +_ssl.so ??? (???) <5B67DF16-508B-3839-42DE-0270C85627CA> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_ssl.so
 0x130d000 -  0x130eff7 +cStringIO.so ??? (???) <721E10B1-65B4-ABA6-90E6-D92952BE3AF8> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cStringIO.so
 0x1312000 -  0x1313ff7 +time.so ??? (???) <5ECA4EBE-2EC9-3107-DCF4-45050F936643> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/time.so
 0x1318000 -  0x131bff7 +_collections.so ??? (???) <78F6EE64-6C57-7632-ADBE-FABDF9630120> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_collections.so
 0x1320000 -  0x1323ff7 +operator.so ??? (???) <C61843E8-61D2-104C-C3BC-A296888E7B24> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/operator.so
 0x1369000 -  0x136eff7 +itertools.so ??? (???) <7FAA1ED6-582E-BEEA-379F-F82A7923D051> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/itertools.so
 0x1376000 -  0x1377ff7 +_heapq.so ??? (???) <FA517395-8DD2-B833-7C71-297CA2E5CC71> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_heapq.so
 0x137b000 -  0x138eff7 +_io.so ??? (???) <1B9DFDC8-9D70-4256-B603-31A943100A2F> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
 0x1443000 -  0x1445ff7 +select.so ??? (???) <5DF162CA-80BD-B25D-0243-E8D56AC37868> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/select.so
 0x144a000 -  0x144bff7 +fcntl.so ??? (???) <7D79E04D-6165-E55E-0917-AC482EB3FC59> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/fcntl.so
 0x144e000 -  0x1451ff7 +_struct.so ??? (???) <21694FA7-1A29-5746-7D5C-4F57EB4BA72A> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_struct.so
 0x1458000 -  0x145afe7 +binascii.so ??? (???) <600CFC44-CBCF-E606-E378-AA5D6F00CB56> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/binascii.so
 0x14de000 -  0x14e2ff7 +math.so ??? (???) <E69F8DAC-CC96-392E-FFDE-749ACA982564> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/math.so
 0x14e7000 -  0x14e8ff7 +_hashlib.so ??? (???) <8E1D90CA-C55F-B334-F047-8743905D87BD> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_hashlib.so
 0x14ec000 -  0x14edff7 +_random.so ??? (???) <BCF247FD-CE8B-1290-4A4F-419542E24D4A> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_random.so
 0x1530000 -  0x1531ff7 +_locale.so ??? (???) <C642A507-EFA8-4FB6-133A-4DF30A04C569> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_locale.so
 0x1534000 -  0x1542ff7 +cPickle.so ??? (???) <F739315F-6A1E-86E9-88EC-CEFCCA285AE6> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/cPickle.so
0x8fe00000 - 0x8fe4163b  dyld 132.1 (???) <4CDE4F04-0DD6-224E-ACE5-3C06E169A801> /usr/lib/dyld
0x90003000 - 0x90419ff7  libBLAS.dylib 219.0.0 (compatibility 1.0.0) <C4FB303A-DB4D-F9E8-181C-129585E59603> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
0x9042b000 - 0x904d3ffb  com.apple.QD 3.36 (???) <FA2785A4-BB69-DCB4-3BA3-7C89A82CAB41> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
0x904d4000 - 0x90516ff7  libvDSP.dylib 268.0.1 (compatibility 1.0.0) <8A4721DE-25C4-C8AA-EA90-9DA7812E3EBA> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
0x9051c000 - 0x90531fff  com.apple.ImageCapture 6.1 (6.1) <B909459A-EAC9-A7C8-F2A9-CD757CDB59E8> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
0x90532000 - 0x90532ff7  com.apple.CoreServices 44 (44) <51CFA89A-33DB-90ED-26A8-67D461718A4A> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x90533000 - 0x90557ff7  libJPEG.dylib ??? (???) <50E17B4D-63D6-24D3-702F-6A6E912A55EA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
0x90559000 - 0x905d4fff  com.apple.AppleVAFramework 4.10.27 (4.10.27) <BFD2D1CA-535C-F16F-0EB5-04905ABD65CF> /System/Library/PrivateFrameworks/AppleVA.framework/Versions/A/AppleVA
0x905d5000 - 0x90655feb  com.apple.SearchKit 1.3.0 (1.3.0) <9E18AEA5-F4B4-8BE5-EEA9-818FC4F46FD9> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
0x9065c000 - 0x9065fffb  com.apple.help 1.3.2 (41.1) <8AC20B01-4A3B-94BA-D8AF-E39034B97D8C> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
0x90660000 - 0x9069eff7  com.apple.QuickLookFramework 2.3 (327.7) <6387A103-C7EF-D56B-10EF-5ED5FC7F33A5> /System/Library/Frameworks/QuickLook.framework/Versions/A/QuickLook
0x90711000 - 0x90742ff7  libGLImage.dylib ??? (???) <D18E2E76-DBF4-6930-039A-F66CA0D120B3> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
0x90743000 - 0x9077ffe7  libssl.0.9.8.dylib 0.9.8 (compatibility 0.9.8) <CEE95B62-8F1C-2013-6ED3-42EB8A1018DF> /usr/lib/libssl.0.9.8.dylib
0x90780000 - 0x90882fef  com.apple.MeshKitIO 1.1 (49.2) <D0401AC5-1F92-2BBB-EBAB-58EDD3BA61B9> /System/Library/PrivateFrameworks/MeshKit.framework/Versions/A/Frameworks/MeshKitIO.framework/Versions/A/MeshKitIO
0x90883000 - 0x908c9ff7  libauto.dylib ??? (???) <29422A70-87CF-10E2-CE59-FEE1234CFAAE> /usr/lib/libauto.dylib
0x908d6000 - 0x90945ff7  libvMisc.dylib 268.0.1 (compatibility 1.0.0) <595A5539-9F54-63E6-7AAC-C04E1574B050> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
0x90948000 - 0x90954ff7  libkxld.dylib ??? (???) <9A441C48-2D18-E716-5F38-CBEAE6A0BB3E> /usr/lib/system/libkxld.dylib
0x90b5d000 - 0x90b61ff7  IOSurface ??? (???) <89D859B7-A26A-A5AB-8401-FC1E01AC7A60> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
0x90b62000 - 0x90e0ffff  com.apple.JavaScriptCore 6534.59 (6534.59.11) <7F623AA5-A11B-4C26-D2FD-EB5B9DE73F85> /System/Library/Frameworks/JavaScriptCore.framework/Versions/A/JavaScriptCore
0x90e10000 - 0x90eccfff  com.apple.ColorSync 4.6.8 (4.6.8) <920DD017-8B41-7334-E554-A85DB99EBD5A> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
0x90ecd000 - 0x90ed8ff7  libCSync.A.dylib 545.0.0 (compatibility 64.0.0) <287DECA3-7821-32B6-724D-AE03A9A350F9> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
0x90ed9000 - 0x90ed9ff7  com.apple.Accelerate 1.6 (Accelerate 1.6) <3891A689-4F38-FACD-38B2-4BF937DE30CF> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
0x90eda000 - 0x90ef8fe7  libPng.dylib ??? (???) <6C0B95D7-9634-E044-0B79-F1DD56961C33> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
0x90ef9000 - 0x90fb1feb  libFontParser.dylib ??? (???) <D2D0C922-5ED1-3AE9-6F99-707C74DF3E62> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
0x9118f000 - 0x91192ff7  libCoreVMClient.dylib ??? (???) <37F56237-4ABA-E5B5-968D-70FFE357E8E0> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
0x912f6000 - 0x91391fe7  com.apple.ApplicationServices.ATS 275.19 (???) <2E83B3E9-AF39-36FC-5D05-CC1E952098AB> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
0x91392000 - 0x91395ff7  libCGXType.A.dylib 545.0.0 (compatibility 64.0.0) <4D766435-EB76-C384-0127-1D20ACD74076> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXType.A.dylib
0x91396000 - 0x91396ff7  com.apple.vecLib 3.6 (vecLib 3.6) <FF4DC8B6-0AB0-DEE8-ADA8-7B57645A1F36> /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
0x913a4000 - 0x913a5ff7  com.apple.audio.units.AudioUnit 1.6.7 (1.6.7) <93EC71F1-4D4E-F456-8EFE-32E7EFD7A064> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0x913e0000 - 0x913e6fe7  com.apple.CommerceCore 1.0 (9.1) <521D067B-3BDA-D04E-E1FA-CFA526C87EB5> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore
0x913e7000 - 0x91515fe7  com.apple.CoreData 102.1 (251) <87FE6861-F2D6-773D-ED45-345272E56463> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
0x91516000 - 0x91521ff7  libGL.dylib ??? (???) <3E34468F-E9A7-8EFB-FF66-5204BD5B4E21> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
0x9153b000 - 0x915b5fff  com.apple.audio.CoreAudio 3.2.6 (3.2.6) <156A532C-0B60-55B0-EE27-D02B82AA6217> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
0x915b6000 - 0x91606ff7  com.apple.framework.familycontrols 2.0.2 (2020) <596ADD85-79F5-A613-537B-F83B6E19013C> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
0x91607000 - 0x9165dff7  com.apple.MeshKitRuntime 1.1 (49.2) <CB9F38B1-E107-EA62-EDFF-02EE79F6D1A5> /System/Library/PrivateFrameworks/MeshKit.framework/Versions/A/Frameworks/MeshKitRuntime.framework/Versions/A/MeshKitRuntime
0x9165e000 - 0x918c4ff7  com.apple.security 6.1.2 (55002) <E88E133F-5FB3-446F-B753-2B8AD577B46A> /System/Library/Frameworks/Security.framework/Versions/A/Security
0x9191c000 - 0x91942ffb  com.apple.DictionaryServices 1.1.2 (1.1.2) <43E1D565-6E01-3681-F2E5-72AE4C3A097A> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
0x91943000 - 0x91aeaff7  libSystem.B.dylib 125.2.11 (compatibility 1.0.0) <2DCD13E3-1BD1-6F25-119A-3863A3848B90> /usr/lib/libSystem.B.dylib
0x91aeb000 - 0x91b1efff  libTrueTypeScaler.dylib ??? (???) <8ADB7D19-413E-4499-C874-13C383F97685> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libTrueTypeScaler.dylib
0x91b1f000 - 0x91b24ff7  com.apple.OpenDirectory 10.6 (10.6) <0603680A-A002-D294-DE83-0D028C6BE884> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
0x91b25000 - 0x91b78ff7  com.apple.HIServices 1.8.3 (???) <1D3C4587-6318-C339-BD0F-1988F246BE2E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
0x91b79000 - 0x91b91ff7  com.apple.CFOpenDirectory 10.6 (10.6) <D1CF5881-0AF7-D164-4156-9E9067B7FA37> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
0x91b92000 - 0x91c3ffe7  libobjc.A.dylib 227.0.0 (compatibility 1.0.0) <9F8413A6-736D-37D9-8EB3-7986D4699957> /usr/lib/libobjc.A.dylib
0x91cf7000 - 0x91d13fe3  com.apple.openscripting 1.3.1 (???) <2A748037-D1C0-6D47-2C4A-0562AF799AC9> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
0x91d14000 - 0x91db1fe3  com.apple.LaunchServices 362.3 (362.3) <15B47388-16C8-97DA-EEBB-1709E136169E> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
0x91db2000 - 0x91e7dfef  com.apple.CoreServices.OSServices 359.2 (359.2) <7C16D9C8-6F41-5754-17F7-2659D9DD9579> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
0x91ef6000 - 0x91efaff7  libGIF.dylib ??? (???) <2251F789-B187-0837-6E38-A0E5C7C4FA3C> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
0x91f45000 - 0x91f55ff7  libsasl2.2.dylib 3.15.0 (compatibility 3.0.0) <C8744EA3-0AB7-CD03-E639-C4F2B910BE5D> /usr/lib/libsasl2.2.dylib
0x91f7a000 - 0x91f8bff7  com.apple.LangAnalysis 1.6.6 (1.6.6) <3036AD83-4F1D-1028-54EE-54165E562650> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
0x91f8c000 - 0x92009ff7  com.apple.iLifeMediaBrowser 2.5.5 (468.2.2) <459C8983-EAC4-7067-3355-5299D111D339> /System/Library/PrivateFrameworks/iLifeMediaBrowser.framework/Versions/A/iLifeMediaBrowser
0x9200a000 - 0x9202afe7  libresolv.9.dylib 41.1.0 (compatibility 1.0.0) <8C2B5FA8-2469-21C7-D297-F95A0FFE5F19> /usr/lib/libresolv.9.dylib
0x9202b000 - 0x92061fff  libtidy.A.dylib ??? (???) <0FD72C68-4803-4C5B-3A63-05D7394BFD71> /usr/lib/libtidy.A.dylib
0x92103000 - 0x92117fe7  libbsm.0.dylib ??? (???) <14CB053A-7C47-96DA-E415-0906BA1B78C9> /usr/lib/libbsm.0.dylib
0x92118000 - 0x92218fe7  libxml2.2.dylib 10.3.0 (compatibility 10.0.0) <BE7FCD73-03B5-25A4-FCA4-D4980F1488D6> /usr/lib/libxml2.2.dylib
0x92238000 - 0x92259fe7  com.apple.opencl 12.3.6 (12.3.6) <B4104B80-1CB3-191C-AFD3-697843C6BCFF> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
0x9225d000 - 0x922a1ff3  com.apple.coreui 2 (114) <2234855E-3BED-717F-0BFA-D1A289ECDBDA> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
0x922a2000 - 0x922a4ff7  com.apple.securityhi 4.0 (36638) <6118C361-61E7-B34E-93DB-1B88108F8F18> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
0x922a5000 - 0x92337fe7  com.apple.print.framework.PrintCore 6.3 (312.7) <7410D1B2-655D-68DA-D4B9-2C65747B6817> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
0x92338000 - 0x927f3ff7  com.apple.VideoToolbox 0.484.60 (484.60) <B53299EC-E30F-EC04-779D-29B7113CC14A> /System/Library/PrivateFrameworks/VideoToolbox.framework/Versions/A/VideoToolbox
0x92827000 - 0x92868ff7  libRIP.A.dylib 545.0.0 (compatibility 64.0.0) <80998F66-0AD7-AD12-B9AF-3E8D2CE6DE05> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
0x92869000 - 0x92872ff7  com.apple.DiskArbitration 2.3 (2.3) <E9C40767-DA6A-6CCB-8B00-2D5706753000> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x93061000 - 0x931a4fef  com.apple.QTKit 7.7 (1800) <9DD27495-3020-0928-B3F2-D418C336E163> /System/Library/Frameworks/QTKit.framework/Versions/A/QTKit
0x931a5000 - 0x931b7ff7  com.apple.MultitouchSupport.framework 207.11 (207.11) <6FF4F2D6-B8CD-AE13-56CB-17437EE5B741> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
0x931b8000 - 0x931b8ff7  com.apple.Accelerate.vecLib 3.6 (vecLib 3.6) <ABF97DA4-3BDF-6FFD-6239-B023CA1F7974> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
0x931b9000 - 0x931c3fe7  com.apple.audio.SoundManager 3.9.3 (3.9.3) <5F494955-7290-2D91-DA94-44B590191771> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound
0x931c4000 - 0x931ffffb  libFontRegistry.dylib ??? (???) <19ED5DE0-D3AF-B229-9193-35D58FE377E5> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
0x93200000 - 0x9320eff7  com.apple.opengl 1.6.14 (1.6.14) <82622F67-E032-0BF6-A78D-50B346E8D0FD> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
0x93517000 - 0x9351bff7  libGFXShared.dylib ??? (???) <09540618-2ED1-72C4-61CB-938B35927568> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
0x9351c000 - 0x93526ff7  com.apple.HelpData 2.0.5 (34.1.1) <A9CF754F-B254-5D40-B8B5-F35414DFD875> /System/Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData
0x93527000 - 0x93531ffb  com.apple.speech.recognition.framework 3.11.1 (3.11.1) <7486003F-8FDB-BD6C-CB34-DE45315BD82C> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
0x93532000 - 0x9375dff3  com.apple.QuartzComposer 4.2 ({156.30}) <2C88F8C3-7181-6B1D-B278-E0EE3F33A2AF> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuartzComposer.framework/Versions/A/QuartzComposer
0x937ac000 - 0x9396ffeb  com.apple.ImageIO.framework 3.0.6 (3.0.6) <AE641FAD-DF38-AE31-B45B-85AEE7AF3A45> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
0x93970000 - 0x93b52fff  com.apple.imageKit 2.0.3 (1.0) <6E557757-26F7-7941-8AE7-046EC1871F50> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/ImageKit.framework/Versions/A/ImageKit
0x93b53000 - 0x93b7bff7  libxslt.1.dylib 3.24.0 (compatibility 3.0.0) <E761F29A-328B-29D9-3DF0-023F2C21E500> /usr/lib/libxslt.1.dylib
0x93b7c000 - 0x93bfeffb  SecurityFoundation ??? (???) <C4506287-1AE2-5380-675D-95B0291AA425> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
0x93cfe000 - 0x94133ff7  libLAPACK.dylib 219.0.0 (compatibility 1.0.0) <5E2D2283-57DE-9A49-1DB0-CD027FEFA6C2> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
0x94134000 - 0x94181feb  com.apple.DirectoryService.PasswordServerFramework 6.1 (6.1) <00A1A83B-0E7D-D0F4-A643-8C5675C2BB21> /System/Library/PrivateFrameworks/PasswordServer.framework/Versions/A/PasswordServer
0x94182000 - 0x9423bfe7  libsqlite3.dylib 9.6.0 (compatibility 9.0.0) <52438E77-55D1-C231-1936-76F1369518E4> /usr/lib/libsqlite3.dylib
0x94284000 - 0x944f5fef  com.apple.Foundation 6.6.8 (751.63) <69B3441C-B196-F2AD-07F8-D8DD24E4CD8C> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x946d0000 - 0x946e0ff7  com.apple.DSObjCWrappers.Framework 10.6 (134) <81A0B409-3906-A98F-CA9B-A49E75007495> /System/Library/PrivateFrameworks/DSObjCWrappers.framework/Versions/A/DSObjCWrappers
0x947ae000 - 0x947afff7  com.apple.MonitorPanelFramework 1.3.0 (1.3.0) <0EC4EEFF-477E-908E-6F21-ED2C973846A4> /System/Library/PrivateFrameworks/MonitorPanel.framework/Versions/A/MonitorPanel
0x947b0000 - 0x9488afff  com.apple.DesktopServices 1.5.11 (1.5.11) <800F2040-9211-81A7-B438-7712BF51DEE3> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
0x9488b000 - 0x948e8ff7  com.apple.framework.IOKit 2.0 (???) <3DABAB9C-4949-F441-B077-0498F8E47A35> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x948e9000 - 0x948f0ff3  com.apple.print.framework.Print 6.1 (237.1) <F5AAE53D-5530-9004-A9E3-2C1690C5328E> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
0x94943000 - 0x94ac5fe7  libicucore.A.dylib 40.0.0 (compatibility 1.0.0) <60FF302E-5FAE-749B-BC70-0496DC2FBF2D> /usr/lib/libicucore.A.dylib
0x94af2000 - 0x952e1557  com.apple.CoreGraphics 1.545.0 (???) <1D9DC7A5-228B-42CB-7018-66F42C3A9BB3> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
0x9534e000 - 0x953a6fe7  com.apple.datadetectorscore 2.0 (80.7) <A40AA74A-9D13-2A6C-5440-B50905923251> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
0x95462000 - 0x95d45ff7  com.apple.AppKit 6.6.8 (1038.36) <A353465E-CFC9-CB75-949D-786F6F7732F6> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x95d46000 - 0x95d76ff7  com.apple.MeshKit 1.1 (49.2) <5A74D1A4-4B97-FE39-4F4D-E0B80F0ADD87> /System/Library/PrivateFrameworks/MeshKit.framework/Versions/A/MeshKit
0x95d77000 - 0x95d77ff7  liblangid.dylib ??? (???) <B99607FC-5646-32C8-2C16-AFB5EA9097C2> /usr/lib/liblangid.dylib
0x95db1000 - 0x95dd8ff7  com.apple.quartzfilters 1.6.0 (1.6.0) <879A3B93-87A6-88FE-305D-DF1EAED04756> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuartzFilters.framework/Versions/A/QuartzFilters
0x95dd9000 - 0x95ddffff  com.apple.CommonPanels 1.2.4 (91) <2438AF5D-067B-B9FD-1248-2C9987F360BA> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
0x95de0000 - 0x95e4afe7  libstdc++.6.dylib 7.9.0 (compatibility 7.0.0) <411D87F4-B7E1-44EB-F201-F8B4F9227213> /usr/lib/libstdc++.6.dylib
0x95e4b000 - 0x95e4bff7  com.apple.quartzframework 1.5 (1.5) <CEB78F00-C5B2-3B3F-BF70-DD6D578719C0> /System/Library/Frameworks/Quartz.framework/Versions/A/Quartz
0x95f1e000 - 0x96099fe7  com.apple.CoreFoundation 6.6.6 (550.44) <F88C95CD-1264-782D-A1F5-204739847E93> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x96284000 - 0x965efff7  com.apple.QuartzCore 1.6.3 (227.37) <E323A5CC-499E-CA9E-9BC3-537231449CAA> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
0x96726000 - 0x96726ff7  com.apple.Carbon 150 (152) <8F767518-AD3C-5CA0-7613-674CD2B509C4> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
0x96727000 - 0x96864fe7  com.apple.audio.toolbox.AudioToolbox 1.6.7 (1.6.7) <423BDE4D-5082-B6CA-BB2C-E22A037235A4> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
0x96865000 - 0x968a2ff7  com.apple.SystemConfiguration 1.10.8 (1.10.2) <50E4D49B-4F61-446F-1C21-1B2BA814713D> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
0x9694d000 - 0x969f9fe7  com.apple.CFNetwork 454.12.4 (454.12.4) <DEDCD006-389F-967F-3405-EDF541F406D7> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
0x9706d000 - 0x9708ffef  com.apple.DirectoryService.Framework 3.6 (621.16) <5566E769-6459-78A7-DD2C-1D3068BD3932> /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService
0x970d6000 - 0x973d0fef  com.apple.QuickTime 7.6.6 (1800) <D3538A45-5F4B-262A-06AB-64C1EBAC4A33> /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime
0x97573000 - 0x9757bff7  com.apple.DisplayServicesFW 2.3.3 (289) <828084B0-9197-14DD-F66A-D634250A212E> /System/Library/PrivateFrameworks/DisplayServices.framework/Versions/A/DisplayServices
0x9758f000 - 0x975dffe7  libTIFF.dylib ??? (???) <AB182CEC-188A-F2BC-21E1-0059FD3B2598> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
0x975e0000 - 0x97a31fef  com.apple.RawCamera.bundle 3.7.1 (570) <AF94D180-5E0F-10DF-0CB2-FD8EDB110FA2> /System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera
0x97a37000 - 0x97a7cff7  com.apple.ImageCaptureCore 1.1 (1.1) <F54F284F-0B81-0AFA-CE47-FF797A6E05B0> /System/Library/Frameworks/ImageCaptureCore.framework/Versions/A/ImageCaptureCore
0x97a9f000 - 0x97dbfff3  com.apple.CoreServices.CarbonCore 861.39 (861.39) <5C59805C-AF39-9010-B8B5-D673C9C38538> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x97dc0000 - 0x97dc2ff7  libRadiance.dylib ??? (???) <090420B3-CB65-9F7B-5349-D42F2F9693B6> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
0x97dc3000 - 0x97e07fe7  com.apple.Metadata 10.6.3 (507.15) <74F05E64-2A68-BA10-CCD4-128D164E5A0F> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
0x97e10000 - 0x97e89ff7  com.apple.PDFKit 2.5.5 (2.5.5) <85AA9E1C-D946-863A-823E-32F2AAF314CB> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/PDFKit.framework/Versions/A/PDFKit
0x97e8a000 - 0x97e90ff7  libCGXCoreImage.A.dylib 545.0.0 (compatibility 64.0.0) <6EE825E7-CBA5-2AD2-0336-244D45A1A834> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGXCoreImage.A.dylib
0x97ebd000 - 0x97edcff7  com.apple.CoreVideo 1.6.2 (45.6) <EB53CAA4-5EE2-C356-A954-5775F7DDD493> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
0x98c8f000 - 0x98cc9ff7  libcups.2.dylib 2.8.0 (compatibility 2.0.0) <A6C207E3-7B42-926D-9C93-BE3F50B92496> /usr/lib/libcups.2.dylib
0x98cca000 - 0x98dd6fe7  libGLProgrammability.dylib ??? (???) <6167CEB0-D8D6-C4D9-DD74-49755ADB540F> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib
0x98dd7000 - 0x98dd8ff7  com.apple.TrustEvaluationAgent 1.1 (1) <2D970A9B-77E8-EDC0-BEC6-7580D78B2843> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
0x98dd9000 - 0x98e16ff7  com.apple.CoreMedia 0.484.60 (484.60) <8FAB137D-682C-6DEC-5A15-F0029A5B226F> /System/Library/PrivateFrameworks/CoreMedia.framework/Versions/A/CoreMedia
0x98e17000 - 0x98e5effb  com.apple.CoreMediaIOServices 140.0 (1496) <DA152F1C-8EF4-4F5E-6D60-82B1DC72EF47> /System/Library/PrivateFrameworks/CoreMediaIOServices.framework/Versions/A/CoreMediaIOServices
0x98e5f000 - 0x98e6dfe7  libz.1.dylib 1.2.3 (compatibility 1.0.0) <33C1B260-ED05-945D-FC33-EF56EC791E2E> /usr/lib/libz.1.dylib
0x98e6e000 - 0x98e98ff7  com.apple.shortcut 1.1 (1.1) <B0514FA9-7CAE-AD94-93CA-7B2A2C5F7B8A> /System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Shortcut
0x98e99000 - 0x98f9bfe7  libcrypto.0.9.8.dylib 0.9.8 (compatibility 0.9.8) <EB34F049-D9E1-BF19-CF03-B26A0352D40C> /usr/lib/libcrypto.0.9.8.dylib
0x98fc6000 - 0x99027fe7  com.apple.CoreText 151.13 (???) <23F359DA-D845-5C50-4DF3-19E858CF2B2C> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText
0x99071000 - 0x990dfff7  com.apple.QuickLookUIFramework 2.3 (327.7) <7F89C0A1-310F-ACF1-AA6E-4ADFA4DC98DC> /System/Library/Frameworks/Quartz.framework/Versions/A/Frameworks/QuickLookUI.framework/Versions/A/QuickLookUI
0x990e0000 - 0x990e3fe7  libmathCommon.A.dylib 315.0.0 (compatibility 1.0.0) <1622A54F-1A98-2CBE-B6A4-2122981A500E> /usr/lib/system/libmathCommon.A.dylib
0x990e4000 - 0x9917cfe7  edu.mit.Kerberos 6.5.11 (6.5.11) <F36DB665-A88B-7F5B-6244-6A2E7FFFF668> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
0x991ec000 - 0x99250ffb  com.apple.htmlrendering 72 (1.1.4) <4D451A35-FAB6-1288-71F6-F24A4B6E2371> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering
0x992c1000 - 0x9936fff3  com.apple.ink.framework 1.3.3 (107) <233A981E-A2F9-56FB-8BDE-C2DEC3F20784> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
0x993ca000 - 0x993fdff7  com.apple.AE 496.5 (496.5) <BF9673D5-2419-7120-26A3-83D264C75222> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x993fe000 - 0x9940bff7  com.apple.NetFS 3.2.2 (3.2.2) <DDC9C397-C35F-8D7A-BB24-3D1B42FA5FAB> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
0x9942a000 - 0x99557ffb  com.apple.MediaToolbox 0.484.60 (484.60) <A7FE2739-64A7-40EB-A6E7-69FBCE3C87D4> /System/Library/PrivateFrameworks/MediaToolbox.framework/Versions/A/MediaToolbox
0x9a5ec000 - 0x9a6ccfe7  com.apple.vImage 4.1 (4.1) <D029C515-08E1-93A6-3705-DD062A3A672C> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
0x9a6cd000 - 0x9a6cdff7  com.apple.ApplicationServices 38 (38) <8012B504-3D83-BFBB-DA65-065E061CFE03> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
0x9a6ce000 - 0x9a9f2fef  com.apple.HIToolbox 1.6.5 (???) <21164164-41CE-61DE-C567-32E89755CB34> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
0x9a9f3000 - 0x9aa36ff7  com.apple.NavigationServices 3.5.4 (182) <8DC6FD4A-6C74-9C23-A4C3-715B44A8D28C> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices
0x9aa37000 - 0x9aa7aff7  libGLU.dylib ??? (???) <6CC3CE6A-7024-C685-EADA-7F9DC27128E2> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
0x9aa7b000 - 0x9aa8fffb  com.apple.speech.synthesis.framework 3.10.35 (3.10.35) <57DD5458-4F24-DA7D-0927-C3321A65D743> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
0x9aa90000 - 0x9aaeafe7  com.apple.CorePDF 1.4 (1.4) <78A1DDE1-1609-223C-A532-D282DC5E0CD0> /System/Library/PrivateFrameworks/CorePDF.framework/Versions/A/CorePDF
0x9ac02000 - 0x9ac02ff7  com.apple.Cocoa 6.6 (???) <EA27B428-5904-B00B-397A-185588698BCC> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
0xffff0000 - 0xffff1fff  libSystem.B.dylib ??? (???) <2DCD13E3-1BD1-6F25-119A-3863A3848B90> /usr/lib/libSystem.B.dylib

Model: MacBookPro1,1, BootROM MBP11.0055.B08, 2 processors, Intel Core Duo, 2 GHz, 1 GB, SMC 1.2f10
Graphics: ATI Radeon X1600, ATY,RadeonX1600, PCIe, 256 MB
Memory Module: global_name
AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x86), Atheros 5424: 2.1.14.6
Bluetooth: Version 2.4.5f3, 2 service, 19 devices, 1 incoming serial ports
Network Service: AirPort, AirPort, en1
Network Service: Bluetooth, PPP (PPPSerial), Bluetooth-Modem
Serial ATA Device: ST910021AS, 93.16 GB
Parallel ATA Device: MATSHITADVD-R   UJ-857
USB Device: Built-in iSight, 0x05ac  (Apple Inc.), 0x8501, 0xfd400000 / 2
USB Device: Apple Internal Keyboard / Trackpad, 0x05ac  (Apple Inc.), 0x0217, 0x1d200000 / 2
USB Device: IR Receiver, 0x05ac  (Apple Inc.), 0x8240, 0x5d200000 / 2
USB Device: Bluetooth USB Host Controller, 0x05ac  (Apple Inc.), 0x8205, 0x7d100000 / 2

----------
components: IDLE
messages: 203657
nosy: adamswg
priority: normal
severity: normal
status: open
title: OS X 10.6.8 Crash when opening a file
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 22 00:46:46 2013
From: report at bugs.python.org (=?utf-8?b?TGx1w61z?=)
Date: Thu, 21 Nov 2013 23:46:46 +0000
Subject: [New-bugs-announce] [issue19686] possible unnecessary memoryview
	copies?
Message-ID: <1385077606.25.0.863226598696.issue19686@psf.upfronthosting.co.za>


New submission from Llu?s:

The following code works without raising any AssertionError
 >>> n = "some small integer value"
 >>> m = "some larger integer value"
 >>> assert n<m
 >>> data = bytearray(n)
 >>> mem = memoryview(data)
 >>> assert mem==mem[:]
 >>> assert mem==mem[0:]
 >>> assert mem==mem[:m]

However, the different slices have different IDs, failing on the following asserts:
 >>> assert id(mem)==id(mem[:])
 >>> assert id(mem)==id(mem[0:])
 >>> assert id(mem)==id(mem[:m])

Is the interpreter copying unnecessary data in these type of slices?

----------
components: Library (Lib)
messages: 203700
nosy: Llu?s
priority: normal
severity: normal
status: open
title: possible unnecessary memoryview copies?
type: enhancement

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

From report at bugs.python.org  Fri Nov 22 01:03:31 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Nov 2013 00:03:31 +0000
Subject: [New-bugs-announce] [issue19687] Fixes for elementtree integer
	overflow
Message-ID: <1385078611.06.0.503563950207.issue19687@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch addresses most overflow errors in elementtree except for the problems in element_ass_subscr().

----------
components: Library (Lib)
files: elementtree_overflow.patch
keywords: patch
messages: 203702
nosy: christian.heimes, haypo
priority: normal
severity: normal
stage: patch review
status: open
title: Fixes for elementtree integer overflow
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file32767/elementtree_overflow.patch

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

From report at bugs.python.org  Fri Nov 22 03:20:00 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 22 Nov 2013 02:20:00 +0000
Subject: [New-bugs-announce] [issue19688] pip install now fails with
	'HTMLParser' object has no	attribute 'unescape'
Message-ID: <1385086800.23.0.730007142289.issue19688@psf.upfronthosting.co.za>


New submission from Ned Deily:

7b9235852b3b for Issue2927 moved and documents the previously undocumented unescape function.  Unfortunately, at least one third-party module, distlib, depends on it.  And distlib is now used by pip and needed for the ensurepip feature of 3.4.

$ python3.4 get-pip.py
Traceback (most recent call last):
  File "get-pip.py", line 7269, in <module>
    do_exec(entry, locals())
  File "<string>", line 1, in do_exec
  File "<string>", line 9, in <module>
  File "/var/folders/fm/9wjgctqx61n796zt88qmmnxc0000gn/T/unpacker-1kz7n2dh-scratchdir/pip/__init__.py", line 10, in <module>
  File "/var/folders/fm/9wjgctqx61n796zt88qmmnxc0000gn/T/unpacker-1kz7n2dh-scratchdir/pip/util.py", line 17, in <module>
  File "/var/folders/fm/9wjgctqx61n796zt88qmmnxc0000gn/T/unpacker-1kz7n2dh-scratchdir/pip/vendor/distlib/version.py", line 13, in <module>
  File "/var/folders/fm/9wjgctqx61n796zt88qmmnxc0000gn/T/unpacker-1kz7n2dh-scratchdir/pip/vendor/distlib/compat.py", line 343, in <module>
AttributeError: 'HTMLParser' object has no attribute 'unescape'

----------
assignee: ezio.melotti
components: Library (Lib)
messages: 203712
nosy: ezio.melotti, larry, ned.deily
priority: release blocker
severity: normal
status: open
title: pip install now fails with 'HTMLParser' object has no attribute 'unescape'
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 04:22:24 2013
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Nov 2013 03:22:24 +0000
Subject: [New-bugs-announce] [issue19689] ssl.create_default_context()
Message-ID: <1385090544.45.0.828501319408.issue19689@psf.upfronthosting.co.za>


New submission from Christian Heimes:

A few weeks ago I suggested the addition of ssl.create_default_context() to the stdlib. The patch implements my proposal. It replaces code in several of modules with one central function. The patch also removes ssl.wrap_socket() in favor for a SSLContext object.

As soon as #19292 gets accepted I'll add the additional keyword argument "purpose=None" to the arguments of ssl.create_default_context() in order to load the default system certs::
    
    if purpose is not None and verify_mode != CERT_NONE:
        context.load_default_certs(purpose)

----------
components: Library (Lib)
files: ssl_create_default_context.patch
keywords: patch
messages: 203718
nosy: christian.heimes, giampaolo.rodola, gvanrossum, janssen, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: ssl.create_default_context()
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32770/ssl_create_default_context.patch

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

From report at bugs.python.org  Fri Nov 22 08:31:15 2013
From: report at bugs.python.org (Ned Deily)
Date: Fri, 22 Nov 2013 07:31:15 +0000
Subject: [New-bugs-announce] [issue19690] test_logging test_race failed with
	PermissionError
Message-ID: <1385105475.94.0.253645069216.issue19690@psf.upfronthosting.co.za>


New submission from Ned Deily:

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

======================================================================
ERROR: test_race (test.test_logging.HandlerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_logging.py", line 613, in test_race
    h.handle(r)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/logging/__init__.py", line 835, in handle
    self.emit(record)
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/logging/handlers.py", line 468, in emit
    self.stream = self._open()
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/logging/__init__.py", line 1005, in _open
    return open(self.baseFilename, self.mode, encoding=self.encoding)
PermissionError: [Errno 1] Operation not permitted: '/tmp/test_logging-3-i5haxx_n.log'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_logging.py", line 616, in test_race
    h.close()
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/logging/__init__.py", line 990, in close
    self.flush()
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/logging/__init__.py", line 937, in flush
    self.stream.flush()
ValueError: I/O operation on closed file.

The test passed when rerun by regrtest.  This looks similar to the failures in Issue14632.

----------
components: Tests
messages: 203727
nosy: ned.deily, vinay.sajip
priority: normal
severity: normal
status: open
title: test_logging test_race failed with PermissionError
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov 21 22:21:02 2013
From: report at bugs.python.org (Curtis Doty)
Date: Thu, 21 Nov 2013 21:21:02 +0000
Subject: [New-bugs-announce] [issue19685] open() fails to autodetect utf-8
	if LANG=C
Message-ID: <1385068862.86.0.511890547507.issue19685@psf.upfronthosting.co.za>


New submission from Curtis Doty:

I first stumbled across this bug attempting to install use pip's cool editable mode:

$ pip install -e git+git://github.com/appliedsec/pygeoip.git#egg=pygeoip
Obtaining pygeoip from git+git://github.com/appliedsec/pygeoip.git#egg=pygeoip
  Cloning git://github.com/appliedsec/pygeoip.git to ./src/pygeoip
  Running setup.py egg_info for package pygeoip
    Traceback (most recent call last):
      File "<string>", line 16, in <module>
      File "/home/curtis/python/3.3.3/lib/python3.3/encodings/ascii.py", line 26, in decode
        return codecs.ascii_decode(input, self.errors)[0]
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1098: ordinal not in range(128)
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):

  File "<string>", line 16, in <module>

  File "/home/curtis/python/3.3.3/lib/python3.3/encodings/ascii.py", line 26, in decode

    return codecs.ascii_decode(input, self.errors)[0]

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1098: ordinal not in range(128)

----------------------------------------
Cleaning up...
Command python setup.py egg_info failed with error code 1 in /home/curtis/python/2013-11-20/src/pygeoip
Storing complete log in /home/curtis/.pip/pip.log


It turns out this is related to a local LANG=C environment. If I set LANG=en_US.UTF-8, the problem goes away. But it seems pip/python3 open() should be more intelligently handling this.

Worse, the file in this case https://github.com/appliedsec/pygeoip/blob/master/setup.py already has a source code decorator *declaring* it as utf-8.

Ugly workaround patch is to force pip to always use 8-bit encoding on setup.py:

--- pip.orig/req.py	2013-11-19 15:53:49.000000000 -0800
+++ pip/req.py	2013-11-20 16:37:23.642656132 -0800
@@ -281,7 +281,7 @@ def replacement_run(self):
             writer(self, ep.name, os.path.join(self.egg_info,ep.name))
     self.find_sources()
 egg_info.egg_info.run = replacement_run
-exec(compile(open(__file__).read().replace('\\r\\n', '\\n'), __file__, 'exec'))
+exec(compile(open(__file__,encoding='utf_8').read().replace('\\r\\n', '\\n'), __file__, 'exec'))
 """
 
     def egg_info_data(self, filename):
@@ -687,7 +687,7 @@ exec(compile(open(__file__).read().repla
             ## FIXME: should we do --install-headers here too?
             call_subprocess(
                 [sys.executable, '-c',
-                 "import setuptools; __file__=%r; exec(compile(open(__file__).read().replace('\\r\\n', '\\n'), __file__, 'exec'))" % self.setup_py]
+                 "import setuptools; __file__=%r; exec(compile(open(__file__,encoding='utf_8').read().replace('\\r\\n', '\\n'), __file__, 'exec'))" % self.setup_py]
                 + list(global_options) + ['develop', '--no-deps'] + list(install_options),
 
                 cwd=self.source_dir, filter_stdout=self._filter_install,


But that only treats the symptom. Root cause appears to be in python3 as demonstrated by this simple script:

wrong-codec.py:
#! /bin/env python3
from urllib.request import urlretrieve
urlretrieve('https://raw.github.com/appliedsec/pygeoip/master/setup.py', filename='setup.py')

# if LANC=C then locale.py:getpreferredencoding()->'ANSI_X3.4-1968'
foo= open('setup.py')

# bang! ascii_decode() cannot handle the unicode
bar= foo.read()


This does not occur in python2. Is this bug in pip or python3?

----------
components: Unicode
messages: 203673
nosy: GreenKey, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: open() fails to autodetect utf-8 if LANG=C
type: crash
versions: Python 3.3

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

From report at bugs.python.org  Fri Nov 22 15:21:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Nov 2013 14:21:48 +0000
Subject: [New-bugs-announce] [issue19691] Weird wording in RuntimeError doc
Message-ID: <1385130108.97.0.877442110994.issue19691@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The RuntimeError documentation has a strange sentence embedded in it:

"""This exception is mostly a relic from a previous version of the interpreter; it is not used very much any more"""

http://docs.python.org/dev/library/exceptions.html#RuntimeError

That's quite wrong. RuntimeError may not be raised inside the interpreter core, but it's raised by a bunch of stdlib modules.

----------
assignee: docs at python
components: Documentation
messages: 203763
nosy: docs at python, neologix, pitrou
priority: normal
severity: normal
status: open
title: Weird wording in RuntimeError doc
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov 22 15:24:55 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Nov 2013 14:24:55 +0000
Subject: [New-bugs-announce] [issue19692] Rename Py_SAFE_DOWNCAST
Message-ID: <1385130295.49.0.846468108755.issue19692@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Py_SAFE_DOWNCAST's name is a bit misleading: it isn't safe except in debug mode. I propose to rename it to Py_DOWNCAST, so that developers are reminded that the burden of the sanity checks is on them.

----------
components: Interpreter Core
messages: 203764
nosy: christian.heimes, haypo, pitrou, tim.peters
priority: normal
severity: normal
status: open
title: Rename Py_SAFE_DOWNCAST
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 15:39:14 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 22 Nov 2013 14:39:14 +0000
Subject: [New-bugs-announce] [issue19693] "make altinstall && make install"
	behaviour differs from	"make install"
Message-ID: <1385131154.65.0.84746252058.issue19693@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

>From issue #19553:

8. "make install" is a superset of "make altinstall" and one would expect the results of (a) "make install" to be the same as (b) "make altinstall && make install".  However (b) results in "python -m ensurepip --altinstall --upgrade && python -m ensurepip --upgrade" which results in no unversioned pip files being installed as the second call to pip does nothing:

Requirement already up-to-date: setuptools in /py/dev/3x/root/uxd/lib/python3.4/site-packages
Requirement already up-to-date: pip in /py/dev/3x/root/uxd/lib/python3.4/site-packages

We may need some magic on the pip side when ENSUREPIP_OPTIONS is set to make this behave consistently.

----------
components: Library (Lib)
messages: 203771
nosy: dstufft, larry, ncoghlan, ned.deily
priority: high
severity: normal
stage: needs patch
status: open
title: "make altinstall && make install" behaviour differs from "make install"
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 16:09:41 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 22 Nov 2013 15:09:41 +0000
Subject: [New-bugs-announce] [issue19694] test_venv failing on one of the
	Ubuntu buildbots
Message-ID: <1385132981.26.0.207810200878.issue19694@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

pip still relies on imp (due to cross-version compatibility requirements), so it may trigger a pending deprecation warning, and potentially return a non-zero return code:

http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/3142/steps/test/logs/stdio

----------
components: Library (Lib)
keywords: buildbot
messages: 203778
nosy: larry, ncoghlan
priority: release blocker
severity: normal
stage: needs patch
status: open
title: test_venv failing on one of the Ubuntu buildbots
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 16:17:36 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 15:17:36 +0000
Subject: [New-bugs-announce] [issue19695] Clarify how to use various
	import-related locks
Message-ID: <1385133456.35.0.294583357802.issue19695@psf.upfronthosting.co.za>


New submission from Brett Cannon:

While working on the PEP 451 code I realized that the way we are handling the global import lock along with the per-module lock is a little ad-hoc. For instance, what are we wanting to use the global lock for these days? Mutations of anything off of sys? Reading anything from sys as well? Just to create the module-level locks?

And the per-module lock expects the global lock to be held already, but then does a release implicitly. That seems like the wrong way to structure the context managers; maybe pass in the lock global lock as proof it's being held? Or if we switch to much finer granularity for dealing with sys.modules (especially if it is only for mutation) then we can lock and unlock the global lock entirely within the per-module lock context manager.

At worst I think we should clearly document in the docstrings for the global and per-module context managers what we expect the lock to be used for and then really go through the import code to make sure we are holding it where we want but no more.

To start the conversation, I say the global lock is just to get the per-module locks. The per-module locks are held when finding/loading modules to prevent threading issues of requesting an incomplete module or thinking it isn't being imported when it actually is (which implicitly means holding it when accessing/mutating sys.modules for any module, e.g. trying to fetch a parent module).

----------
components: Interpreter Core
messages: 203783
nosy: brett.cannon, eric.snow, ncoghlan, pitrou
priority: low
severity: normal
stage: needs patch
status: open
title: Clarify how to use various import-related locks
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov 22 17:04:45 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:04:45 +0000
Subject: [New-bugs-announce] [issue19696] Merge all (non-syntactic)
	import-related tests into	test_importlib
Message-ID: <1385136285.91.0.72176568785.issue19696@psf.upfronthosting.co.za>


New submission from Brett Cannon:

E.g. test_namespace_pkgs should be under test_importlib and so should test_namespace_pkgs. test_import can conceivably stay out if it's updated to only contain syntactic tests for the import statement.

This is so that it's easier to run import-related tests when making changes to importlib (otherwise one has to run the whole test suite or memorize the name of every test suite related to import/importlib).

----------
components: Tests
keywords: easy
messages: 203792
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Merge all (non-syntactic) import-related tests into test_importlib
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov 22 17:25:46 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:25:46 +0000
Subject: [New-bugs-announce] [issue19697] refactor pythonrun.c to make use
	of specs	(__main__.__spec__)
Message-ID: <1385137546.91.0.531425476426.issue19697@psf.upfronthosting.co.za>


New submission from Brett Cannon:

So that e.g. __main__.__spec__.name is the actual name of the module being executed.

----------
components: Interpreter Core
messages: 203796
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: refactor pythonrun.c to make use of specs (__main__.__spec__)
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 17:27:55 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:27:55 +0000
Subject: [New-bugs-announce] [issue19698] Implement _imp.exec_builtin and
	exec_dynamic
Message-ID: <1385137675.64.0.235823443194.issue19698@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Since _imp.init_builtin and _imp.load_dynamic don't take in a module to load, need to create new functions which do. Afterwards can deprecate init_builtin, load_dynamic, and init_frozen (the latter having been worked around thanks to get_frozen_object).

----------
components: Interpreter Core
messages: 203798
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Implement _imp.exec_builtin and exec_dynamic
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 17:29:22 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:29:22 +0000
Subject: [New-bugs-announce] [issue19699] Update zipimport for PEP 451
Message-ID: <1385137762.02.0.629134883022.issue19699@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Need to add find_spec and exec_module (or move over to a pure Python zipfile importer).

----------
components: Library (Lib)
messages: 203799
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Update zipimport for PEP 451
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 17:31:23 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:31:23 +0000
Subject: [New-bugs-announce] [issue19700] Update runpy for PEP 451
Message-ID: <1385137883.59.0.0975117328441.issue19700@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
components: Library (Lib)
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Update runpy for PEP 451
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 17:34:03 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:34:03 +0000
Subject: [New-bugs-announce] [issue19701] Update multiprocessing for PEP 451
Message-ID: <1385138043.59.0.905087765846.issue19701@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Specifically Lib/multiprocessing/spawn.py:import_main_path()

----------
components: Library (Lib)
messages: 203802
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Update multiprocessing for PEP 451
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 17:35:18 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:35:18 +0000
Subject: [New-bugs-announce] [issue19702] Update pickle to PEP 451
Message-ID: <1385138118.75.0.812720443886.issue19702@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
components: Library (Lib)
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Update pickle to PEP 451
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 17:37:12 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:37:12 +0000
Subject: [New-bugs-announce] [issue19703] Upate pydoc to PEP 451
Message-ID: <1385138232.11.0.0698925291353.issue19703@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
components: Library (Lib)
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: Upate pydoc to PEP 451
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 17:38:26 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:38:26 +0000
Subject: [New-bugs-announce] [issue19704] Update test.test_threaded_import
	to PEP 451
Message-ID: <1385138306.82.0.45846437054.issue19704@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
components: Tests
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Update test.test_threaded_import to PEP 451
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 17:39:19 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:39:19 +0000
Subject: [New-bugs-announce] [issue19705] Update test.test_namespace_pkgs to
	PEP 451
Message-ID: <1385138359.01.0.8135242067.issue19705@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
components: Tests
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Update test.test_namespace_pkgs to PEP 451
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 17:40:02 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:40:02 +0000
Subject: [New-bugs-announce] [issue19706] Check if inspect needs updating
	for PEP 451
Message-ID: <1385138402.37.0.531890220708.issue19706@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: Check if inspect needs updating for PEP 451
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 17:41:00 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:41:00 +0000
Subject: [New-bugs-announce] [issue19707] Check if unittest.mock needs
	updating for PEP 451
Message-ID: <1385138460.31.0.778271177242.issue19707@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
components: Library (Lib)
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: Check if unittest.mock needs updating for PEP 451
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 17:42:47 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:42:47 +0000
Subject: [New-bugs-announce] [issue19708] Check pkgutil for anything missing
	for PEP 451
Message-ID: <1385138567.45.0.499849261032.issue19708@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
components: Library (Lib)
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: Check pkgutil for anything missing for PEP 451
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 17:43:38 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:43:38 +0000
Subject: [New-bugs-announce] [issue19709] Check pythonrun.c is fully using
	PEP 451
Message-ID: <1385138618.7.0.0888740649809.issue19709@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
components: Interpreter Core
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: Check pythonrun.c is fully using PEP 451
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 17:45:05 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:45:05 +0000
Subject: [New-bugs-announce] [issue19710] Make sure documentation for PEP
	451 is finished
Message-ID: <1385138705.49.0.0614847614933.issue19710@psf.upfronthosting.co.za>


New submission from Brett Cannon:

This includes both importlib.rst and docstrings for various methods.

----------
assignee: docs at python
components: Documentation
messages: 203804
nosy: brett.cannon, docs at python, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Make sure documentation for PEP 451 is finished
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 17:47:07 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:47:07 +0000
Subject: [New-bugs-announce] [issue19711] add test for changed portions
	after reloading a	namespace package
Message-ID: <1385138827.34.0.898717139288.issue19711@psf.upfronthosting.co.za>


New submission from Brett Cannon:

http://bugs.python.org/msg202660

----------
components: Tests
messages: 203805
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: add test for changed portions after reloading a namespace package
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 17:48:18 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:48:18 +0000
Subject: [New-bugs-announce] [issue19712] Make sure there are exec_module
	tests for _LoaderBasics	subclasses
Message-ID: <1385138898.72.0.923604245324.issue19712@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
components: Tests
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Make sure there are exec_module tests for _LoaderBasics subclasses
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 17:50:07 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 16:50:07 +0000
Subject: [New-bugs-announce] [issue19713] Deprecate various things in
	importlib thanks to PEP 451
Message-ID: <1385139007.0.0.922066136531.issue19713@psf.upfronthosting.co.za>


New submission from Brett Cannon:

http://bugs.python.org/msg202659

----------
messages: 203807
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Deprecate various things in importlib thanks to PEP 451
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 18:02:11 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 17:02:11 +0000
Subject: [New-bugs-announce] [issue19714] Add tests for
	importlib.machinery.WindowsRegistryFinder
Message-ID: <1385139731.13.0.379714643713.issue19714@psf.upfronthosting.co.za>


New submission from Brett Cannon:

At least mocking out things if manipulating the Windows registry during testing is considered bad or difficult to make sure that stuff basically works.

----------
components: Library (Lib)
messages: 203809
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Add tests for importlib.machinery.WindowsRegistryFinder
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 18:42:48 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Nov 2013 17:42:48 +0000
Subject: [New-bugs-announce] [issue19715] test_touch_common failure under
	Windows
Message-ID: <1385142168.58.0.0468844706285.issue19715@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Path.touch() doesn't seem to change the mtime under Windows, which leads to the following failure:

======================================================================
FAIL: test_touch_common (test.test_pathlib.PathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_pathlib.py", line 1391, in test_touch_common
    self.assertGreaterEqual(p.stat().st_mtime, old_mtime)
AssertionError: 1385140662.458926 not greater than or equal to 1385140662.4589267

======================================================================
FAIL: test_touch_common (test.test_pathlib.WindowsPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_pathlib.py", line 1391, in test_touch_common
    self.assertGreaterEqual(p.stat().st_mtime, old_mtime)
AssertionError: 1385140663.098527 not greater than or equal to 1385140663.098528

Can anyone enlighten me about the semantics of st_mtime on Windows?

----------
components: Library (Lib), Tests
messages: 203817
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_touch_common failure under Windows
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 18:43:31 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Nov 2013 17:43:31 +0000
Subject: [New-bugs-announce] [issue19716] test that touch doesn't change
	file contents
Message-ID: <1385142211.7.0.550068935701.issue19716@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Path.touch() shouldn't change a file's contents, but this is currently not tested for by test_pathlib.

----------
components: Tests
keywords: easy
messages: 203818
nosy: pitrou
priority: normal
severity: normal
status: open
title: test that touch doesn't change file contents
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 18:45:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Nov 2013 17:45:53 +0000
Subject: [New-bugs-announce] [issue19717] resolve() fails when the path
	doesn't exist
Message-ID: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Currently Path.resolve() raises FileNotFoundError when the path does not exist. Guido pointed out that it may more useful to resolve the path components until one doesn't exist, and then return the rest unchanged.

e.g. if /home/ points to /var/home/, Path("/home/antoine/toto") should resolve to Path("/var/home/antoine/toto") even if toto doesn't actually exist.

However, this makes the function less safe. Perhaps with a "strict" flag?

----------
components: Library (Lib)
messages: 203819
nosy: gvanrossum, neologix, pitrou
priority: normal
severity: normal
status: open
title: resolve() fails when the path doesn't exist
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 18:49:42 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Nov 2013 17:49:42 +0000
Subject: [New-bugs-announce] [issue19718] Path.glob() on case-insensitive
	Posix filesystems
Message-ID: <1385142582.76.0.752016715187.issue19718@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

test_glob fails under OS X:

======================================================================
FAIL: test_glob (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_pathlib.py", line 1615, in test_glob
    self.assertEqual(set(p.glob("FILEa")), set())
AssertionError: Items in the first set but not the second:
PosixPath('/Users/buildbot/buildarea/3.x.murray-snowleopard/build/build/test_python_39872/@test_39872_tmp/FILEa')


In that test, "FILEa" doesn't exist but "fileA" does.  glob() uses a shortcut when there's no wildcard: it calls .exists() instead of checking the name is inside listdir().  Unfortunately here, the filesystem is insensitive and Path("FILEa").exists() will return True.

However, p.glob("FILEa*") will really return nothing (at least I think so, I don't have a Mac to test), so this is a bit inconsistent.


If we decide the inconsistency is ok, I must then change the test to not exercise it :)

----------
components: Library (Lib), Tests
messages: 203820
nosy: hynek, ned.deily, pitrou, ronaldoussoren
priority: low
severity: normal
status: open
title: Path.glob() on case-insensitive Posix filesystems
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 19:15:15 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 18:15:15 +0000
Subject: [New-bugs-announce] [issue19719] add importlib.abc.SpecLoader and
	SpecFinder
Message-ID: <1385144115.2.0.854403656611.issue19719@psf.upfronthosting.co.za>


New submission from Brett Cannon:

That way the ABCs can require find_spec/load_spec, inherit from the older ABCs, and provide stubs that do what's necessary to support the old, deprecated find_module/find_loader/load_module API (and automatically include the deprecation warning).

----------
assignee: brett.cannon
components: Library (Lib)
messages: 203826
nosy: brett.cannon, eric.snow, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: add importlib.abc.SpecLoader and SpecFinder
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 19:36:50 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 22 Nov 2013 18:36:50 +0000
Subject: [New-bugs-announce] [issue19720] suppress context for some
	exceptions in importlib?
Message-ID: <1385145410.42.0.284273410583.issue19720@psf.upfronthosting.co.za>


New submission from Eric Snow:

Some exceptions in importlib are raised from within except blocks, resulting in chained tracebacks. [1]  For at least some of these we should consider suppressing the exception context.

For example (for [1]):

        try:
            path = parent_module.__path__
        except AttributeError:
            msg = (_ERR_MSG + '; {} is not a package').format(name, parent)
            raise ImportError(msg, name=name) from None

[1] http://hg.python.org/cpython/file/default/Lib/importlib/_bootstrap.py#l2088

----------
messages: 203830
nosy: brett.cannon, eric.snow
priority: low
severity: normal
stage: needs patch
status: open
title: suppress context for some exceptions in importlib?
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov 22 20:10:57 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Nov 2013 19:10:57 +0000
Subject: [New-bugs-announce] [issue19721] Move all test_importlib utility
	code into	test_importlib.util
Message-ID: <1385147457.8.0.6225076975.issue19721@psf.upfronthosting.co.za>


New submission from Brett Cannon:

test_importlib has a ton of utility code, typically segregated into separate util modules in each directory. But it makes importing a pain as you typically end up with the global test_importlib.util plus the directory-specific util module. Would be better to ditch the per-directory ones and just move everything up to test_importlib.util.

----------
assignee: brett.cannon
components: Tests
keywords: easy
messages: 203840
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: Move all test_importlib utility code into test_importlib.util

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

From report at bugs.python.org  Fri Nov 22 20:42:03 2013
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 22 Nov 2013 19:42:03 +0000
Subject: [New-bugs-announce] [issue19722] Expose stack effect calculator to
	Python
Message-ID: <1385149323.26.0.11954812505.issue19722@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Attached is a patch exposing the old opcode_stack_effect() function to Python.  The patch does the following:

* renames opcode_stack_effect() to PyCompile_OpcodeStackEffect()
* removes the "static" modifier from PyCompile_OpcodeStackEffect()
* changes PyCompile_OpcodeStackEffect()'s behavior so it returns a magic
  value on failure
* preserves existing behavior when compiling code and encountering
  an opcode/oparg pair that results in failure
* creates a new _opcode module
* exposes PyCompile_OpcodeStackEffect() as _opcode.stack_effect()
* tests _opcode module with new test__opcode.py
* imports _opcode.stack_effect() into opcode, exposing it publically
* documents the function in dis (there is no documentation for opcode,
  and dis imports and exposes everything in opcode)

Whew!  I think it's ready to go in.

----------
assignee: larry
components: Library (Lib)
files: larry.expose.stack.effect.patch.1.diff
keywords: patch
messages: 203845
nosy: larry, ncoghlan
priority: normal
severity: normal
stage: patch review
status: open
title: Expose stack effect calculator to Python
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32781/larry.expose.stack.effect.patch.1.diff

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

From report at bugs.python.org  Fri Nov 22 21:04:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Nov 2013 20:04:04 +0000
Subject: [New-bugs-announce] [issue19723] Argument Clinic should add markers
	for humans
Message-ID: <1385150644.99.0.984146693257.issue19723@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

I was reviewing a patch by Larry and I started commenting on some rather tasteless code, until I realized it was generated by Argument Clinic.

It would be nice if Argument Clinic added some markers, such as:

/* Start of code generated by Argument Clinic */

/* End of code generated by Argument Clinic */

----------
assignee: larry
components: Build, Demos and Tools
messages: 203852
nosy: larry, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Argument Clinic should add markers for humans
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 21:30:17 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 22 Nov 2013 20:30:17 +0000
Subject: [New-bugs-announce] [issue19724] test_pkgutil buildbot failure
	(related to PEP 451)
Message-ID: <1385152217.94.0.908121512777.issue19724@psf.upfronthosting.co.za>


New submission from Eric Snow:

http://buildbot.python.org/all/builders/x86%20Gentoo%203.x/builds/5448/steps/test/logs/stdio

======================================================================
ERROR: test_iter_importers (test.test_pkgutil.ExtendPathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 2128, in _find_and_load_unlocked
AttributeError: 'module' object has no attribute '__path__'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_pkgutil.py", line 206, in test_iter_importers
    importlib.import_module(fullname)
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/importlib/__init__.py", line 129, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 2164, in _gcd_import
  File "<frozen importlib._bootstrap>", line 2147, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2131, in _find_and_load_unlocked
ImportError: No module named 'spam.eggs'; spam is not a package

----------
components: Library (Lib), Tests
messages: 203861
nosy: brett.cannon, eric.snow
priority: high
severity: normal
stage: needs patch
status: open
title: test_pkgutil buildbot failure (related to PEP 451)
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Nov 22 22:41:48 2013
From: report at bugs.python.org (Philip Jenvey)
Date: Fri, 22 Nov 2013 21:41:48 +0000
Subject: [New-bugs-announce] [issue19725] Richer stat object
Message-ID: <1385156508.32.0.63377992281.issue19725@psf.upfronthosting.co.za>


New submission from Philip Jenvey:

With discussion of the new Pathlib API there's been suggestion (and maybe even already consensus) that some of the convenience APIs provided by it should exist on stat result objects.

It's maybe too late for 3.4, but let's track exactly what additions are wanted

----------
components: Library (Lib)
messages: 203892
nosy: ncoghlan, pitrou, pjenvey
priority: normal
severity: normal
status: open
title: Richer stat object
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 23 00:38:19 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Nov 2013 23:38:19 +0000
Subject: [New-bugs-announce] [issue19726] BaseProtocol is not an ABC
Message-ID: <1385163499.31.0.337273163062.issue19726@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

BaseProtocol docstring describes it as an "ABC for base protocol class", but it is not actually an ABC in the technical sense.

----------
assignee: gvanrossum
components: Library (Lib)
messages: 203921
nosy: gvanrossum, pitrou
priority: normal
severity: normal
status: open
title: BaseProtocol is not an ABC
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 23 02:15:52 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Nov 2013 01:15:52 +0000
Subject: [New-bugs-announce] [issue19727] os.utime(...,
	None) has poor resolution on Windows
Message-ID: <1385169352.32.0.642692439706.issue19727@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

os.utime() uses the following code when times is None under Windows:

        SYSTEMTIME now;
        GetSystemTime(&now);
        if (!SystemTimeToFileTime(&now, &mtime) ||
            !SystemTimeToFileTime(&now, &atime)) {
            PyErr_SetFromWindowsErr(0);
            goto exit;
        }

The problem is GetSystemTime has poor resolution (milliseconds). Instead, it could call GetSystemTimeAsFileTime which writes directly into a FILETIME structure, and potentially (?) has better resolution.

(according to a comment on MSDN, "Resolution on Windows 7 seems to be sub-millisecond": http://msdn.microsoft.com/en-us/library/windows/desktop/ms724397%28v=vs.85%29.aspx )

----------
components: Library (Lib), Windows
messages: 203943
nosy: brian.curtin, larry, loewis, pitrou, steve.dower, tim.golden, tim.peters
priority: normal
severity: normal
status: open
title: os.utime(..., None) has poor resolution on Windows
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 23 02:47:23 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 23 Nov 2013 01:47:23 +0000
Subject: [New-bugs-announce] [issue19728] PEP 453: enable pip by default in
	the binary installers
Message-ID: <1385171243.96.0.0357035720605.issue19728@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

While implementing the Windows installer for PEP 453 in issue 19550, MvL pointed out that, *by default*, the installers should be able to uninstall everything they install.

At the moment, if they install pip by default, that's not accurate, as we don't currently have the appropriate command defined to do the uninstall.

For beta 1, Martin just went with the option of leaving the option off by default, but it would be good to resolve the uninstallation problem and allow it to be enabled by default.

My suggestion for a design requirement is:

    If a user installs CPython use the binary installer, makes no changes to the installation options, makes no use of the installed pip and then uninstalls CPython, then there should be no CPython related files left on their system.

If they *do* use the installed pip (whether to upgrade pip itself or to install other packages), then files may potentially be left behind, since they're seen as user data files by CPython.

I also think it's OK if uninstalling CPython removes setuptools and pip from that installation's site-packages, even if they had been upgraded following the original installation.

----------
messages: 203949
nosy: dstufft, loewis, ncoghlan, ned.deily
priority: high
severity: normal
stage: needs patch
status: open
title: PEP 453: enable pip by default in the binary installers
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 23 03:16:42 2013
From: report at bugs.python.org (HCT)
Date: Sat, 23 Nov 2013 02:16:42 +0000
Subject: [New-bugs-announce] [issue19729] str.format sublevel format parsing
	broken in Python 3.3.3
Message-ID: <1385173002.6.0.538237708826.issue19729@psf.upfronthosting.co.za>


New submission from HCT:

can't find a way around it... maybe a new regression test on this.

Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> "0x{:0{:d}X}".format(0x0,16)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: unmatched '{' in format
>>> "0x{:0{{:d}}X}".format(0x0,16)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid format specifier
>>> "0x{:0{:d}X}".format(0x0,16)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: unmatched '{' in format
>>> "0x{:{:d}X}".format(0x0,16)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: unmatched '{' in format
>>> "0x{:0{:d}X}".format(0x0,16)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: unmatched '{' in format
>>> "0x{:0{:d}x}".format(0x0,16)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: unmatched '{' in format
>>>
>>> "{:0{}x}".format(0,16)
'0000000000000000'

"0x{:0{:d}X}".format(0x0,16) and "{:0{}x}".format(0,16)
work with Python 3.1, 3.2 and up to 3.3.2

----------
components: Interpreter Core
messages: 203954
nosy: hct
priority: normal
severity: normal
status: open
title: str.format sublevel format parsing broken in Python 3.3.3
versions: Python 3.3

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

From report at bugs.python.org  Sat Nov 23 03:28:12 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 23 Nov 2013 02:28:12 +0000
Subject: [New-bugs-announce] [issue19730] Clinic fixes: add converters with
	length, version directive
Message-ID: <1385173692.32.0.599871676954.issue19730@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Two minor changes for Argument Clinic.

* Added a "version" directive, so a programmer can require a
  specific version (or better) of Clinic.

* Finished off support for all the 'legacy' converters.  The ones today
  were those that give off a "length" parameter.  This was complicated
  by finally dealing properly with the Py_buffer conversion stuff.

To properly handle length parameters, I had to support PY_SSIZE_T_CLEAN being turned off (when are we gonna throw that away?).  So I added a new type to pyports.h, Py_ssize_clean_t, which is either an int or a Py_ssize_t depending on PY_SSIZE_T_CLEAN.

I've run out of gas and am going to bed.  I know I have two TODO items in the diff so far; I'll deal with those tomorrow.  But can I get a quick review of the rest, so I can get this in tomorrow?

----------
assignee: larry
components: Build
files: larry.misc.clinic.fixes.diff.1.patch
keywords: patch
messages: 203958
nosy: brett.cannon, larry, ncoghlan, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Clinic fixes: add converters with length, version directive
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32790/larry.misc.clinic.fixes.diff.1.patch

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

From report at bugs.python.org  Sat Nov 23 03:29:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Nov 2013 02:29:28 +0000
Subject: [New-bugs-announce] [issue19731] Fix copyright footer
Message-ID: <1385173768.12.0.946242825352.issue19731@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Marc-Andr? pointed out that the copyright footer has the wrong date. See attached patch.

----------
assignee: docs at python
components: Documentation
files: copyright.patch
keywords: patch
messages: 203959
nosy: docs at python, lemburg, pitrou
priority: low
severity: normal
status: open
title: Fix copyright footer
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32791/copyright.patch

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

From report at bugs.python.org  Sat Nov 23 09:33:00 2013
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 23 Nov 2013 08:33:00 +0000
Subject: [New-bugs-announce] [issue19732] python fails to build when
	configured with	--with-system-libmpdec
Message-ID: <1385195580.05.0.00984042109495.issue19732@psf.upfronthosting.co.za>


New submission from Matthias Klose:

using the only mpdecimal release (2.3):

building '_decimal' extension
creating build/temp.linux-x86_64-3.3/scratch/packages/python/3.3/python3.3-3.3.3/Modules/_decimal
x86_64-linux-gnu-gcc -pthread -fPIC -D_FORTIFY_SOURCE=2 -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fprofile-generate -g -flto -fuse-linker-plugin -DCONFIG_64=1 -DASM=1 -I../Include -I. -IInclude -I/usr/include/x86_64-linux-gnu -I/scratch/packages/python/3.3/python3.3-3.3.3/Include -I/scratch/packages/python/3.3/python3.3-3.3.3/build-static -c /scratch/packages/python/3.3/python3.3-3.3.3/Modules/_decimal/_decimal.c -o build/temp.linux-x86_64-3.3/scratch/packages/python/3.3/python3.3-3.3.3/Modules/_decimal/_decimal.o -Wextra -Wno-missing-field-initializers
/scratch/packages/python/3.3/python3.3-3.3.3/Modules/_decimal/_decimal.c: In function 'dectuple_as_str':
/scratch/packages/python/3.3/python3.3-3.3.3/Modules/_decimal/_decimal.c:2522:47: error: expected ')' before 'PRI_mpd_ssize_t'
         n = snprintf(cp, MPD_EXPDIGITS+2, "%" PRI_mpd_ssize_t, exp);
                                               ^
/scratch/packages/python/3.3/python3.3-3.3.3/Modules/_decimal/_decimal.c:2522:47: warning: spurious trailing '%' in format [-Wformat=]
/scratch/packages/python/3.3/python3.3-3.3.3/Modules/_decimal/_decimal.c:2522:47: warning: spurious trailing '%' in format [-Wformat=]
/scratch/packages/python/3.3/python3.3-3.3.3/Modules/_decimal/_decimal.c: In function 'dec_str':
/scratch/packages/python/3.3/python3.3-3.3.3/Modules/_decimal/_decimal.c:3075:5: warning: implicit declaration of function 'mpd_to_sci_size' [-Wimplicit-function-declaration]
     size = mpd_to_sci_size(&cp, MPD(dec), CtxCaps(context));
     ^
/scratch/packages/python/3.3/python3.3-3.3.3/Modules/_decimal/_decimal.c: In function 'dec_format':
/scratch/packages/python/3.3/python3.3-3.3.3/Modules/_decimal/_decimal.c:3243:9: warning: implicit declaration of function 'mpd_validate_lconv' [-Wimplicit-function-declaration]
         if (mpd_validate_lconv(&spec) < 0) {
         ^
/scratch/packages/python/3.3/python3.3-3.3.3/Modules/_decimal/_decimal.c: In function 'dec_as_long':
/scratch/packages/python/3.3/python3.3-3.3.3/Modules/_decimal/_decimal.c:3340:5: warning: passing argument 1 of 'mpd_qexport_u32' from incompatible pointer type [enabled by default]
     n = mpd_qexport_u32(&ob_digit, 0, PyLong_BASE, x, &status);
     ^
In file included from /scratch/packages/python/3.3/python3.3-3.3.3/Modules/_decimal/_decimal.c:34:0:
/usr/include/x86_64-linux-gnu/mpdecimal.h:474:8: note: expected 'uint32_t *' but argument is of type 'digit **'
 size_t mpd_qexport_u32(uint32_t *rdata, size_t rlen, uint32_t base,
        ^
/scratch/packages/python/3.3/python3.3-3.3.3/Modules/_decimal/_decimal.c: In function 'dec_mpd_to_eng':
/scratch/packages/python/3.3/python3.3-3.3.3/Modules/_decimal/_decimal.c:4136:5: warning: implicit declaration of function 'mpd_to_eng_size' [-Wimplicit-function-declaration]
     size = mpd_to_eng_size(&s, MPD(self), CtxCaps(context));
     ^

----------
components: Build
messages: 203978
nosy: doko
priority: normal
severity: normal
status: open
title: python fails to build when configured with --with-system-libmpdec
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Nov 23 14:09:46 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Nov 2013 13:09:46 +0000
Subject: [New-bugs-announce] [issue19733] Setting image parameter of a
	button crashes with Cocoa Tk
Message-ID: <1385212186.78.0.599244063108.issue19733@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>From msg202006:

With Cocoa Tk 8.5.15 or Cocoa Tk 8.6.1 on OS X 10.8.5, test_widgets.ButtonTest crashes Tk:

test_image (tkinter.test.test_tkinter.test_widgets.ButtonTest) ... 2013-11-03 01:52:53.498 pytest_10.8[82465:f07] *** Assertion failure in -[NSBitmapImageRep initWithCGImage:], /SourceCache/AppKit/AppKit-1187.40/AppKit.subproj/NSBitmapImageRep.m:1242
2013-11-03 01:52:53.499 pytest_10.8[82465:f07] An uncaught exception was raised
2013-11-03 01:52:53.499 pytest_10.8[82465:f07] Invalid parameter not satisfying: cgImage != NULL
2013-11-03 01:52:53.502 pytest_10.8[82465:f07] (
	0   CoreFoundation                      0x965eae8b __raiseError + 219
	1   libobjc.A.dylib                     0x956d152e objc_exception_throw + 230
	2   CoreFoundation                      0x9654a698 +[NSException raise:format:arguments:] + 136
	3   Foundation                          0x966a5364 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 116
	4   AppKit                              0x98a34525 -[NSBitmapImageRep initWithCGImage:] + 145
	5   Tk                                  0x00725a48 CreateNSImageWithPixmap + 151
	6   Tk                                  0x00725b1c TkMacOSXGetNSImageWithTkImage + 149
	7   Tk                                  0x0071eb2f TkpComputeButtonGeometry + 2550
	8   Tk                                  0x0069849d TkButtonWorldChanged + 470
	9   Tk                                  0x00698e99 ConfigureButton + 1981
	10  Tk                                  0x0069980f ButtonWidgetObjCmd + 440
	11  Tcl                                 0x00579c2f TclEvalObjvInternal + 770
	12  Tcl                                 0x0057ac1a Tcl_EvalObjv + 72
	13  _tkinter.so                         0x0055db81 Tkapp_Call + 673
        [...]

----------
assignee: ronaldoussoren
components: Macintosh, Tkinter
messages: 203999
nosy: ned.deily, ronaldoussoren, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Setting image parameter of a button crashes with Cocoa Tk
type: crash
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Nov 23 14:51:42 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Nov 2013 13:51:42 +0000
Subject: [New-bugs-announce] [issue19734] test_venv.test_with_pip() fails on
	"AMD64 Ubuntu LTS	3.x" buildbot
Message-ID: <1385214702.5.0.171407877009.issue19734@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/3178/steps/test/logs/stdio

Re-running failed tests in verbose mode
Re-running test 'test_venv' in verbose mode
test_defaults (test.test_venv.BasicTest) ... ok
test_executable (test.test_venv.BasicTest) ... ok
test_executable_symlinks (test.test_venv.BasicTest) ... ok
test_isolation (test.test_venv.BasicTest) ... ok
test_overwrite_existing (test.test_venv.BasicTest) ... ok
test_prefixes (test.test_venv.BasicTest) ... ok
test_symlinking (test.test_venv.BasicTest) ... ok
test_unoverwritable_fails (test.test_venv.BasicTest) ... ok
test_upgrade (test.test_venv.BasicTest) ... ok
test_explicit_no_pip (test.test_venv.EnsurePipTest) ... ok
test_no_pip_by_default (test.test_venv.EnsurePipTest) ... ok
test_with_pip (test.test_venv.EnsurePipTest) ... test test_venv failed
ERROR

======================================================================
ERROR: test_with_pip (test.test_venv.EnsurePipTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_venv.py", line 288, in test_with_pip
    self.run_with_capture(venv.create, self.env_dir, with_pip=True)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_venv.py", line 48, in run_with_capture
    func(*args, **kwargs)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/venv/__init__.py", line 359, in create
    builder.create(env_dir)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/venv/__init__.py", line 86, in create
    self._setup_pip(context)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/venv/__init__.py", line 242, in _setup_pip
    subprocess.check_output(cmd)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/subprocess.py", line 618, in check_output
    raise CalledProcessError(retcode, process.args, output=output)
subprocess.CalledProcessError: Command '['/tmp/tmp4_ukigy9/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 3

----------
components: Tests
keywords: buildbot
messages: 204013
nosy: haypo, loewis, nick
priority: normal
severity: normal
status: open
title: test_venv.test_with_pip() fails on "AMD64 Ubuntu LTS 3.x" buildbot
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 23 16:46:03 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 23 Nov 2013 15:46:03 +0000
Subject: [New-bugs-announce] [issue19735] ssl._create_stdlib_context
Message-ID: <1385221563.59.0.016103325517.issue19735@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The second part of #19689. This patch implements _create_stdlib_context() that wrap lots of common code in one function that is private to Python's stdlib.

----------
components: Library (Lib)
files: ssl_create_stdlib_context.patch
keywords: patch
messages: 204042
nosy: christian.heimes, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: ssl._create_stdlib_context
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32804/ssl_create_stdlib_context.patch

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

From report at bugs.python.org  Sat Nov 23 16:55:25 2013
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 23 Nov 2013 15:55:25 +0000
Subject: [New-bugs-announce] [issue19736] posixmodule.c: Add flags for
	statvfs.f_flag to constant	list
Message-ID: <1385222125.46.0.688361383331.issue19736@psf.upfronthosting.co.za>


New submission from Matthias Klose:

the posix module has the statvfs call, but doesn't define any constants used as parameters. add them.

----------
components: Extension Modules
files: statvfs-f_flag-constants.diff
keywords: patch
messages: 204043
nosy: doko
priority: normal
severity: normal
status: open
title: posixmodule.c: Add flags for statvfs.f_flag to constant list
versions: Python 3.4
Added file: http://bugs.python.org/file32805/statvfs-f_flag-constants.diff

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

From report at bugs.python.org  Sat Nov 23 17:51:01 2013
From: report at bugs.python.org (Zahari Dim)
Date: Sat, 23 Nov 2013 16:51:01 +0000
Subject: [New-bugs-announce] [issue19737] Documentation of globals() and
	locals() should be	improved
Message-ID: <1385225461.09.0.671908077084.issue19737@psf.upfronthosting.co.za>


New submission from Zahari Dim:

The globals() notification states:

Return a dictionary representing the current global symbol table.[...]

This doc and the fact that globals() is called as a function made me think that globals() returns a copy of the global namespace dict, rather than an object that could be used to actually modify the namespace. I don't find obvious the meaning of "representing" in this context.

This of course led to a very nasty and sneaky bug in my code.

The docs of locals() don't seem clear to me either, thought at least it seems to imply that it is actually modifying the namespace.

----------
assignee: docs at python
components: Documentation
messages: 204052
nosy: Zahari.Dim, docs at python
priority: normal
severity: normal
status: open
title: Documentation of globals() and locals() should be improved

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

From report at bugs.python.org  Sat Nov 23 18:27:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Nov 2013 17:27:12 +0000
Subject: [New-bugs-announce] [issue19738] pytime.c loses precision under
	Windows
Message-ID: <1385227632.17.0.4146549909.issue19738@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Under Windows, GetSystemTimeAsFileTime has a 100 ns resolution, but pygettimeofday stores it in a timeval which only has microsecond resolution. As a consequence, some precision is lost under Windows (which shows e.g. in time.time() results).

----------
components: Interpreter Core
messages: 204063
nosy: haypo, loewis, pitrou, tim.peters
priority: normal
severity: normal
status: open
title: pytime.c loses precision under Windows
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Nov 23 20:51:04 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 23 Nov 2013 19:51:04 +0000
Subject: [New-bugs-announce] [issue19739] Legit compiler warnings in new
	pickle code on 32-bit	Windows
Message-ID: <1385236264.72.0.60711493858.issue19739@psf.upfronthosting.co.za>


New submission from Tim Peters:

1>..\Modules\_pickle.c(710): warning C4293: '>>' : shift count negative or too big, undefined behavior
1>..\Modules\_pickle.c(711): warning C4293: '>>' : shift count negative or too big, undefined behavior
1>..\Modules\_pickle.c(712): warning C4293: '>>' : shift count negative or too big, undefined behavior
1>..\Modules\_pickle.c(713): warning C4293: '>>' : shift count negative or too big, undefined behavior
1>..\Modules\_pickle.c(1158): warning C4018: '<' : signed/unsigned mismatch

The first 4 should be easy to fix by using a SIZEOF_SIZE_T >= 8 #ifdef test.  The last is on:

        if (frame_len < n) { ... raise an exception ...

where `frame_len` is size_t and `n` is Py_ssize_t.

----------
assignee: alexandre.vassalotti
messages: 204084
nosy: alexandre.vassalotti, pitrou, tim.peters
priority: normal
severity: normal
status: open
title: Legit compiler warnings in new pickle code on 32-bit Windows
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 23 23:13:28 2013
From: report at bugs.python.org (Tim Peters)
Date: Sat, 23 Nov 2013 22:13:28 +0000
Subject: [New-bugs-announce] [issue19740] test_asyncio problems on 32-bit
	Windows
Message-ID: <1385244808.7.0.933656796277.issue19740@psf.upfronthosting.co.za>


New submission from Tim Peters:

With current default branch, test_asyncio always fails on my 32-bit Windows Vista box, in test_wait_for_handle:

test test_asyncio failed -- Traceback (most recent call last):
  File "C:\Code\Python\lib\test\test_asyncio\test_windows_events.py", line 122, in test_wait_for_handle
    self.assertTrue(f.result())
AssertionError: False is not true

If I comment out that line, the rest of the test passes.

There's also a pile of annoying warnings:

C:\Code\Python\lib\test\test_asyncio\test_events.py:195: ResourceWarning: unclosed <socket.socket fd=456, family=AddressFamily.AF_INET, type=SocketType.SOCK_STREAM, proto=0>
  gc.collect()
C:\Code\Python\lib\test\test_asyncio\test_events.py:195: ResourceWarning: unclosed <socket.socket fd=200, family=AddressFamily.AF_INET, type=SocketType.SOCK_STREAM, proto=0>
  gc.collect()
C:\Code\Python\lib\test\test_asyncio\test_events.py:195: ResourceWarning: unclosed <socket.socket fd=476, family=AddressFamily.AF_INET, type=SocketType.SOCK_STREAM, proto=0>
  gc.collect()
C:\Code\Python\lib\test\test_asyncio\test_events.py:195: ResourceWarning: unclosed <socket.socket fd=508, family=AddressFamily.AF_INET6, type=SocketType.SOCK_STREAM, proto=0>
  gc.collect()
C:\Code\Python\lib\test\test_asyncio\test_events.py:195: ResourceWarning: unclosed <socket.socket fd=528, family=AddressFamily.AF_INET, type=SocketType.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 61433), raddr=('127.0.0.1', 61434)>
  gc.collect()
C:\Code\Python\lib\test\test_asyncio\test_events.py:195: ResourceWarning: unclosed <socket.socket fd=516, fami
ly=AddressFamily.AF_INET, type=SocketType.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 61434), raddr=('127.0.0.1', 61433)>
  gc.collect()
C:\Code\Python\lib\test\test_asyncio\test_events.py:195: ResourceWarning: unclosed <socket.socket fd=556, family=AddressFamily.AF_INET, type=SocketType.SOCK_STREAM, proto=0>
  gc.collect()
C:\Code\Python\lib\unittest\case.py:571: ResourceWarning: unclosed <socket.socket fd=544, family=AddressFamily
.AF_INET, type=SocketType.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 61652), raddr=('127.0.0.1', 61651)>
  testMethod()

----------
assignee: gvanrossum
messages: 204116
nosy: gvanrossum, tim.peters
priority: normal
severity: normal
status: open
title: test_asyncio problems on 32-bit Windows
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 24 00:47:04 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Nov 2013 23:47:04 +0000
Subject: [New-bugs-announce] [issue19741] tracemalloc:
	tracemalloc_log_alloc() doesn't check	_Py_HASHTABLE_SET()
	return value
Message-ID: <1385250424.67.0.149405281139.issue19741@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Christian posted me this warning on IRC:

** CID 1131947:  Unchecked return value  (CHECKED_RETURN) /Modules/_tracemalloc.c: 462 in tracemalloc_log_alloc()

----------
messages: 204131
nosy: christian.heimes, haypo
priority: normal
severity: normal
status: open
title: tracemalloc: tracemalloc_log_alloc() doesn't check _Py_HASHTABLE_SET() return value
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 24 01:45:29 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 24 Nov 2013 00:45:29 +0000
Subject: [New-bugs-announce] [issue19742] pathlib group unittests can fail
Message-ID: <1385253929.39.0.153589073777.issue19742@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

When running test_pathlib on my OSX (10.8) laptop I get these errors:

======================================================================
ERROR: test_group (test.test_pathlib.PathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/guido/cpython/Lib/test/test_pathlib.py", line 1332, in test_group
    name = grp.getgrgid(gid).gr_name
KeyError: 'getgrgid(): gid not found: 849048494'

======================================================================
ERROR: test_group (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/guido/cpython/Lib/test/test_pathlib.py", line 1332, in test_group
    name = grp.getgrgid(gid).gr_name
KeyError: 'getgrgid(): gid not found: 849048494'

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

This is probably some kind of OSX quirk where st_gid is set to a group that's not in /etc/groups, because (except briefly during the reboot process) on OS X the /etc configuration files for users/groups do not provide the whole truth.

Sadly I don't know what API to use to get the group name.   "ls -l" doesn't seem to know either.  My home dir has that gid too, so it's not an isolated anomaly. It may well be some kind of corporate thing (it's not really "my" laptop. :-)

----------
assignee: pitrou
messages: 204141
nosy: gvanrossum, pitrou
priority: normal
severity: normal
status: open
title: pathlib group unittests can fail
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 24 02:10:48 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 24 Nov 2013 01:10:48 +0000
Subject: [New-bugs-announce] [issue19743] test_gdb failures
Message-ID: <1385255448.44.0.696439937315.issue19743@psf.upfronthosting.co.za>


New submission from Larry Hastings:

test_gdb started failing on me within the past few days.  (I would have reported it sooner but I figured the omniscient CPython core dev community already knew about it.)

The machine it's failing on is Ubuntu 13.10, 64-bit.

----------
components: Tests
files: gdb_test_failure
messages: 204143
nosy: larry, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_gdb failures
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32816/gdb_test_failure

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

From report at bugs.python.org  Sun Nov 24 02:38:45 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 24 Nov 2013 01:38:45 +0000
Subject: [New-bugs-announce] [issue19744] test_venv failing on 32-bit
	Windows Vista
Message-ID: <1385257125.97.0.543842843872.issue19744@psf.upfronthosting.co.za>


New submission from Tim Peters:

With the current default branch, test_venv fails every time for me:

[1/1] test_venv
Traceback (most recent call last):
  File "C:\Code\Python\lib\runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "C:\Code\Python\lib\runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "C:\Code\Python\lib\ensurepip\__main__.py", line 66, in <module>
    main()
  File "C:\Code\Python\lib\ensurepip\__main__.py", line 61, in main
    default_pip=args.default_pip,
  File "C:\Code\Python\lib\ensurepip\__init__.py", line 92, in bootstrap
    _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
  File "C:\Code\Python\lib\ensurepip\__init__.py", line 28, in _run_pip
    import pip
  File "C:\Users\Tim\AppData\Local\Temp\tmpjltqdgi8\pip-1.5.rc1-py2.py3-none-any.whl\pip\__init__.py", line 10
, in <module>
  File "C:\Users\Tim\AppData\Local\Temp\tmpjltqdgi8\pip-1.5.rc1-py2.py3-none-any.whl\pip\util.py", line 17, in
 <module>
  File "C:\Users\Tim\AppData\Local\Temp\tmpjltqdgi8\pip-1.5.rc1-py2.py3-none-any.whl\pip\_vendor\distlib\versi
on.py", line 14, in <module>
  File "C:\Users\Tim\AppData\Local\Temp\tmpjltqdgi8\pip-1.5.rc1-py2.py3-none-any.whl\pip\_vendor\distlib\compat.py", line 66, in <module>
ImportError: cannot import name 'HTTPSHandler'
test test_venv failed -- Traceback (most recent call last):
  File "C:\Code\Python\lib\test\test_venv.py", line 288, in test_with_pip
    self.run_with_capture(venv.create, self.env_dir, with_pip=True)
  File "C:\Code\Python\lib\test\test_venv.py", line 48, in run_with_capture
    func(*args, **kwargs)
  File "C:\Code\Python\lib\venv\__init__.py", line 359, in create
    builder.create(env_dir)
  File "C:\Code\Python\lib\venv\__init__.py", line 86, in create
    self._setup_pip(context)
  File "C:\Code\Python\lib\venv\__init__.py", line 242, in _setup_pip
    subprocess.check_output(cmd)
  File "C:\Code\Python\lib\subprocess.py", line 618, in check_output
    raise CalledProcessError(retcode, process.args, output=output)
subprocess.CalledProcessError: Command '['C:\\Users\\Tim\\AppData\\Local\\Temp\\tmpt0ca1aqn\\Scripts\\python_d
.exe', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

1 test failed:
    test_venv

All virtual Greek to me.

----------
messages: 204149
nosy: tim.peters
priority: normal
severity: normal
status: open
title: test_venv failing on 32-bit Windows Vista
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 24 03:40:50 2013
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Nov 2013 02:40:50 +0000
Subject: [New-bugs-announce] [issue19745] TEST_DATA_DIR for out-of-tree
	builds
Message-ID: <1385260850.2.0.647023626646.issue19745@psf.upfronthosting.co.za>


New submission from Christian Heimes:

test.support declares a TEST_DATA_DIR directory inside the source tree of Python:

TEST_SUPPORT_DIR = os.path.dirname(os.path.abspath(__file__))
TEST_HOME_DIR = os.path.dirname(TEST_SUPPORT_DIR)
TEST_DATA_DIR = os.path.join(TEST_HOME_DIR, "data")

make distclean cleans up the very same directory, see r87481. This feature doesn't cope will with out-of-tree builds with a read-only source directory. It looks like this feature isn't used by any test module. Can I remove it?

----------
components: Tests
messages: 204166
nosy: christian.heimes
priority: low
severity: normal
stage: needs patch
status: open
title: TEST_DATA_DIR for out-of-tree builds
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Nov 24 04:16:03 2013
From: report at bugs.python.org (Robert Collins)
Date: Sun, 24 Nov 2013 03:16:03 +0000
Subject: [New-bugs-announce] [issue19746] No introspective way to detect
	ModuleImportFailure
Message-ID: <1385262963.63.0.210713286499.issue19746@psf.upfronthosting.co.za>


New submission from Robert Collins:

https://bugs.launchpad.net/testtools/+bug/1245672 was filed on testtools recently. It would be easier to fix that if there was some way that something loading a test suite could check to see if there were import errors. The current code nicely works in the case where folk run the tests - so we should keep that behaviour, but also accumulate a list somewhere.

One possibility would be on the returned top level suite; another place would be on the loader itself. Or a new return type where we return a tuple of (suite, failures), but thats a more intrusive API change.

Any preference about how to solve this? I will work up a patch given some minor direction.

----------
components: Library (Lib)
messages: 204172
nosy: michael.foord, rbcollins
priority: normal
severity: normal
status: open
title: No introspective way to detect ModuleImportFailure
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Nov 24 06:09:28 2013
From: report at bugs.python.org (Tim Peters)
Date: Sun, 24 Nov 2013 05:09:28 +0000
Subject: [New-bugs-announce] [issue19747] New failures in test_pickletools
	on 32-bit Windows Vista
Message-ID: <1385269768.24.0.0786219443726.issue19747@psf.upfronthosting.co.za>


New submission from Tim Peters:

Alexandre, this started after your latest checkin (to finish the framing work):

======================================================================
FAIL: test_framing_large_objects (test.test_pickletools.OptimizedPickleTests) (proto=4)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Code\Python\lib\test\pickletester.py", line 1354, in test_framing_large_objects
    self.assertGreaterEqual(n_frames, len(obj))
AssertionError: 1 not greater than or equal to 3

======================================================================
FAIL: test_framing_many_objects (test.test_pickletools.OptimizedPickleTests) (proto=4)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Code\Python\lib\test\pickletester.py", line 1342, in test_framing_many_objects
    self.FRAME_SIZE_TARGET * 1)
AssertionError: 368886.0 not less than or equal to 65536

======================================================================
FAIL: test_optional_frames (test.test_pickletools.OptimizedPickleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Code\Python\lib\test\pickletester.py", line 1392, in test_optional_frames
    count_opcode(pickle.FRAME, pickled))
AssertionError: 1 not less than 1

----------------------------------------------------------------------
Ran 82 tests in 4.034s

FAILED (failures=3)
test test_pickletools failed
1 test failed:
    test_pickletools

----------
assignee: alexandre.vassalotti
messages: 204180
nosy: alexandre.vassalotti, tim.peters
priority: normal
severity: normal
status: open
title: New failures in test_pickletools on 32-bit Windows Vista
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 24 13:36:24 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Nov 2013 12:36:24 +0000
Subject: [New-bugs-announce] [issue19748] test_time failures on AIX
Message-ID: <1385296584.36.0.0978202241603.issue19748@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/1138/steps/test/logs/stdio

======================================================================
ERROR: test_mktime (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_time.py", line 348, in test_mktime
    self.assertEqual(time.mktime(tt), t)
OverflowError: mktime argument out of range

======================================================================
FAIL: test_ctime (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_time.py", line 233, in test_ctime
    self.assertEqual(time.ctime(testval)[20:], str(year))
AssertionError: '1941' != '-100'
- 1941
+ -100

----------
messages: 204201
nosy: David.Edelsohn, haypo
priority: normal
severity: normal
status: open
title: test_time failures on AIX

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

From report at bugs.python.org  Sun Nov 24 13:40:30 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Nov 2013 12:40:30 +0000
Subject: [New-bugs-announce] [issue19749] test_venv failure on AIX: 'module'
	object has no	attribute 'O_NOFOLLOW'
Message-ID: <1385296830.18.0.279935527114.issue19749@psf.upfronthosting.co.za>


New submission from STINNER Victor:

os.open(path, os.O_RDONLY | os.O_NOFOLLOW) fails on AIX:

https://github.com/pypa/pip/blob/develop/pip/locations.py#L70

http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/1138/steps/test/logs/stdio

[120/387/3] test_venv
test_defaults (test.test_venv.BasicTest) ... ok
test_executable (test.test_venv.BasicTest) ... ok
test_executable_symlinks (test.test_venv.BasicTest) ... ok
test_isolation (test.test_venv.BasicTest) ... ok
test_overwrite_existing (test.test_venv.BasicTest) ... ok
test_prefixes (test.test_venv.BasicTest) ... ok
test_symlinking (test.test_venv.BasicTest) ... ok
test_unoverwritable_fails (test.test_venv.BasicTest) ... ok
test_upgrade (test.test_venv.BasicTest) ... ok
test_explicit_no_pip (test.test_venv.EnsurePipTest) ... ok
test_no_pip_by_default (test.test_venv.EnsurePipTest) ... ok
test_with_pip (test.test_venv.EnsurePipTest) ... FAIL

======================================================================
FAIL: test_with_pip (test.test_venv.EnsurePipTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_venv.py", line 299, in test_with_pip
    self.run_with_capture(venv.create, self.env_dir, with_pip=True)
subprocess.CalledProcessError: Command '['/tmp/tmpu7qsi1xa/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_venv.py", line 305, in test_with_pip
    self.fail(msg)
AssertionError: Command '['/tmp/tmpu7qsi1xa/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

**Subprocess Output**
Traceback (most recent call last):
  File "/tmp/tmpch6gt1sg/pip-1.5.rc1-py2.py3-none-any.whl/pip/locations.py", line 65, in _get_build_prefix
FileExistsError: [Errno 17] File exists: '/tmp/pip_build_shager'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/ensurepip/__main__.py", line 66, in <module>
    main()
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/ensurepip/__main__.py", line 61, in main
    default_pip=args.default_pip,
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/ensurepip/__init__.py", line 92, in bootstrap
    _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/ensurepip/__init__.py", line 28, in _run_pip
    import pip
  File "<frozen importlib._bootstrap>", line 2147, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2136, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1178, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1140, in _load_backward_compatible
  File "/tmp/tmpch6gt1sg/pip-1.5.rc1-py2.py3-none-any.whl/pip/__init__.py", line 10, in <module>
  File "<frozen importlib._bootstrap>", line 2147, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2136, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1178, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1140, in _load_backward_compatible
  File "/tmp/tmpch6gt1sg/pip-1.5.rc1-py2.py3-none-any.whl/pip/util.py", line 15, in <module>
  File "<frozen importlib._bootstrap>", line 2147, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2136, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1178, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1140, in _load_backward_compatible
  File "/tmp/tmpch6gt1sg/pip-1.5.rc1-py2.py3-none-any.whl/pip/locations.py", line 91, in <module>
  File "/tmp/tmpch6gt1sg/pip-1.5.rc1-py2.py3-none-any.whl/pip/locations.py", line 70, in _get_build_prefix
AttributeError: 'module' object has no attribute 'O_NOFOLLOW'

----------
messages: 204202
nosy: David.Edelsohn, haypo, ncoghlan
priority: normal
severity: normal
status: open
title: test_venv failure on AIX: 'module' object has no attribute 'O_NOFOLLOW'
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 24 13:42:30 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Nov 2013 12:42:30 +0000
Subject: [New-bugs-announce] [issue19750] test_asyncio.test_unix_events
	constructor failures on AIX
Message-ID: <1385296950.99.0.982628682855.issue19750@psf.upfronthosting.co.za>


New submission from STINNER Victor:

buildbot.python.org/all/builders/PPC64 AIX 3.x/builds/1138/steps/test/logs/stdio 

======================================================================
FAIL: test_ctor (test.test_asyncio.test_unix_events.UnixWritePipeTransportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_asyncio/test_unix_events.py", line 389, in test_ctor
    self.loop.assert_reader(5, tr._read_ready)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/asyncio/test_utils.py", line 217, in assert_reader
    assert fd in self.readers, 'fd {} is not registered'.format(fd)
AssertionError: fd 5 is not registered

======================================================================
FAIL: test_ctor_with_waiter (test.test_asyncio.test_unix_events.UnixWritePipeTransportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_asyncio/test_unix_events.py", line 397, in test_ctor_with_waiter
    self.loop.assert_reader(5, tr._read_ready)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/asyncio/test_utils.py", line 217, in assert_reader
    assert fd in self.readers, 'fd {} is not registered'.format(fd)
AssertionError: fd 5 is not registered

----------
messages: 204203
nosy: David.Edelsohn, gvanrossum, haypo
priority: normal
severity: normal
status: open
title: test_asyncio.test_unix_events constructor failures on AIX
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 24 13:46:27 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Nov 2013 12:46:27 +0000
Subject: [New-bugs-announce] [issue19751] test_sys: sys.hash_info.algorithm
	failure on SPARC	Solaris buildbot
Message-ID: <1385297187.74.0.693847111414.issue19751@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/SPARC%20Solaris%2010%20%28cc%2C%2032b%29%20%5BSB%5D%203.x/builds/1574/steps/test/logs/stdio

======================================================================
FAIL: test_attributes (test.test_sys.SysModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/3.x.snakebite-sol10-sparc-cc-32/build/Lib/test/test_sys.py", line 462, in test_attributes
    self.assertEqual(sys.hash_info.algorithm, "fnv")
AssertionError: 'siphash24' != 'fnv'
- siphash24
+ fnv

----------
messages: 204205
nosy: christian.heimes, haypo
priority: normal
severity: normal
status: open
title: test_sys: sys.hash_info.algorithm failure on SPARC Solaris buildbot
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 24 13:48:55 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Nov 2013 12:48:55 +0000
Subject: [New-bugs-announce] [issue19752] test_os failure on Solaris 10
Message-ID: <1385297335.29.0.992027389374.issue19752@psf.upfronthosting.co.za>


New submission from STINNER Victor:

It looks like a regression was introduced in Python 3.4 (the test pass on Python 3.3). It may be related to the PEP 446 (non inheritable file descriptors).

http://buildbot.python.org/all/builders/SPARC Solaris 10 (cc%2C 32b) [SB] 3.x/builds/1574/steps/test/logs/stdio 

======================================================================
ERROR: test (test.test_openpty.OpenptyTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/cpython/buildslave/cc-32/3.x.snakebite-sol10-sparc-cc-32/build/Lib/test/test_openpty.py", line 12, in test
    master, slave = os.openpty()
PermissionError: [Errno 13] Permission denied

----------
messages: 204207
nosy: haypo
priority: normal
severity: normal
status: open
title: test_os failure on Solaris 10
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 24 13:51:38 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Nov 2013 12:51:38 +0000
Subject: [New-bugs-announce] [issue19753] test_gdb failure on SystemZ
	buildbot
Message-ID: <1385297498.35.0.580960849051.issue19753@psf.upfronthosting.co.za>


New submission from STINNER Victor:

test_gdb should ignore the following gdb warning.

http://buildbot.python.org/all/builders/System%20Z%20Linux%203.x/builds/806/steps/test/logs/stdio

======================================================================
FAIL: test_NULL_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with NULL ob_type is handled gracefully
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/test/test_gdb.py", line 440, in test_NULL_ob_type
    'set v->ob_type=0')
  File "/home/dje/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/test/test_gdb.py", line 411, in assertSane
    cmds_after_breakpoint=cmds_after_breakpoint)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/test/test_gdb.py", line 196, in get_gdb_repr
    import_site=import_site)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-zlinux-z/build/Lib/test/test_gdb.py", line 179, in get_stack_trace
    self.assertEqual(unexpected_errlines, [])
AssertionError: Lists differ: ['Missing separate debuginfo for /lib/ld64[801 chars]a1"'] != []

First list contains 12 additional elements.
First extra element 0:
Missing separate debuginfo for /lib/ld64.so.1

Diff is 925 characters long. Set self.maxDiff to None to see it.

----------
messages: 204209
nosy: dmalcolm, haypo
priority: normal
severity: normal
status: open
title: test_gdb failure on SystemZ buildbot
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 24 14:29:04 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Nov 2013 13:29:04 +0000
Subject: [New-bugs-announce] [issue19754] pickletools.optimize doesn't
	reframe correctly
Message-ID: <1385299744.51.0.958781846562.issue19754@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

pickletools.optimize() can output arbitrarily large frames (much larger than then 64 KB heuristic). This may be annoying for memory use when pickling -- on the other hand if you keep the whole pickle in memory for optimize() perhaps it's not a problem keeping it in memory for load() :-)

$ ./python -c "import pickle, pickletools; d = pickle.dumps(list(range(100000)), 4); pickletools.dis(d)"  | head
    0: \x80 PROTO      4
    2: \x95 FRAME      65537
   11: ]    EMPTY_LIST
   12: \x94 MEMOIZE
   13: (    MARK
   14: K        BININT1    0
   16: K        BININT1    1
   18: K        BININT1    2
   20: K        BININT1    3
   22: K        BININT1    4

$ ./python -c "import pickle, pickletools; d = pickle.dumps(list(range(100000)), 4); pickletools.dis(pickletools.optimize(d))"  | head
    0: \x80 PROTO      4
    2: \x95 FRAME      368875
   11: ]    EMPTY_LIST
   12: \x94 MEMOIZE
   13: (    MARK
   14: K        BININT1    0
   16: K        BININT1    1
   18: K        BININT1    2
   20: K        BININT1    3
   22: K        BININT1    4

----------
messages: 204213
nosy: alexandre.vassalotti, pitrou, tim.peters
priority: low
severity: normal
status: open
title: pickletools.optimize doesn't reframe correctly
type: resource usage
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 24 17:16:31 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 24 Nov 2013 16:16:31 +0000
Subject: [New-bugs-announce] [issue19755] PEP 397 listed as accepted instead
	of finished.
Message-ID: <1385309791.24.0.404517317536.issue19755@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

On the PEP index 397 is listed under the section "Accepted PEPs (accepted; may not be implemented yet)".  I believe it should be moved to Finished PEPs (done, implemented in code repository).

----------
messages: 204227
nosy: BreamoreBoy
priority: normal
severity: normal
status: open
title: PEP 397 listed as accepted instead of finished.

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

From report at bugs.python.org  Sun Nov 24 19:07:31 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Nov 2013 18:07:31 +0000
Subject: [New-bugs-announce] [issue19756] test_nntplib: sporadic failures,
	network isses? server down?
Message-ID: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>


New submission from STINNER Victor:

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

======================================================================
ERROR: test_capabilities (test.test_nntplib.NetworkedNNTP_SSLTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_nntplib.py", line 251, in wrapped
    meth(self)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_nntplib.py", line 201, in test_capabilities
    resp, caps = self.server.capabilities()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/nntplib.py", line 558, in capabilities
    resp, lines = self._longcmdstring("CAPABILITIES")
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/nntplib.py", line 525, in _longcmdstring
    resp, list = self._getlongresp(file)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/nntplib.py", line 476, in _getlongresp
    resp = self._getresp()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/nntplib.py", line 449, in _getresp
    resp = self._getline()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/nntplib.py", line 432, in _getline
    line = self.file.readline(_MAXLINE +1)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/socket.py", line 368, in readinto
    raise OSError("cannot read from timed out object")
OSError: cannot read from timed out object



http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.x/builds/7147/steps/test/logs/stdio


======================================================================
ERROR: setUpClass (test.test_nntplib.NetworkedNNTP_SSLTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_nntplib.py", line 298, in setUpClass
    cls.server = cls.NNTP_CLASS(cls.NNTP_HOST, timeout=TIMEOUT, usenetrc=False)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/nntplib.py", line 1071, in __init__
    readermode=readermode, timeout=timeout)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/nntplib.py", line 334, in __init__
    self.getcapabilities()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/nntplib.py", line 390, in getcapabilities
    resp, caps = self.capabilities()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/nntplib.py", line 558, in capabilities
    resp, lines = self._longcmdstring("CAPABILITIES")
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/nntplib.py", line 525, in _longcmdstring
    resp, list = self._getlongresp(file)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/nntplib.py", line 476, in _getlongresp
    resp = self._getresp()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/nntplib.py", line 449, in _getresp
    resp = self._getline()
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/nntplib.py", line 437, in _getline
    if not line: raise EOFError
EOFError

----------
components: Tests
keywords: buildbot
messages: 204248
nosy: haypo
priority: normal
severity: normal
status: open
title: test_nntplib: sporadic failures, network isses? server down?
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 24 19:26:57 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Nov 2013 18:26:57 +0000
Subject: [New-bugs-announce] [issue19757] _tracemalloc.c: compiler warning
	with gil_state
Message-ID: <1385317617.76.0.570657043672.issue19757@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Clang complains that gil_state might be used uninitialized in _tracemalloc.c:488 and 533.

----------
messages: 204254
nosy: christian.heimes, haypo
priority: normal
severity: normal
status: open
title: _tracemalloc.c: compiler warning with gil_state
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 24 22:14:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Nov 2013 21:14:17 +0000
Subject: [New-bugs-announce] [issue19758] Warnings in tests
Message-ID: <1385327657.07.0.59921543232.issue19758@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Following warnings emitted by test suite when run it with -Wall.

[101/387] test_distutils
/home/serhiy/py/cpython/Lib/distutils/sysconfig.py:578: DeprecationWarning: SO is deprecated, use EXT_SUFFIX
  warnings.warn('SO is deprecated, use EXT_SUFFIX', DeprecationWarning)
unknown, 0: Warning: using regular magic file `/etc/magic'
unknown, 0: Warning: using regular magic file `/etc/magic'

[154/387] test_hmac
/home/serhiy/py/cpython/Lib/test/test_hmac.py:271: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h = hmac.HMAC(b"key")
/home/serhiy/py/cpython/Lib/test/test_hmac.py:296: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h = hmac.HMAC(bytearray(b"key"), bytearray(b"hash this!"))
/home/serhiy/py/cpython/Lib/test/test_hmac.py:303: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h = hmac.HMAC(b"key", memoryview(b"hash this!"))
/home/serhiy/py/cpython/Lib/test/test_hmac.py:290: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h = hmac.HMAC(b"key", b"hash this!")
/home/serhiy/py/cpython/Lib/test/test_hmac.py:320: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h = hmac.HMAC(b"key")
/home/serhiy/py/cpython/Lib/test/test_hmac.py:327: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h = hmac.HMAC(b"my secret key")
/home/serhiy/py/cpython/Lib/test/test_hmac.py:339: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h1 = hmac.HMAC(b"key")
/home/serhiy/py/cpython/Lib/test/test_hmac.py:361: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h1 = hmac.HMAC(b"key")
/home/serhiy/py/cpython/Lib/test/test_hmac.py:350: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h1 = hmac.HMAC(b"key")

[165/387] test_importlib
/home/serhiy/py/cpython/Lib/test/test_importlib/test_spec.py:58: PendingDeprecationWarning: The import system now takes care of this automatically.
  @frozen_util.module_for_loader

[245/387] test_poplib
/home/serhiy/py/cpython/Lib/test/support/__init__.py:1331: ResourceWarning: unclosed <ssl.SSLSocket fd=24, family=AddressFamily.AF_INET, type=2049, proto=6, laddr=('127.0.0.1', 36469), raddr=('127.0.0.1', 50929)>
  gc.collect()

[319/387] test_sysconfig
/home/serhiy/py/cpython/Lib/sysconfig.py:588: DeprecationWarning: SO is deprecated, use EXT_SUFFIX
  warnings.warn('SO is deprecated, use EXT_SUFFIX', DeprecationWarning)

----------
components: Tests
messages: 204270
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Warnings in tests
versions: Python 3.4

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

From report at bugs.python.org  Sun Nov 24 23:11:43 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Nov 2013 22:11:43 +0000
Subject: [New-bugs-announce] [issue19759] Deprecation warnings in test_hmac
Message-ID: <1385331103.9.0.931908547844.issue19759@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Following warnings are emitted when test_hmac ran with -Wall:

$ ./python -Wall -m test.regrtest test_hmac
[1/1] test_hmac
/home/serhiy/py/cpython/Lib/test/test_hmac.py:271: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h = hmac.HMAC(b"key")
/home/serhiy/py/cpython/Lib/test/test_hmac.py:296: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h = hmac.HMAC(bytearray(b"key"), bytearray(b"hash this!"))
/home/serhiy/py/cpython/Lib/test/test_hmac.py:303: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h = hmac.HMAC(b"key", memoryview(b"hash this!"))
/home/serhiy/py/cpython/Lib/test/test_hmac.py:290: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h = hmac.HMAC(b"key", b"hash this!")
/home/serhiy/py/cpython/Lib/test/test_hmac.py:320: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h = hmac.HMAC(b"key")
/home/serhiy/py/cpython/Lib/test/test_hmac.py:327: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h = hmac.HMAC(b"my secret key")
/home/serhiy/py/cpython/Lib/test/test_hmac.py:339: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h1 = hmac.HMAC(b"key")
/home/serhiy/py/cpython/Lib/test/test_hmac.py:361: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h1 = hmac.HMAC(b"key")
/home/serhiy/py/cpython/Lib/test/test_hmac.py:350: PendingDeprecationWarning: HMAC() without an explicit digestmod argument is deprecated.
  h1 = hmac.HMAC(b"key")
1 test OK.

The proposed patch silences these warnings.

----------
components: Tests
files: test_hmac_warnings.patch
keywords: patch
messages: 204272
nosy: christian.heimes, gregory.p.smith, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Deprecation warnings in test_hmac
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32824/test_hmac_warnings.patch

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

From report at bugs.python.org  Sun Nov 24 23:13:38 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Nov 2013 22:13:38 +0000
Subject: [New-bugs-announce] [issue19760] Deprecation warnings in
	ttest_sysconfig and	test_distutils
Message-ID: <1385331218.39.0.240436697883.issue19760@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Following warnings are emitted when ttest_sysconfig and test_distutils ran with -Wall:

$ ./python -Wall -m test.regrtest test_sysconfig test_distutils
[1/2] test_sysconfig
/home/serhiy/py/cpython/Lib/sysconfig.py:588: DeprecationWarning: SO is deprecated, use EXT_SUFFIX
  warnings.warn('SO is deprecated, use EXT_SUFFIX', DeprecationWarning)
[2/2] test_distutils
/home/serhiy/py/cpython/Lib/distutils/sysconfig.py:578: DeprecationWarning: SO is deprecated, use EXT_SUFFIX
  warnings.warn('SO is deprecated, use EXT_SUFFIX', DeprecationWarning)
unknown, 0: Warning: using regular magic file `/etc/magic'
unknown, 0: Warning: using regular magic file `/etc/magic'
All 2 tests OK.

The proposed patch silences deprecation warnings. It also changes warning stacklevel for the 'SO' key in sysconfig to 2 so a warning now reports about place where stdlib function is called instead a place in the stdlib.

----------
components: Library (Lib), Tests
files: test_sysconfig_warnings.patch
keywords: patch
messages: 204273
nosy: barry, serhiy.storchaka, tarek
priority: normal
severity: normal
stage: patch review
status: open
title: Deprecation warnings in ttest_sysconfig and test_distutils
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32825/test_sysconfig_warnings.patch

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

From report at bugs.python.org  Mon Nov 25 01:05:35 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 25 Nov 2013 00:05:35 +0000
Subject: [New-bugs-announce] [issue19761] test_tk fails on OS X with
	multiple test case failures	with both Tk 8.5 and 8.4
Message-ID: <1385337935.63.0.262182292505.issue19761@psf.upfronthosting.co.za>


New submission from Ned Deily:

As of 3.4.0b1, the following test failures are observed with Tk 8.5 on OS X (python.org 64-/32- installer with ActiveTcl 8.5.15.1 on OS X 10.9):

======================================================================
FAIL: test_bitmap (tkinter.test.test_tkinter.test_widgets.ButtonTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 240, in test_bitmap
    errmsg='bitmap "spam" not defined')
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 75, in checkInvalidParam
    widget[name] = value
AssertionError: TclError not raised

======================================================================
FAIL: test_bitmap (tkinter.test.test_tkinter.test_widgets.CheckbuttonTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 240, in test_bitmap
    errmsg='bitmap "spam" not defined')
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 75, in checkInvalidParam
    widget[name] = value
AssertionError: TclError not raised

======================================================================
FAIL: test_insertborderwidth (tkinter.test.test_tkinter.test_widgets.EntryTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/test_tkinter/test_widgets.py", line 333, in test_insertborderwidth
    self.checkPixelsParam(widget, 'insertborderwidth', 0, 1.3, -2)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 169, in checkPixelsParam
    conv=conv1, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 59, in checkParam
    self.assertEqual2(widget[name], expected, eq=eq)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 43, in assertEqual2
    self.assertEqual(actual, expected, msg)
AssertionError: 0 != 1

======================================================================
FAIL: test_bitmap (tkinter.test.test_tkinter.test_widgets.LabelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 240, in test_bitmap
    errmsg='bitmap "spam" not defined')
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 75, in checkInvalidParam
    widget[name] = value
AssertionError: TclError not raised

======================================================================
FAIL: test_bitmap (tkinter.test.test_tkinter.test_widgets.MenubuttonTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 240, in test_bitmap
    errmsg='bitmap "spam" not defined')
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 75, in checkInvalidParam
    widget[name] = value
AssertionError: TclError not raised

======================================================================
FAIL: test_bitmap (tkinter.test.test_tkinter.test_widgets.OptionMenuTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 240, in test_bitmap
    errmsg='bitmap "spam" not defined')
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 75, in checkInvalidParam
    widget[name] = value
AssertionError: TclError not raised

======================================================================
FAIL: test_bitmap (tkinter.test.test_tkinter.test_widgets.RadiobuttonTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 240, in test_bitmap
    errmsg='bitmap "spam" not defined')
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 75, in checkInvalidParam
    widget[name] = value
AssertionError: TclError not raised

======================================================================
FAIL: test_insertborderwidth (tkinter.test.test_tkinter.test_widgets.SpinboxTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/test_tkinter/test_widgets.py", line 333, in test_insertborderwidth
    self.checkPixelsParam(widget, 'insertborderwidth', 0, 1.3, -2)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 169, in checkPixelsParam
    conv=conv1, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 59, in checkParam
    self.assertEqual2(widget[name], expected, eq=eq)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 43, in assertEqual2
    self.assertEqual(actual, expected, msg)
AssertionError: 0 != 1

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


The following test failures are observed with Tk 8.4 on OS X (python.org 32-only installer with ActiveTcl 8.4.20 on OS X 10.5.8):

======================================================================
FAIL: test_debug (tkinter.test.test_tkinter.test_text.TextTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/test_tkinter/test_text.py", line 22, in test_debug
    self.assertEqual(text.debug(), 0)
AssertionError: '0' != 0

======================================================================
FAIL: test_insertborderwidth (tkinter.test.test_tkinter.test_widgets.EntryTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/test_tkinter/test_widgets.py", line 333, in test_insertborderwidth
    self.checkPixelsParam(widget, 'insertborderwidth', 0, 1.3, -2)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 169, in checkPixelsParam
    conv=conv1, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 59, in checkParam
    self.assertEqual2(widget[name], expected, eq=eq)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 43, in assertEqual2
    self.assertEqual(actual, expected, msg)
AssertionError: 0 != 1

======================================================================
FAIL: test_insertborderwidth (tkinter.test.test_tkinter.test_widgets.SpinboxTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/test_tkinter/test_widgets.py", line 333, in test_insertborderwidth
    self.checkPixelsParam(widget, 'insertborderwidth', 0, 1.3, -2)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 169, in checkPixelsParam
    conv=conv1, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 59, in checkParam
    self.assertEqual2(widget[name], expected, eq=eq)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/test/widget_tests.py", line 43, in assertEqual2
    self.assertEqual(actual, expected, msg)
AssertionError: 0 != 1

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

----------
components: Tests, Tkinter
messages: 204285
nosy: ned.deily, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: test_tk fails on OS X with multiple test case failures with both Tk 8.5 and 8.4
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 25 05:41:18 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 25 Nov 2013 04:41:18 +0000
Subject: [New-bugs-announce] [issue19762] Incorrect function documentation
	of	_get_object_traceback and _get_traces in _tracemalloc module
Message-ID: <1385354478.04.0.931471819915.issue19762@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

>>> import _tracemalloc
>>> _tracemalloc._get_object_traceback.__doc__
'get_object_traceback(obj)\n\nGet the traceback where the Python object obj was allocated.\nReturn a tuple of (filename: str, lineno: int) tuples.\n\nReturn None if the tracemalloc module is disabled or did not\ntrace the allocation of the object.'
>>> _tracemalloc._get_traces.__doc__
'get_traces() -> list\n\nGet traces of all memory blocks allocated by Python.\nReturn a list of (size: int, traceback: tuple) tuples.\ntraceback is a tuple of (filename: str, lineno: int) tuples.\n\nReturn an empty list if the tracemalloc module is disabled.'

----------
assignee: docs at python
components: Documentation, Extension Modules
files: fix_doc__tracemalloc.patch
keywords: patch
messages: 204293
nosy: docs at python, haypo, vajrasky
priority: normal
severity: normal
status: open
title: Incorrect function documentation of _get_object_traceback and _get_traces in _tracemalloc module
versions: Python 3.4
Added file: http://bugs.python.org/file32827/fix_doc__tracemalloc.patch

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

From report at bugs.python.org  Mon Nov 25 08:31:36 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 25 Nov 2013 07:31:36 +0000
Subject: [New-bugs-announce] [issue19763] Make it easier to backport
	statistics to 2.7
Message-ID: <1385364696.32.0.708082450803.issue19763@psf.upfronthosting.co.za>


New submission from Christian Heimes:

A while ago I created a backport of statistics to Python 2.6 to 3.3. [1] It worked pretty and required just a few modifications to the code. I'd like to add most modifications to 3.4 to simplify backporting.

The modifications are:

* from __future__ import division
* replace super() with super(MySuperClass, self)
* changes to doc tests because Python 2 has slightly different represenstations (<type 'float'> / <class'float'>, longer float repr)
* "import collections" -> "from collections import Counter" so I can simply add a Counter class for 2.6
* "import math" -> "from math import isfinite" so it's easier to add a isfinite() function for 2.x

The patch does neither remove "raise ... from None" nor does it add a 2.x isfinite or range = xrange. The backport still needs some patches but I can keep the amount of changes rather small.

[1] https://bitbucket.org/tiran/backports.statistics

----------
files: statistics_backports.patch
keywords: patch
messages: 204301
nosy: christian.heimes, larry
priority: normal
severity: normal
stage: patch review
status: open
title: Make it easier to backport statistics to 2.7
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32829/statistics_backports.patch

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

From report at bugs.python.org  Mon Nov 25 10:01:55 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Nov 2013 09:01:55 +0000
Subject: [New-bugs-announce] [issue19764] subprocess: use
	PROC_THREAD_ATTRIBUTE_HANDLE_LIST with	STARTUPINFOEX on
	Windows Vista
Message-ID: <1385370115.99.0.757096187315.issue19764@psf.upfronthosting.co.za>


New submission from STINNER Victor:

subprocess.Popen has a race condition on Windows with file descriptors: if two threads spawn subprocesses at the same time, unwanted file descriptors may be inherited, which lead to annoying issues like "cannot delete a file because it is open by another process". For the issue #19575 for an example of such bug.

Since Windows Vista, a list of handle which should be inherited can be specified in CreateProcess() using PROC_THREAD_ATTRIBUTE_HANDLE_LIST with STARTUPINFOEX. It avoids the need to mark the handle temporarly inheritable.

For more information, see:
http://www.python.org/dev/peps/pep-0446/#only-inherit-some-handles-on-windows

----------
messages: 204314
nosy: Bernt.R?skar.Brenna, haypo, sbt
priority: normal
severity: normal
status: open
title: subprocess: use PROC_THREAD_ATTRIBUTE_HANDLE_LIST with STARTUPINFOEX on Windows Vista
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Nov 25 10:29:26 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Nov 2013 09:29:26 +0000
Subject: [New-bugs-announce] [issue19765] test_asyncio: test_create_server()
	failed on "x86	Windows Server 2008 [SB] 3.x"
Message-ID: <1385371766.88.0.569586270438.issue19765@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/x86%20Windows%20Server%202008%20%5BSB%5D%203.x/builds/1794/steps/test/logs/stdio

======================================================================
FAIL: test_create_server (test.test_asyncio.test_events.ProactorEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\test\test_asyncio\test_events.py", line 563, in test_create_server
    self.assertIsInstance(proto, MyProto)
AssertionError: None is not an instance of <class 'test.test_asyncio.test_events.MyProto'>

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

----------
components: Tests
keywords: buildbot
messages: 204315
nosy: gvanrossum, haypo
priority: normal
severity: normal
status: open
title: test_asyncio: test_create_server() failed on "x86 Windows Server 2008 [SB] 3.x"
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 25 10:41:00 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Nov 2013 09:41:00 +0000
Subject: [New-bugs-announce] [issue19766] test_venv: test_with_pip() failed
	on "AMD64 Fedora	without threads 3.x" buildbot
Message-ID: <1385372460.23.0.39838448994.issue19766@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The line "from . import exceptions" of urllib3 failed:
https://github.com/shazow/urllib3/blob/master/urllib3/__init__.py#L22

It is strange because urllib3/exceptions.py is part of the urllib3 module.

http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/5674/steps/test/logs/stdio

======================================================================
FAIL: test_with_pip (test.test_venv.EnsurePipTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/test_venv.py", line 299, in test_with_pip
    self.run_with_capture(venv.create, self.env_dir, with_pip=True)
subprocess.CalledProcessError: Command '['/tmp/tmpd8r2w88y/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/test/test_venv.py", line 305, in test_with_pip
    self.fail(msg)
AssertionError: Command '['/tmp/tmpd8r2w88y/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1

**Subprocess Output**
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/ensurepip/__main__.py", line 66, in <module>
    main()
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/ensurepip/__main__.py", line 61, in main
    default_pip=args.default_pip,
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/ensurepip/__init__.py", line 92, in bootstrap
    _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
  File "/home/buildbot/buildarea/3.x.krah-fedora/build/Lib/ensurepip/__init__.py", line 28, in _run_pip
    import pip
  File "/tmp/tmpwzs5sx88/pip-1.5.rc1-py2.py3-none-any.whl/pip/__init__.py", line 11, in <module>
  File "/tmp/tmpwzs5sx88/pip-1.5.rc1-py2.py3-none-any.whl/pip/vcs/mercurial.py", line 9, in <module>
  File "/tmp/tmpwzs5sx88/pip-1.5.rc1-py2.py3-none-any.whl/pip/download.py", line 22, in <module>
  File "/tmp/tmpwzs5sx88/pip-1.5.rc1-py2.py3-none-any.whl/pip/_vendor/requests/__init__.py", line 58, in <module>
  File "/tmp/tmpwzs5sx88/pip-1.5.rc1-py2.py3-none-any.whl/pip/_vendor/requests/utils.py", line 24, in <module>
  File "/tmp/tmpwzs5sx88/pip-1.5.rc1-py2.py3-none-any.whl/pip/_vendor/requests/compat.py", line 7, in <module>
  File "/tmp/tmpwzs5sx88/pip-1.5.rc1-py2.py3-none-any.whl/pip/_vendor/requests/packages/__init__.py", line 3, in <module>
  File "/tmp/tmpwzs5sx88/pip-1.5.rc1-py2.py3-none-any.whl/pip/_vendor/requests/packages/urllib3/__init__.py", line 22, in <module>
ImportError: cannot import name 'exceptions'

----------
components: Tests
keywords: buildbot
messages: 204316
nosy: haypo
priority: normal
severity: normal
status: open
title: test_venv: test_with_pip() failed on "AMD64 Fedora without threads 3.x" buildbot
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 25 11:25:47 2013
From: report at bugs.python.org (Jonas H.)
Date: Mon, 25 Nov 2013 10:25:47 +0000
Subject: [New-bugs-announce] [issue19767] pathlib: iterfiles() and iterdirs()
Message-ID: <1385375147.52.0.820545347485.issue19767@psf.upfronthosting.co.za>


New submission from Jonas H.:

>From my personal experience, listing all real files and all subdirectories in a directory is a very common use case.

Here's a patch that adds the `iterfiles()` and `iterdirs()` methods as a shortcut for `[f for f in p.iterdir() if f.is_dir/file()]` .

----------
components: Library (Lib)
files: iterdirs_iterfiles.diff
keywords: patch
messages: 204320
nosy: jonash
priority: normal
severity: normal
status: open
title: pathlib: iterfiles() and iterdirs()
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32832/iterdirs_iterfiles.diff

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

From report at bugs.python.org  Mon Nov 25 11:29:50 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 25 Nov 2013 10:29:50 +0000
Subject: [New-bugs-announce] [issue19768] Not so correct error message when
	giving incorrect type	to maxlen in deque
Message-ID: <1385375390.08.0.216334193444.issue19768@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

>>> from collections import deque
>>> deque('abc', maxlen='a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required

But it's a lie. You can give None to maxlen
>>> deque('abc', maxlen=None)
deque(['a', 'b', 'c'])

maxlen with None value means unlimited.

You can give boolean value too to maxlen.

>>> deque('abc', maxlen=True)
deque(['c'], maxlen=1)

But since we use boolean and integer interchangeably in Python, so this should not matter in this case.

So, after the patch:
>>> deque('abc', maxlen='a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: maxlen must be integer or None

Don't worry, I only overrode the TypeError one. So overflow error should be kept intact.

>>> deque('abc', maxlen=2**68)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C ssize_t

I did not override the negative integer error message, because I assume when people give negative integer, they are in the mindset of giving integer value to maxlen.

>>> deque('abc', maxlen=-3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: maxlen must be non-negative

----------
components: Extension Modules
files: fix_error_message_maxlen_deque.patch
keywords: patch
messages: 204321
nosy: rhettinger, vajrasky
priority: normal
severity: normal
status: open
title: Not so correct error message when giving incorrect type to maxlen in deque
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32833/fix_error_message_maxlen_deque.patch

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

From report at bugs.python.org  Mon Nov 25 12:30:05 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Nov 2013 11:30:05 +0000
Subject: [New-bugs-announce] [issue19769] test_venv: test_with_pip() failure
	on "AMD64 Windows	Server 2008 [SB] 3.x" buildbot
Message-ID: <1385379005.22.0.834841842674.issue19769@psf.upfronthosting.co.za>


New submission from STINNER Victor:

This issue looks like issue #19734, but I'm not sure, so I prefer to open a new issue. Don't hesitate to close it as a duplicate of it's the same.

http://buildbot.python.org/all/builders/AMD64%20Windows%20Server%202008%20%5BSB%5D%203.x/builds/1752/steps/test/logs/stdio

test_with_pip (test.test_venv.EnsurePipTest) ... FAIL

======================================================================
FAIL: test_with_pip (test.test_venv.EnsurePipTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\home\cpython\buildslave\x64\3.x.snakebite-win2k8r2sp1-amd64\build\lib\test\test_venv.py", line 314, in test_with_pip
    self.assertEqual(err, "")
AssertionError: "C:\\Users\\BUILDS~1\\AppData\\Local\\Tem[138 chars]\r\n" != ''
- C:\Users\BUILDS~1\AppData\Local\Temp\tmpa0ocjb9d\Scripts\python_d.exe: No module named 'pip._vendor.requests.adapters'; 'pip' is a package and cannot be directly executed

----------
components: Tests
keywords: buildbot
messages: 204325
nosy: haypo, ncoghlan
priority: normal
severity: normal
status: open
title: test_venv: test_with_pip() failure on "AMD64 Windows Server 2008 [SB] 3.x" buildbot

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

From report at bugs.python.org  Mon Nov 25 13:28:44 2013
From: report at bugs.python.org (Szymon Sobik)
Date: Mon, 25 Nov 2013 12:28:44 +0000
Subject: [New-bugs-announce] [issue19770] NNTP.post broken
Message-ID: <1385382524.39.0.481766399265.issue19770@psf.upfronthosting.co.za>


New submission from Szymon Sobik:

post method fails because string methods have bytesrting arguments

ie.
line = line.rstrip(b"\r\n") + _CRLF

----------
components: Library (Lib)
messages: 204331
nosy: sobczyk
priority: normal
severity: normal
status: open
title: NNTP.post broken
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Nov 25 13:39:47 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 25 Nov 2013 12:39:47 +0000
Subject: [New-bugs-announce] [issue19771] runpy should check
	ImportError.name before wrapping it
Message-ID: <1385383187.11.0.803942496087.issue19771@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Issue 19769 shows that if __main__ in a package throws ImportError, runpy will incorrectly report the package as not being directly executable (when it actually claims to be executable, it's just broken)

This can be fixed in 3.3+ by checking for an appropriate value in the name attribute of the caught exception, and only wrapping it if the failed lookup was for the __main__ submodule we're looking for.

The associated test can just use a __main__.py that deliberately raises ImportError.

----------
components: Library (Lib)
keywords: easy
messages: 204334
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: runpy should check ImportError.name before wrapping it
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Nov 25 17:14:11 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Nov 2013 16:14:11 +0000
Subject: [New-bugs-announce] [issue19772] str serialization of Message
	object may mutate the	payload and CTE.
Message-ID: <1385396051.26.0.384603344718.issue19772@psf.upfronthosting.co.za>


New submission from R. David Murray:

Currently the string generator will downcast 8bit body parts to 7bit by encoding them using a 7bit CTE.  This is good.  However, the way it does it is to modify the Message object accordingly.  This is not good.  Except for filling in required missing bits of data (such as MIME borders), serializing a Message should not mutate it.  (And, for the curious, I am the one who made this mistake when I wrote the code :)

----------
components: Library (Lib), email
keywords: easy
messages: 204356
nosy: barry, r.david.murray, vajrasky
priority: normal
severity: normal
stage: needs patch
status: open
title: str serialization of Message object may mutate the payload and CTE.
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Nov 25 17:42:54 2013
From: report at bugs.python.org (lambrecht)
Date: Mon, 25 Nov 2013 16:42:54 +0000
Subject: [New-bugs-announce] [issue19773] Failed to build python 2.6.9
	Solaris 10
Message-ID: <1385397774.16.0.00982923688333.issue19773@psf.upfronthosting.co.za>


New submission from lambrecht:

u1662805 at methpr:/home/u1662805>echo $PATH
/usr/sbin:/usr/bin:/usr/local/bin:/etc:/EXP_SYS/etc/ga/scripts:/EXP_SYS/etc:/EXP_SYS/UTI:/METHPR/EXP_SYS/etc:/METHPR/EXP_SYS/uti:/opt/VRTSvxfs/sbin:/EXP_SYS/etc/ga/scripts:/usr/openwin/bin:/usr/ccs/bin
u1662805 at methpr:/home/u1662805>make
running build
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
building '_ssl' extension
gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/usr/local/ssl/include -I. -I/METHPR/tmp/Python-2.6.9/./Include -I. -I/METHPR/tmp/Python-2.6.9/./Include -I. -IInclude -I./Include -I/usr/local/include -I/METHPR/tmp/Python-2.6.9/Include -I/METHPR/tmp/Python-2.6.9 -c /METHPR/tmp/Python-2.6.9/Modules/_ssl.c -o build/temp.solaris-2.10-sun4v-2.6/METHPR/tmp/Python-2.6.9/Modules/_ssl.o
/METHPR/tmp/Python-2.6.9/Modules/_ssl.c: In function `_get_peer_alt_names':
/METHPR/tmp/Python-2.6.9/Modules/_ssl.c:702: warning: assignment discards qualifiers from pointer target type
/METHPR/tmp/Python-2.6.9/Modules/_ssl.c: In function `PySSL_cipher':
/METHPR/tmp/Python-2.6.9/Modules/_ssl.c:1095: warning: assignment discards qualifiers from pointer target type
gcc -shared build/temp.solaris-2.10-sun4v-2.6/METHPR/tmp/Python-2.6.9/Modules/_ssl.o -L/usr/local/ssl/lib -L/usr/local/lib -lssl -lcrypto -o build/lib.solaris-2.10-sun4v-2.6/_ssl.so
*** WARNING: renaming "_ssl" since importing it failed: ld.so.1: python: fatal: libssl.so.1.0.0: open failed: No such file or directory
building '_hashlib' extension
gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/usr/local/ssl/include -I. -I/METHPR/tmp/Python-2.6.9/./Include -I. -I/METHPR/tmp/Python-2.6.9/./Include -I. -IInclude -I./Include -I/usr/local/include -I/METHPR/tmp/Python-2.6.9/Include -I/METHPR/tmp/Python-2.6.9 -c /METHPR/tmp/Python-2.6.9/Modules/_hashopenssl.c -o build/temp.solaris-2.10-sun4v-2.6/METHPR/tmp/Python-2.6.9/Modules/_hashopenssl.o
gcc -shared build/temp.solaris-2.10-sun4v-2.6/METHPR/tmp/Python-2.6.9/Modules/_hashopenssl.o -L/usr/local/ssl/lib -L/usr/local/lib -lssl -lcrypto -o build/lib.solaris-2.10-sun4v-2.6/_hashlib.so
*** WARNING: renaming "_hashlib" since importing it failed: ld.so.1: python: fatal: libssl.so.1.0.0: open failed: No such file or directory
building '_curses' extension
gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/METHPR/tmp/Python-2.6.9/./Include -I. -IInclude -I./Include -I/usr/local/include -I/METHPR/tmp/Python-2.6.9/Include -I/METHPR/tmp/Python-2.6.9 -c /METHPR/tmp/Python-2.6.9/Modules/_cursesmodule.c -o build/temp.solaris-2.10-sun4v-2.6/METHPR/tmp/Python-2.6.9/Modules/_cursesmodule.o
/METHPR/tmp/Python-2.6.9/Modules/_cursesmodule.c: In function `PyCursesWindow_ChgAt':
/METHPR/tmp/Python-2.6.9/Modules/_cursesmodule.c:708: warning: implicit declaration of function `mvwchgat'
/METHPR/tmp/Python-2.6.9/Modules/_cursesmodule.c:712: warning: implicit declaration of function `wchgat'
gcc -shared build/temp.solaris-2.10-sun4v-2.6/METHPR/tmp/Python-2.6.9/Modules/_cursesmodule.o -L/usr/local/lib -lncurses -o build/lib.solaris-2.10-sun4v-2.6/_curses.so
*** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: fatal: relocation error: file build/lib.solaris-2.10-sun4v-2.6/_curses.so: symbol _unctrl: referenced symbol not found
building '_curses_panel' extension
gcc -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -I/METHPR/tmp/Python-2.6.9/./Include -I. -IInclude -I./Include -I/usr/local/include -I/METHPR/tmp/Python-2.6.9/Include -I/METHPR/tmp/Python-2.6.9 -c /METHPR/tmp/Python-2.6.9/Modules/_curses_panel.c -o build/temp.solaris-2.10-sun4v-2.6/METHPR/tmp/Python-2.6.9/Modules/_curses_panel.o
gcc -shared build/temp.solaris-2.10-sun4v-2.6/METHPR/tmp/Python-2.6.9/Modules/_curses_panel.o -L/usr/local/lib -lpanel -lncurses -o build/lib.solaris-2.10-sun4v-2.6/_curses_panel.so
*** WARNING: renaming "_curses_panel" since importing it failed: No module named _curses

Failed to find the necessary bits to build these modules:
_bsddb             _tkinter           bsddb185
gdbm               linuxaudiodev      ossaudiodev
To find the necessary bits, look in setup.py in detect_modules() for the module's name.


Failed to build these modules:
_curses            _curses_panel      _hashlib
_ssl

running build_scripts

----------
components: Build
messages: 204359
nosy: lambrechtphilippe
priority: normal
severity: normal
status: open
title: Failed to build python 2.6.9 Solaris 10
versions: Python 2.6

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

From report at bugs.python.org  Mon Nov 25 20:23:05 2013
From: report at bugs.python.org (Steve J Borba)
Date: Mon, 25 Nov 2013 19:23:05 +0000
Subject: [New-bugs-announce] [issue19774] strptime incorrect for weekday '0'
	when using week	number format
Message-ID: <1385407385.23.0.963319097072.issue19774@psf.upfronthosting.co.za>


New submission from Steve J Borba:

OS: Windows 7 Professional (64-bit)
Hardware: Intel

datetime.strptime returns an incorrect value when calculating a date using a week number format, such as "%Y-%W-%w" (Year-Week-Weekday). The value returned for weekday '0' of a given week is consistently 7 days greater than it should be. The following code illustrates:

from datetime import datetime
for i in range(0,53):
    if i == 0:
        yr=input("Enter a valid year: ")
        print("Wk#\tBeginning of week\tEnd of week")
    BegWk = datetime.strptime((yr + "-" + str(i) + "-0"),"%Y-%W-%w")
    EndWk = datetime.strptime((yr + "-" + str(i) + "-6"),"%Y-%W-%w")
    print(str(i) + "\t" + str(BegWk) + "\t" +str(EndWk))

Here is a clip (7 lines) of the output from the code above:
Enter a valid year: 2013
Wk#	Beginning of week	End of week
0	2013-01-06 00:00:00	2013-01-05 00:00:00
1	2013-01-13 00:00:00	2013-01-12 00:00:00
2	2013-01-20 00:00:00	2013-01-19 00:00:00
3	2013-01-27 00:00:00	2013-01-26 00:00:00
4	2013-02-03 00:00:00	2013-02-02 00:00:00
5	2013-02-10 00:00:00	2013-02-09 00:00:00
6	2013-02-17 00:00:00	2013-02-16 00:00:00

The value returned for the first column of each week is exactly 7 days higher than the correct result.

----------
components: Library (Lib)
messages: 204382
nosy: Steve.J.Borba
priority: normal
severity: normal
status: open
title: strptime incorrect for weekday '0' when using week number format
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Nov 25 20:48:21 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Nov 2013 19:48:21 +0000
Subject: [New-bugs-announce] [issue19775] Provide samefile() on Path objects
Message-ID: <1385408901.26.0.705019475145.issue19775@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

It would probably be useful to provide samefile() on Path objects - basically doing the same thing as os.path.samefile().

----------
components: Library (Lib)
messages: 204386
nosy: pitrou
priority: normal
severity: normal
status: open
title: Provide samefile() on Path objects
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Nov 25 21:02:58 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Nov 2013 20:02:58 +0000
Subject: [New-bugs-announce] [issue19776] Provide expanduser() on Path
	objects
Message-ID: <1385409778.55.0.842571848249.issue19776@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Something like expanduser() may be useful on Path objects.

----------
components: Library (Lib)
messages: 204387
nosy: pitrou
priority: low
severity: normal
status: open
title: Provide expanduser() on Path objects
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Nov 25 21:04:23 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Nov 2013 20:04:23 +0000
Subject: [New-bugs-announce] [issue19777] Provide a home() classmethod on
	Path objects
Message-ID: <1385409863.35.0.0114355564026.issue19777@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Similar to Path.cwd(), perhaps a Path.home() to create a new Path object pointing to the current user's home directory may be useful.

----------
components: Library (Lib)
messages: 204388
nosy: pitrou
priority: low
severity: normal
status: open
title: Provide a home() classmethod on Path objects
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Nov 25 21:37:16 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Mon, 25 Nov 2013 20:37:16 +0000
Subject: [New-bugs-announce] [issue19778] Change re.compile display
Message-ID: <1385411836.14.0.1819060635.issue19778@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Hello. I attached a minimal patch which fixes the re.compile display in documentation, after issue13592 was closed.

----------
assignee: docs at python
components: Documentation
files: sre_re.patch
keywords: patch
messages: 204402
nosy: Claudiu.Popa, docs at python, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Change re.compile display
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32841/sre_re.patch

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

From report at bugs.python.org  Mon Nov 25 22:36:19 2013
From: report at bugs.python.org (Tim Peters)
Date: Mon, 25 Nov 2013 21:36:19 +0000
Subject: [New-bugs-announce] [issue19779] test_concurrent_futures crashes on
	32-bit Windows Vista
Message-ID: <1385415379.8.0.787528986127.issue19779@psf.upfronthosting.co.za>


New submission from Tim Peters:

Worked OK yesterday, using current default branch in all cases.

C:\Code\Python\PCbuild>.\\python_d  -Wd -E -bb ../lib/test/regrtest.py test_concurrent_futures
[1/1] test_concurrent_futures
Fatal Python error: Segmentation fault

Current thread 0x00000590 (most recent call first):
  File "<frozen importlib._bootstrap>", line 882 in spec_from_file_location
  File "<frozen importlib._bootstrap>", line 1930 in _get_spec
  File "<frozen importlib._bootstrap>", line 1971 in find_spec
  File "<frozen importlib._bootstrap>", line 1834 in _get_spec
  File "<frozen importlib._bootstrap>", line 1860 in find_spec
  File "<frozen importlib._bootstrap>", line 2074 in _find_spec
  File "<frozen importlib._bootstrap>", line 2132 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 2147 in _find_and_load
  File "<frozen importlib._bootstrap>", line 303 in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 2194 in _handle_fromlist
  File "C:\Code\Python\lib\multiprocessing\popen_spawn_win32.py", line 8 in <module>
  File "<frozen importlib._bootstrap>", line 303 in _call_with_frames_removed
  File "<frozen importlib._bootstrap>", line 1422 in exec_module
  File "<frozen importlib._bootstrap>", line 1111 in _exec
  File "<frozen importlib._bootstrap>", line 1187 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 2136 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 2147 in _find_and_load
  File "C:\Code\Python\lib\multiprocessing\context.py", line 312 in _Popen
  File "C:\Code\Python\lib\multiprocessing\context.py", line 212 in _Popen
  File "C:\Code\Python\lib\multiprocessing\process.py", line 105 in start
  File "C:\Code\Python\lib\concurrent\futures\process.py", line 387 in _adjust_process_count
  File "C:\Code\Python\lib\concurrent\futures\process.py", line 368 in _start_queue_management_thread
  File "C:\Code\Python\lib\concurrent\futures\process.py", line 407 in submit
  File "C:\Code\Python\lib\test\test_concurrent_futures.py", line 83 in <listcomp>
  File "C:\Code\Python\lib\test\test_concurrent_futures.py", line 83 in _prime_executor
  File "C:\Code\Python\lib\test\test_concurrent_futures.py", line 70 in setUp
  File "C:\Code\Python\lib\unittest\case.py", line 567 in run
  File "C:\Code\Python\lib\unittest\case.py", line 610 in __call__
  File "C:\Code\Python\lib\unittest\suite.py", line 117 in run
  File "C:\Code\Python\lib\unittest\suite.py", line 79 in __call__
  File "C:\Code\Python\lib\unittest\suite.py", line 117 in run
  File "C:\Code\Python\lib\unittest\suite.py", line 79 in __call__
  File "C:\Code\Python\lib\unittest\suite.py", line 117 in run
  File "C:\Code\Python\lib\unittest\suite.py", line 79 in __call__
  File "C:\Code\Python\lib\test\support\__init__.py", line 1584 in run
  File "C:\Code\Python\lib\test\support\__init__.py", line 1685 in _run_suite
  File "C:\Code\Python\lib\test\support\__init__.py", line 1719 in run_unittest
  File "C:\Code\Python\lib\test\test_concurrent_futures.py", line 673 in test_main
  File "C:\Code\Python\lib\test\support\__init__.py", line 1831 in decorator
  File "../lib/test/regrtest.py", line 1278 in runtest_inner
  File "../lib/test/regrtest.py", line 978 in runtest
  File "../lib/test/regrtest.py", line 763 in main
  File "../lib/test/regrtest.py", line 1562 in main_in_temp_cwd
  File "../lib/test/regrtest.py", line 1587 in <module>

Running with -v suggests it's dying in test_submit_keyword:

...
test_no_stale_references (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 0.88s ok
test_shutdown_race_issue12456 (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 0.88s ok
test_submit (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 0.88s ok
test_submit_keyword (test.test_concurrent_futures.ProcessPoolExecutorTest) ...

And then a box pops up complaining that python_d stopped working.

----------
messages: 204418
nosy: tim.peters
priority: normal
severity: normal
status: open
title: test_concurrent_futures crashes on 32-bit Windows Vista
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 25 22:55:09 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Nov 2013 21:55:09 +0000
Subject: [New-bugs-announce] [issue19780] Pickle 4 frame headers optimization
Message-ID: <1385416509.02.0.493465582704.issue19780@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which restores (removed at last moment before 3.4beta1 release) frame headers optimization for the pickle protocol 4. Frame header now saved as a part of previous frame. This decreases the number of unbuffered reads per frame from 3 to 1.

----------
components: Library (Lib)
files: pickle_frame_headers.patch
keywords: patch
messages: 204424
nosy: alexandre.vassalotti, larry, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Pickle 4 frame headers optimization
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file32843/pickle_frame_headers.patch

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

From report at bugs.python.org  Tue Nov 26 00:44:23 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 25 Nov 2013 23:44:23 +0000
Subject: [New-bugs-announce] [issue19781] No SSL match_hostname() in ftplib
Message-ID: <1385423063.98.0.532680357118.issue19781@psf.upfronthosting.co.za>


New submission from Christian Heimes:

match_hostname patch for ftplib (see #19509)

----------
files: check_ftplib.patch
keywords: patch
messages: 204433
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: No SSL match_hostname() in ftplib
type: security
versions: Python 3.4
Added file: http://bugs.python.org/file32844/check_ftplib.patch

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

From report at bugs.python.org  Tue Nov 26 00:45:28 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 25 Nov 2013 23:45:28 +0000
Subject: [New-bugs-announce] [issue19782] No SSL match_hostname() in imaplib
Message-ID: <1385423128.55.0.373615853043.issue19782@psf.upfronthosting.co.za>


New submission from Christian Heimes:

match_hostname patch for imaplib (see #19509). The patch doesn't have tests yet.

----------
components: Library (Lib)
messages: 204434
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: No SSL match_hostname() in imaplib
type: security
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 26 00:46:48 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 25 Nov 2013 23:46:48 +0000
Subject: [New-bugs-announce] [issue19783] No SSL match_hostname() in nntplib
Message-ID: <1385423208.98.0.59627306788.issue19783@psf.upfronthosting.co.za>


New submission from Christian Heimes:

match_hostname patch for nntplib (see #19509). The patch doesn't have tests yet.

----------
components: Library (Lib)
files: check_nntplib.patch
keywords: patch
messages: 204436
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: No SSL match_hostname() in nntplib
type: security
versions: Python 3.4
Added file: http://bugs.python.org/file32846/check_nntplib.patch

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

From report at bugs.python.org  Tue Nov 26 00:47:27 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 25 Nov 2013 23:47:27 +0000
Subject: [New-bugs-announce] [issue19784] No SSL match_hostname() in poplib
Message-ID: <1385423247.18.0.333542654641.issue19784@psf.upfronthosting.co.za>


New submission from Christian Heimes:

match_hostname patch for poplib (see #19509). The patch doesn't have tests yet.

----------
components: Library (Lib)
files: check_poplib.patch
keywords: patch
messages: 204437
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: No SSL match_hostname() in poplib
type: security
versions: Python 3.4
Added file: http://bugs.python.org/file32847/check_poplib.patch

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

From report at bugs.python.org  Tue Nov 26 00:47:59 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 25 Nov 2013 23:47:59 +0000
Subject: [New-bugs-announce] [issue19785] No SSL match_hostname() in smtplib
Message-ID: <1385423279.73.0.0929925715399.issue19785@psf.upfronthosting.co.za>


New submission from Christian Heimes:

match_hostname patch for smtplib (see #19509). The patch doesn't have tests yet.

----------
components: Library (Lib)
messages: 204438
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: No SSL match_hostname() in smtplib
type: security
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 26 00:49:46 2013
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Nov 2013 23:49:46 +0000
Subject: [New-bugs-announce] [issue19786] tracemalloc: remove arbitrary
	limit of 100 frames
Message-ID: <1385423386.94.0.320211351923.issue19786@psf.upfronthosting.co.za>


New submission from STINNER Victor:

It should be possible to collect more than 100 frames per traceback (even it is much slower and uses much more memory).

I prepared the code to make it possible. Now only one thread should call traceback_new() at the same time, and the maximum number of frames is fixed while tracemalloc is tracing.

I will work on a patch.

----------
messages: 204440
nosy: haypo
priority: normal
severity: normal
status: open
title: tracemalloc: remove arbitrary limit of 100 frames
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 26 01:13:57 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Nov 2013 00:13:57 +0000
Subject: [New-bugs-announce] [issue19787] tracemalloc: set_reentrant()
	should not have to call	PyThread_delete_key()
Message-ID: <1385424837.9.0.232178819972.issue19787@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The tracemalloc module uses PyThread_set_key_value() to store an flag in the Thread Local Storage. The problem is that it is not possible to call the function twice with two different values. If PyThread_set_key_value() is called with a non-NULL pointer, the next calls do nothing.

Python should expose a new function which would always call TlsSetValue() / pthread_setspecific() with the input value with no extra check on the input value.

----------
messages: 204442
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: tracemalloc: set_reentrant() should not have to call PyThread_delete_key()
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 26 05:45:31 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 26 Nov 2013 04:45:31 +0000
Subject: [New-bugs-announce] [issue19788] Always run kill_python(_d).exe
	when (re-)building on	Windows
Message-ID: <1385441131.37.0.761786658191.issue19788@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The attached patch turns running kill_python(_d).exe into a PreBuildEvent in pythoncore.vcxproj.  This should guarantee that kill_python(_d).exe is always run to guarantee no zombie pythons in the background can prevent overwriting the Python dll.  The pythoncore project already depends on the kill_python project, so kill_python should always be built and ready before this PreBuildEvent fires.  The patch also removes the separate building and running of kill_python_d.exe from the buildbot build scripts, since it should be unnecessary with the patch to pythoncore.vcxproj.

Tim Peters, this patch was partly inspired by your issues in #19779; I suspect that perhaps your rebuild didn't take due to the segfaulted interpreter still hanging around in the background since the same thing happened to me doing a rebuild from the command line.  Would you mind testing this patch to see if it would have helped in your case?  Steps to test should be something like:

- update to e39db21df580
- build, run test_concurrent_futures (expect segfault)
- update to default
- rebuild, run test_concurrent_futures (expect build error and segfault again)
- apply patch
- rebuild, run test_concurrent_futures (expect success (or usual result))

----------
components: Build, Windows
files: kill_python_prebuild.diff
keywords: patch
messages: 204448
nosy: brian.curtin, tim.golden, tim.peters, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Always run kill_python(_d).exe when (re-)building on Windows
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32848/kill_python_prebuild.diff

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

From report at bugs.python.org  Tue Nov 26 06:14:20 2013
From: report at bugs.python.org (Simon Weber)
Date: Tue, 26 Nov 2013 05:14:20 +0000
Subject: [New-bugs-announce] [issue19789] Improve wording of how to "undo" a
	call to	logging.disable(lvl)
Message-ID: <1385442860.38.0.88263802784.issue19789@psf.upfronthosting.co.za>


New submission from Simon Weber:

In http://bugs.python.org/issue14864, this line was added to the logging.disable docstring:

To undo the effect of a call to logging.disable(lvl), call logging.disable(logging.NOTSET).

To prevent misunderstanding, I propose that this line be changed to:

Calling logging.disable(logging.NOTSET) will undo all previous calls to logging.disable(lvl).


While the original change was an improvement, it's misleading. "undoing the effect of a call" reads as "undoing the effect of the last call", which implies a stack -- think of text editor "undo" functionality. In other words, the current documentation implies behavior like a context manager:

>>> import logging
# start with all logging enabled

>>> logging.disable(logging.CRITICAL)
#     all logging disabled

>>> logging.disable(logging.WARNING)
#         only CRITICAL enabled

>>> logging.disable(logging.NOTSET)
#     undo; all logging disabled

>>> logging.disable(logging.NOTSET)
# undo; all logging enabled

Since logging.disable is idempotent, we're not undoing *a call*, we're undoing *all calls*.

----------
assignee: docs at python
components: Documentation
messages: 204451
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, simonmweber
priority: normal
severity: normal
status: open
title: Improve wording of how to "undo" a call to logging.disable(lvl)
type: enhancement

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

From report at bugs.python.org  Tue Nov 26 07:38:32 2013
From: report at bugs.python.org (yinkaisheng)
Date: Tue, 26 Nov 2013 06:38:32 +0000
Subject: [New-bugs-announce] [issue19790] ctypes can't load a c++ dll if the
	dll calls COM on	Windows 8
Message-ID: <1385447912.09.0.00620803320142.issue19790@psf.upfronthosting.co.za>


New submission from yinkaisheng:

I created a c++ dll project that calls COM.
cyptes works well with the dll on Windows XP(SP3) and Windows 7.
But it can't load the dll on windows 8. 
The function ctypes.cdll.LoadLibrary doesn't return when I call it to load the dll on Windows 8.

The version of my Python is 2.7.6
The version of my Windows 8 is 6.2.9200.16384

I uploaded a sample dll project created by VS2012 as the attachment.
Here are the c++ codes

// dllmain.cpp :
#include "stdafx.h"
#include <Windows.h>

#include <UIAutomation.h>
IUIAutomation *g_pAutomation = NULL;

#define DLL_EXPORT __declspec(dllexport)

BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
					 )
{
	switch (ul_reason_for_call)
	{
	case DLL_PROCESS_ATTACH:
		{
			if (NULL == g_pAutomation)
			{
				CoInitialize(NULL);
				HRESULT hr = CoCreateInstance(__uuidof(CUIAutomation), NULL, CLSCTX_INPROC_SERVER, __uuidof(IUIAutomation), (void**)&g_pAutomation);
			}
			break;
		}
	case DLL_THREAD_ATTACH:
		{
			break;
		}
	case DLL_THREAD_DETACH:
		{
			break;
		}
	case DLL_PROCESS_DETACH:
		{
			if (g_pAutomation)
			{
				g_pAutomation->Release();
				CoUninitialize();
			}
			break;
		}
	}
	return TRUE;
}


#ifdef __cplusplus
extern "C"
{
#endif

	DLL_EXPORT int AddTwoNumber(int a, int b)
	{
		return a + b;
	}

#ifdef __cplusplus
}
#endif

----------
components: ctypes
files: TestDll.rar
messages: 204454
nosy: yinkaisheng
priority: normal
severity: normal
status: open
title: ctypes can't load a c++ dll if the dll calls COM on Windows 8
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file32849/TestDll.rar

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

From report at bugs.python.org  Tue Nov 26 08:03:08 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 26 Nov 2013 07:03:08 +0000
Subject: [New-bugs-announce] [issue19791] test_pathlib should use
	can_symlink or	skip_unless_symlink from test.support
Message-ID: <1385449388.05.0.507393772442.issue19791@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

Right now, Lib/test/test_pathlib.py uses custom checking symbolic link function. But in test.support, we have those functions already (can_symlink and skip_unless_symlink). The only feature that test.support checking symbolic link functions don't have is getting the reason why we don't have symbolic link support. But we can create a separate ticket to add that feature in test.support.

Attached the patch to use can_symlink and skip_unless_symlink. It also removed unnecessary import.

----------
components: Tests
files: use_can_symlink_from_test_support.patch
keywords: patch
messages: 204456
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: test_pathlib should use can_symlink or skip_unless_symlink from test.support
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32850/use_can_symlink_from_test_support.patch

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

From report at bugs.python.org  Tue Nov 26 08:43:34 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Tue, 26 Nov 2013 07:43:34 +0000
Subject: [New-bugs-announce] [issue19792] pathlib does not support symlink
	in Windows XP
Message-ID: <1385451814.33.0.666998936425.issue19792@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

In Lib/pathlib.py, we got this "problematic" code:

     if sys.getwindowsversion()[:2] >= (6, 0):
         from nt import _getfinalpathname
     else:
         supports_symlinks = False
         _getfinalpathname = None

This code means if the windows version is less than Windows NT 6, then we disable symlink support.

http://en.wikipedia.org/wiki/Windows_NT_6.0

Windows NT 6.0 includes Vista, Server 2008. In other word, Windows XP is less than Windows NT 6.0.

Actually, we can add symbolic link support for Windows XP.
http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html#symboliclinksforwindowsxp

Attached the patch to add symbolic link support for Windows XP in pathlib.

Actually, if this ticket is made invalid, I don't care anyway. Windows XP will "die" on 8th April 2014.

http://windows.microsoft.com/en-us/windows/end-support-help

Also, how many people uses pathlib in Python 3.4 in Windows XP with third-party drivers enabling symbolic link support? Should be small.

I am interested in this problem because I have the same problem in Django.
https://code.djangoproject.com/ticket/21482
On the proposed pull request, I let the os.symlink takes care whether we have symbolic link support or not.

But I may "copy" Antoine's approach to Django's bug.

----------
components: Library (Lib)
files: add_symlink_support_for_windows_xp.patch
keywords: patch
messages: 204458
nosy: pitrou, vajrasky
priority: normal
severity: normal
status: open
title: pathlib does not support symlink in Windows XP
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32851/add_symlink_support_for_windows_xp.patch

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

From report at bugs.python.org  Tue Nov 26 10:05:49 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Nov 2013 09:05:49 +0000
Subject: [New-bugs-announce] [issue19793] Formatting of True/Falsein in
	pathlib docs
Message-ID: <1385456749.57.0.871940933045.issue19793@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch improves formatting of True/False in pathlib documentation. "True" becomes "``True``" if it means True constant and "true" if it means true value.

----------
assignee: docs at python
components: Documentation
messages: 204461
nosy: chris.jerdonek, docs at python, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Formatting of True/Falsein in pathlib docs
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 26 10:10:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Nov 2013 09:10:07 +0000
Subject: [New-bugs-announce] [issue19794] Formatting of True/False in
	decimal docs
Message-ID: <1385457007.96.0.784815460487.issue19794@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch improves formatting of True/False in decimal documentation. "True/False" constants become "``True``/``False``".

----------
assignee: docs at python
components: Documentation
files: doc_decimal_truefalse.patch
keywords: patch
messages: 204462
nosy: docs at python, facundobatista, mark.dickinson, rhettinger, serhiy.storchaka, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Formatting of True/False in decimal docs
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32853/doc_decimal_truefalse.patch

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

From report at bugs.python.org  Tue Nov 26 10:18:45 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Nov 2013 09:18:45 +0000
Subject: [New-bugs-announce] [issue19795] Formatting of True/False in docs
Message-ID: <1385457525.93.0.980812903017.issue19795@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch improves formatting of True/False in the documentation. "True" becomes "``True``" if it means True constant and "true" if it means true value (in input arguments).

See also issue19793 and issue19794.

----------
assignee: docs at python
components: Documentation
files: doc_truefalse.patch
keywords: patch
messages: 204463
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Formatting of True/False in docs
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file32854/doc_truefalse.patch

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

From report at bugs.python.org  Tue Nov 26 10:59:18 2013
From: report at bugs.python.org (Alex Willmer)
Date: Tue, 26 Nov 2013 09:59:18 +0000
Subject: [New-bugs-announce] [issue19796] urllib2.HTTPError.reason is not
	documented as "Added in	2.7"
Message-ID: <1385459958.78.0.648544615764.issue19796@psf.upfronthosting.co.za>


New submission from Alex Willmer:

issue13211 added a .reason attribute to urllib2.HTTPError in Python 2.7, issue16634 documented it (http://hg.python.org/cpython/rev/deb60efd32eb).

The documentation for Python 2.7 doesn't mention that this attribute was added in that release. This (at least weakly) implies it's available to use in previous 2.x releases.

----------
assignee: docs at python
components: Documentation
files: HTTPError.reason-versionadded.diff
keywords: patch
messages: 204465
nosy: docs at python, moreati
priority: normal
severity: normal
status: open
title: urllib2.HTTPError.reason is not documented as "Added in 2.7"
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file32855/HTTPError.reason-versionadded.diff

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

From report at bugs.python.org  Tue Nov 26 13:27:48 2013
From: report at bugs.python.org (lambrecht)
Date: Tue, 26 Nov 2013 12:27:48 +0000
Subject: [New-bugs-announce] [issue19797] Solaris 10. mod_python build
	failed.
Message-ID: <1385468868.4.0.798110212412.issue19797@psf.upfronthosting.co.za>


New submission from lambrecht:

Bonjour. Any idea ? 

mod_python 3.3.1 apache 2.2.6

...
/METHPR/tmp/apache/build/libtool --silent --mode=link gcc -o mod_python.la  -rpath /METHPR/tmp/apache/modules -module -avoid-version    finfoob
ject.lo hlistobject.lo hlist.lo filterobject.lo connobject.lo serverobject.lo util.lo tableobject.lo requestobject.lo _apachemodule.lo mod_pyth
on.lo -L/METHPR/data/python/lib/python2.6/config -lm -lintl -lpython2.6 -lsocket -lnsl -lrt -ldl -lm _eprintf.o _floatdidf.o _muldi3.o

*** Warning: Linking the shared library mod_python.la against the non-libtool
*** objects  _eprintf.o _floatdidf.o _muldi3.o is not portable!
Text relocation remains                         referenced
    against symbol                  offset      in file
.text (section)                     0x1510      /METHPR/data/python/lib/python2.6/config/libpython2.6.a(floatobject.o)
.text (section)                     0x1514      /METHPR/data/python/lib/python2.6/config/libpython2.6.a(floatobject.o)
.text (section)                     0x1518      /METHPR/data/python/lib/python2.6/config/libpython2.6.a(floatobject.o)
.text (section)                     0x151c      /METHPR/data/python/lib/python2.6/config/libpython2.6.a(floatobject.o)
.text (section)                     0x1520      /METHPR/data/python/lib/python2.6/config/libpython2.6.a(floatobject.o)
.text (section)                     0x1524      /METHPR/data/python/lib/python2.6/config/libpython2.6.a(floatobject.o)

.../...
                           0x33ec      /METHPR/produits/python/lib/python2.6/config/libpython2.6.a(fileobject.o)
__filbuf                            0x33fc      /METHPR/produits/python/lib/python2.6/config/libpython2.6.a(fileobject.o)
ld: fatal: relocations remain against allocatable but non-writable sections
collect2: ld returned 1 exit status
apxs:Error: Command failed with rc=65536
.
*** Error code 1
make: Fatal error: Command failed for target `mod_python.so'
Current working directory /METHPR/data/mod_python-3.3.1/src
*** Error code 1
The following command caused the error:
cd src && make
make: Fatal error: Command failed for target `do_dso'

----------
messages: 204468
nosy: lambrechtphilippe
priority: normal
severity: normal
status: open
title: Solaris 10. mod_python build failed.

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

From report at bugs.python.org  Tue Nov 26 13:55:01 2013
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Nov 2013 12:55:01 +0000
Subject: [New-bugs-announce] [issue19798] tracemalloc: rename "max_size" to
	"peak_size" in	get_traced_memory() result
Message-ID: <1385470501.4.0.457090532549.issue19798@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Jim.J.Jewett asked me to replaced "max_size" with "peak_size". It looks like Linux also uses the term "peak" for /proc/pid/status (or sometimes "High Water Mark").

See attached patch.

----------
files: peak_size.patch
keywords: patch
messages: 204470
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: tracemalloc: rename "max_size" to "peak_size" in get_traced_memory() result
Added file: http://bugs.python.org/file32856/peak_size.patch

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

From report at bugs.python.org  Tue Nov 26 15:34:58 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 26 Nov 2013 14:34:58 +0000
Subject: [New-bugs-announce] [issue19799] Clarifications for the
	documentation of pathlib
Message-ID: <1385476498.92.0.260116093665.issue19799@psf.upfronthosting.co.za>


New submission from Eli Bendersky:

Following up from Issue #19673; The initial patch clarifies the use cases of pure vs. concrete paths a bit and adds explicit signatures for the path class constructors (moving the construction discussion under the parent class).

Also, IMHO an inheritance diagram from PEP 428 is very relevant and useful. Would you mind if I add a .png for the pathlib rst doc?

----------
assignee: eli.bendersky
components: Documentation
messages: 204477
nosy: eli.bendersky, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Clarifications for the documentation of pathlib
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Nov 26 16:10:25 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Nov 2013 15:10:25 +0000
Subject: [New-bugs-announce] [issue19800] Write more detailed framing tests
Message-ID: <1385478625.17.0.0337296712121.issue19800@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The pickle tests for protocol 4 currently don't test that framing conforms strictly to the frame structure shown in:
http://www.python.org/dev/peps/pep-3154/#framing

It would be nice to add tests for this, especially the frame size.

----------
components: Library (Lib), Tests
messages: 204485
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: low
severity: normal
status: open
title: Write more detailed framing tests
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 26 17:57:10 2013
From: report at bugs.python.org (Sworddragon)
Date: Tue, 26 Nov 2013 16:57:10 +0000
Subject: [New-bugs-announce] [issue19801] Concatenating bytes is much slower
	than concatenating	strings
Message-ID: <1385485030.81.0.978810196169.issue19801@psf.upfronthosting.co.za>


New submission from Sworddragon:

In the attachments is a testcase which does concatenate 100000 times a string and than 100000 times a bytes object. Here is my result:

sworddragon at ubuntu:~/tmp$ ./test.py
String: 0.03165316581726074
Bytes : 0.5805566310882568

----------
components: Benchmarks
files: test.py
messages: 204503
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Concatenating bytes is much slower than concatenating strings
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file32859/test.py

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

From report at bugs.python.org  Tue Nov 26 18:06:19 2013
From: report at bugs.python.org (Sworddragon)
Date: Tue, 26 Nov 2013 17:06:19 +0000
Subject: [New-bugs-announce] [issue19802] socket.SO_PRIORITY is missing
Message-ID: <1385485579.99.0.471708921072.issue19802@psf.upfronthosting.co.za>


New submission from Sworddragon:

socket(7) does contain SO_PRIORITY but trying to use this value will result in this error: AttributeError: 'module' object has no attribute 'SO_PRIORITY'

----------
components: Library (Lib)
messages: 204506
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: socket.SO_PRIORITY is missing
type: behavior
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Tue Nov 26 21:54:09 2013
From: report at bugs.python.org (HCT)
Date: Tue, 26 Nov 2013 20:54:09 +0000
Subject: [New-bugs-announce] [issue19803] memoryview complain ctypes byte
	array are not native	single character
Message-ID: <1385499249.85.0.446556603594.issue19803@psf.upfronthosting.co.za>


New submission from HCT:

I'm trying to create ctypes buffer to be used back and forth with C libraries, but I keep getting errors. I need to slice the buffer to cut out different pieces to work on, so I try to get a memoryview of the buffer. does the error message imply that c_ubyte, c_uint8, c_byte and c_char are not native single character types?

>>> memoryview(c_ubyte()).cast('B')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: memoryview: source format must be a native single character format prefixed with an optional '@'
>>> memoryview((c_ubyte*1024)()).cast('B')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: memoryview: source format must be a native single character format prefixed with an optional '@'
>>> memoryview(c_uint8()).cast('B')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: memoryview: source format must be a native single character format prefixed with an optional '@'
>>> memoryview((c_uint8*1024)()).cast('B')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: memoryview: source format must be a native single character format prefixed with an optional '@'
>>> memoryview((c_byte*1024)()).cast('B')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: memoryview: source format must be a native single character format prefixed with an optional '@'
>>> memoryview((c_char*1024)()).cast('B')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: memoryview: source format must be a native single character format prefixed with an optional '@'
>>> memoryview((c_char*1024)())[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NotImplementedError: memoryview: unsupported format (1024)<c
>>> memoryview((c_byte*1024)())[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NotImplementedError: memoryview: unsupported format (1024)<b
>>> memoryview((c_ubyte*1024)())[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NotImplementedError: memoryview: unsupported format (1024)<B
>>> memoryview((c_uint8*1024)())[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NotImplementedError: memoryview: unsupported format (1024)<B
>>>

----------
components: Library (Lib), ctypes
messages: 204536
nosy: hct
priority: normal
severity: normal
status: open
title: memoryview complain ctypes byte array are not native single character
versions: Python 3.3

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

From report at bugs.python.org  Wed Nov 27 03:59:28 2013
From: report at bugs.python.org (Tim Peters)
Date: Wed, 27 Nov 2013 02:59:28 +0000
Subject: [New-bugs-announce] [issue19804] test_uuid failing on 32-bit
	Windows Vista
Message-ID: <1385521168.13.0.486814911092.issue19804@psf.upfronthosting.co.za>


New submission from Tim Peters:

Using current default branch:

FAIL: test_find_mac (test.test_uuid.TestUUID)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Code\Python\lib\test\test_uuid.py", line 378, in test_find_mac
    self.assertEqual(mac, 0x1234567890ab)
AssertionError: None != 20015998341291

----------
assignee: serhiy.storchaka
messages: 204548
nosy: serhiy.storchaka, tim.peters
priority: normal
severity: normal
status: open
title: test_uuid failing on 32-bit Windows Vista
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Nov 27 05:32:09 2013
From: report at bugs.python.org (Graham Wideman)
Date: Wed, 27 Nov 2013 04:32:09 +0000
Subject: [New-bugs-announce] [issue19805] Revise FAQ Dictionary: consistent
	key order item
Message-ID: <1385526729.76.0.941069828347.issue19805@psf.upfronthosting.co.za>


New submission from Graham Wideman:

FAQ entry:
http://docs.python.org/3/faq/programming.html#how-can-i-get-a-dictionary-to-display-its-keys-in-a-consistent-order
claims that there's no way for a dictionary to return keys in a consistent order. However, there's OrderedDict which should probably be mentioned here.

----------
assignee: docs at python
components: Documentation
messages: 204550
nosy: docs at python, gwideman
priority: normal
severity: normal
status: open
title: Revise FAQ Dictionary: consistent key order item
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Wed Nov 27 07:10:48 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 27 Nov 2013 06:10:48 +0000
Subject: [New-bugs-announce] [issue19806] smtpd crashes when a multi-byte
	UTF-8 sequence is split	between consecutive data packets
Message-ID: <1385532648.32.0.209027401379.issue19806@psf.upfronthosting.co.za>


New submission from Petri Lehtinen:

>From Illirgway, https://github.com/akheron/cpython/pull/2:

Fix utf-8 bug, when symbol byte chain splits on 2 tcp-packets:

error: uncaptured python exception, closing channel (:'utf-8' codec can't decode byte 0xd0 in position 1474: unexpected end of data [/usr/lib/python3.3/asyncore.py|read|83] [/usr/lib/python3.3/asyncore.py|handle_read_event|441] [/usr/lib/python3.3/asynchat.py|handle_read|178] [/usr/lib/python3.3/smtpd.py|collect_incoming_data|289])

----------
components: Library (Lib)
files: smtpd.patch
keywords: needs review, patch
messages: 204553
nosy: giampaolo.rodola, petri.lehtinen
priority: normal
severity: normal
stage: patch review
status: open
title: smtpd crashes when a multi-byte UTF-8 sequence is split between consecutive data packets
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file32863/smtpd.patch

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

From report at bugs.python.org  Wed Nov 27 08:21:47 2013
From: report at bugs.python.org (chili)
Date: Wed, 27 Nov 2013 07:21:47 +0000
Subject: [New-bugs-announce] [issue19807] calculation of  standard math
Message-ID: <1385536907.86.0.721249156878.issue19807@psf.upfronthosting.co.za>


New submission from chili:

Calculation of
print (162-159.9)
(IDLE and source script) returns
2.0999999999999943

I don?t make my financial calculation with this command :)

----------
components: Regular Expressions
messages: 204561
nosy: chili, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: calculation of  standard math
versions: Python 3.3

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

From report at bugs.python.org  Wed Nov 27 09:42:42 2013
From: report at bugs.python.org (Peter Otten)
Date: Wed, 27 Nov 2013 08:42:42 +0000
Subject: [New-bugs-announce] [issue19808] IDLE applys syntax highlighting to
	user input in its	shell
Message-ID: <1385541762.06.0.369087004664.issue19808@psf.upfronthosting.co.za>


New submission from Peter Otten:

For example when you type

>>> input("What shall I do? ")
Run for your life!

in its shell window IDLE shows the 'for' as if it were a keyword. The same happens if you run a script that requires user interaction.

----------
components: IDLE
messages: 204566
nosy: peter.otten
priority: normal
severity: normal
status: open
title: IDLE applys syntax highlighting to user input in its shell

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

From report at bugs.python.org  Wed Nov 27 10:30:46 2013
From: report at bugs.python.org (Owen Lin)
Date: Wed, 27 Nov 2013 09:30:46 +0000
Subject: [New-bugs-announce] [issue19809] Python get stuck in second Popen
	call
Message-ID: <1385544646.44.0.340337636792.issue19809@psf.upfronthosting.co.za>


New submission from Owen Lin:

If we call two subprocess.Popen simultaneously, the second one is blocked until the first one is finished. 

The attached file is a code snippet to reproduce this bug. I can reproduce the bug in version 2.7.3 and 2.7.6 very easily (in few seconds with the code). But it works fine on python3. 


Here is the backtrace of python
==========================================
#0  0x00007f0eba954d2d in read () at ../sysdeps/unix/syscall-template.S:82#1  0x00000000005d8d10 in posix_read (self=0x0, args=(5, 1048576)) at ../Modules/posixmodule.c:6628#2  0x0000000000486896 in PyCFunction_Call (func=<built-in function read>, arg=(5, 1048576), kw=0x0)    at ../Objects/methodobject.c:81#3  0x00000000005278e4 in ext_do_call (func=<built-in function read>, pp_stack=0x7fff1fc0ac80, flags=1, na=0, nk=0)    at ../Python/ceval.c:4331
#4  0x00000000005215cd in PyEval_EvalFrameEx (
    f=Frame 0x298f800, for file /usr/lib/python2.7/subprocess.py, line 478, in _eintr_retry_call (func=<built-in funct
ion read>, args=(5, 1048576)), throwflag=0) at ../Python/ceval.c:2705
#5  0x0000000000523c2e in PyEval_EvalCodeEx (co=0x294b880,     globals={'STDOUT': -2, '_has_poll': True, 'gc': <module at remote 0x29672d0>, 'check_call': <function at remote 0x29c4450>, 'mswindows': False, 'select': <module at remote 0x29676e0>, 'list2cmdline': <function at remote 0x29c45a0>, '__all__': ['Popen', 'PIPE', 'STDOUT', 'call', 'check_call', 'check_output', 'CalledProcessError'], 'errno': <module at remote 0x272d4d8>, '_demo_posix': <function at remote 0x29c4648>, '__package__': None, 'PIPE': -1, '_cleanup': <func
===================================

The fd 5 is actually a pipe. But I cannot find the other end of the pipe. A workaround is using lock around all the Popen()s.

----------
files: test.py
messages: 204568
nosy: owenlin
priority: normal
severity: normal
status: open
title: Python get stuck in second Popen call
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file32868/test.py

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

From report at bugs.python.org  Wed Nov 27 11:10:45 2013
From: report at bugs.python.org (madan ram)
Date: Wed, 27 Nov 2013 10:10:45 +0000
Subject: [New-bugs-announce] [issue19810] adding an feature to python
	interpreter
Message-ID: <1385547045.38.0.843948844606.issue19810@psf.upfronthosting.co.za>


New submission from madan ram:

I found that it will be useful to show the list of function arguments using inspect module. When the function executed by the user in interpreter as "TypeError". 

ex: - 

>>def foo(a,b=4,c="hello"):
...     print a,b,c

>>foo()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: foo() takes at least 2 arguments (0 given)

Rather the displaying like above it is will be much more readable to show as below.

>>foo()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: foo() takes at least 1 arguments args=['a', 'b', 'c'], varargs=None, keywords=None, defaults=(4, 'hello') (0 given)

This will be advantageous when the user has forgotten what parameter to use for builtin function when working offline.

----------
components: Interpreter Core
messages: 204569
nosy: eric.araujo, ezio.melotti, georg.brandl, gpolo, madan.ram
priority: normal
severity: normal
status: open
title: adding an feature to python interpreter
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Nov 27 11:45:08 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Nov 2013 10:45:08 +0000
Subject: [New-bugs-announce] [issue19811] test_pathlib: "The directory is
	not empty" error on	os.rmdir()
Message-ID: <1385549108.25.0.37383053389.issue19811@psf.upfronthosting.co.za>


New submission from STINNER Victor:

test_pathlib should use test.support.rmtree() instead of shutil.rmtree(). The function in support tries harder on Windows.

test_pathlib may also create an unique temporary directory at each test run instead of using a global variable BASE: see below, tests are failing because the directory already exist. (Well, this issue is a consequence of the first one.)

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

======================================================================
ERROR: test_touch_common (test.test_pathlib.WindowsPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 477, in rmtree
    return _rmtree_unsafe(path, onerror)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 367, in _rmtree_unsafe
    _rmtree_unsafe(fullname, onerror)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 367, in _rmtree_unsafe
    _rmtree_unsafe(fullname, onerror)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 376, in _rmtree_unsafe
    onerror(os.rmdir, path, sys.exc_info())
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\shutil.py", line 374, in _rmtree_unsafe
    os.rmdir(path)
OSError: [WinError 145] The directory is not empty: 'C:\\buildbot.python.org\\3.x.kloth-win64\\build\\build\\test_python_4528\\@test_4528_tmp\\dirC\\dirD'

======================================================================
ERROR: test_touch_nochange (test.test_pathlib.WindowsPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_pathlib.py", line 1081, in setUp
    os.mkdir(BASE)
FileExistsError: [WinError 183] Cannot create a file when that file already exists: 'C:\\buildbot.python.org\\3.x.kloth-win64\\build\\build\\test_python_4528\\@test_4528_tmp'

======================================================================
ERROR: test_unlink (test.test_pathlib.WindowsPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_pathlib.py", line 1081, in setUp
    os.mkdir(BASE)
FileExistsError: [WinError 183] Cannot create a file when that file already exists: 'C:\\buildbot.python.org\\3.x.kloth-win64\\build\\build\\test_python_4528\\@test_4528_tmp'

======================================================================
ERROR: test_with (test.test_pathlib.WindowsPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_pathlib.py", line 1081, in setUp
    os.mkdir(BASE)
FileExistsError: [WinError 183] Cannot create a file when that file already exists: 'C:\\buildbot.python.org\\3.x.kloth-win64\\build\\build\\test_python_4528\\@test_4528_tmp'

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

----------
components: Windows
messages: 204571
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: test_pathlib: "The directory is not empty" error on os.rmdir()
versions: Python 3.4

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

From report at bugs.python.org  Wed Nov 27 12:10:56 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 27 Nov 2013 11:10:56 +0000
Subject: [New-bugs-announce] [issue19812] reload() by symbol name
Message-ID: <1385550656.86.0.860350821267.issue19812@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

It would be nice if reload() supported reloading of symbols imported with "from module import ..." syntax. It is quite useful for development sessions, when you patch and test your function on some set of unexpected input.

>>> from astdump import dumpattrs as dat
>>> import imp
>>> imp.reload(dat)
TypeError: reload() argument must be module
>>> imp.reload(dumpattrs)
NameError: name 'dumpattrs' is not defined
>>> imp.reload(astdump)
NameError: name 'astdump' is not defined
>>>

----------
components: Interpreter Core, Library (Lib)
messages: 204573
nosy: techtonik
priority: normal
severity: normal
status: open
title: reload() by symbol name
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Nov 27 12:57:08 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Nov 2013 11:57:08 +0000
Subject: [New-bugs-announce] [issue19813] Add a new optional timeout
	parameter to socket.socket()	constructor
Message-ID: <1385553428.3.0.518090447657.issue19813@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Since Linux 2.6.28, socket() syscall accepts a new SOCK_NONBLOCK flag in the socket type. It avoids 1 or 2 extra syscalls to set the socket in non-blocking mode. This flag comes also slowly in other operating systems: NetBSD, FreeBSD, etc.

FreeBSD:
http://lists.freebsd.org/pipermail/freebsd-hackers/2013-March/042242.html

Discussion in the POSIX standard:
http://austingroupbugs.net/view.php?id=411

Avoiding the syscalls has been proposed on python-dev a few months ago:
https://mail.python.org/pipermail/python-dev/2013-January/123661.html

I tried to include SOCK_NONBLOCK in my PEP 446, but I have been asked to treat it separatly because it's completly different than O_CLOEXEC (even it looks similar).
http://hg.python.org/peps/file/fa873d5aed27/pep-0446.txt#l64

I also proposed to add 2 functions in the PEP:

* ``os.get_blocking(fd:int) -> bool``
* ``os.set_blocking(fd:int, blocking: bool)``

I propose to add a new timeout parameter to socket.socket() constructor which would set the timeout internal attribute and set O_NONBLOCK flag using the new SOCK_NONBLOCK flag, ioctl() or fcntl() (depending on the OS and on what is available).

I don't know if something special should be done on Windows for non-blocking sockets? socket.socket.setblocking() already exists and I suppose that it works on Windows :-) See also the discussion in my old PEP for non-blocking operations in files on Windows:
http://hg.python.org/peps/file/fa873d5aed27/pep-0446.txt#l177

I don't know if the new parameter can just be added at the end of the parameter list, or it should be a keyword-only parameter to avoid breakpoint backward compatibility?

socket.socketpair() and socket.socket.dup() and socket.fromfd(), socket.create_connection() (and more generally any function creating a new socket) may also be modified.

--

By the way, internal_setblocking() currently uses 2 fcntl() syscalls on Linux, whereas it could be implemented with a single ioctl() syscall using FIONBIO.

Set O_NONBLOCK flag:

int flag = 1;
ioctl(fd, FIONBIO, &flag);

Clear O_NONBLOCK flag:

int flag = 0;
ioctl(fd, FIONBIO, &flag);

Tell me if you prefer a different issue for this optimization.

----------
messages: 204575
nosy: gvanrossum, haypo, pitrou
priority: normal
severity: normal
status: open
title: Add a new optional timeout parameter to socket.socket() constructor
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed Nov 27 15:16:01 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 27 Nov 2013 14:16:01 +0000
Subject: [New-bugs-announce] [issue19814] Document prefix matching behavior
	of argparse, particularly for parse_known_args
Message-ID: <1385561761.38.0.108882000791.issue19814@psf.upfronthosting.co.za>


New submission from Eli Bendersky:

Prefix matching behavior can lead to bugs when combined with parse_known_args. See this thread for more details:

https://mail.python.org/pipermail/python-dev/2013-November/130601.html

Issue #14910 deals with making it optional, but until 3.5 we'll have to do with a documentation warning.

----------
assignee: eli.bendersky
components: Documentation
messages: 204584
nosy: bethard, eli.bendersky, r.david.murray
priority: high
severity: normal
status: open
title: Document prefix matching behavior of argparse, particularly for parse_known_args
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov 27 18:26:48 2013
From: report at bugs.python.org (Yann Diorcet)
Date: Wed, 27 Nov 2013 17:26:48 +0000
Subject: [New-bugs-announce] [issue19815] ElementTree segmentation fault in
	expat_start_ns_handler
Message-ID: <1385573208.73.0.552748104114.issue19815@psf.upfronthosting.co.za>


New submission from Yann Diorcet:

I fell on a bug in ElementTree of Python 2.7.5 (default, Nov 12 2013, 16:18:04)

The bug seems to be here: http://hg.python.org/cpython/file/ab05e7dd2788/Modules/_elementtree.c#l2341

uri is NULL and not checked before be passed to strlen

Maybe linked to my expat version: 
expat.i686                             2.1.0-5.fc19                    @fedora  
expat.x86_64                           2.1.0-5.fc19                    @anaconda

----------
components: Library (Lib)
files: trace
messages: 204601
nosy: Yann.Diorcet
priority: normal
severity: normal
status: open
title: ElementTree segmentation fault in expat_start_ns_handler
versions: Python 2.7
Added file: http://bugs.python.org/file32872/trace

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

From report at bugs.python.org  Wed Nov 27 18:49:27 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Nov 2013 17:49:27 +0000
Subject: [New-bugs-announce] [issue19816] test.regrtest: use tracemalloc to
	detect memory leaks?
Message-ID: <1385574567.13.0.658193624023.issue19816@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Someone proposed to use the new tracemalloc module in test.regrtest, I don't remember who. Maybe Nick Coghlan?

I tried an hack dash_R(), but the result was not reliable. I should try harder :-)

----------
components: Tests
messages: 204604
nosy: haypo, ncoghlan, neologix
priority: normal
severity: normal
status: open
title: test.regrtest: use tracemalloc to detect memory leaks?
versions: Python 3.4

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

From report at bugs.python.org  Wed Nov 27 19:03:12 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Nov 2013 18:03:12 +0000
Subject: [New-bugs-announce] [issue19817] tracemalloc add a memory limit
	feature
Message-ID: <1385575392.84.0.858805099832.issue19817@psf.upfronthosting.co.za>


New submission from STINNER Victor:

It would be nice to add a memory_limit feature to the tracemalloc to make memory allocation fails if it would make the traced memory greater than the limit.

See also the pyfailmalloc project which is similar but different:
https://bitbucket.org/haypo/pyfailmalloc

pyfailmalloc doesn't count allocated bytes, it schedules an error in N allocations where N is a random number. And pyfailmalloc only schedules one error, whereas I propose to make all memory allocations fails until the limit is respected.

So if you only 0 bytes free (according to the limit), all memory allocations fail until some bytes are freed.

Python currently behaves badly under very low memory condition.

See also the issue #19437.

----------
files: tracemalloc_memory_limit.patch
keywords: patch
messages: 204605
nosy: haypo, neologix
priority: normal
severity: normal
status: open
title: tracemalloc add a memory limit feature
versions: Python 3.5
Added file: http://bugs.python.org/file32873/tracemalloc_memory_limit.patch

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

From report at bugs.python.org  Wed Nov 27 23:18:43 2013
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Nov 2013 22:18:43 +0000
Subject: [New-bugs-announce] [issue19818] tracemalloc: comments on the doc
Message-ID: <1385590723.56.0.301392704832.issue19818@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Jim Jewett posted the message msg204618 to the issue #18874 which is now closed, so I'm opening a new issue. Copy of his message.


These comments refer to http://hg.python.org/cpython/file/5c9af8194d3b/Doc/library/tracemalloc.rst which is newer than the current patches.

I believe I have consolidated the still-open issues that I see (including those that aren't mine) for this file:

http://hg.python.org/cpython/file/5c9af8194d3b/Doc/library/tracemalloc.rst

(line 24, new comment; also repeated at line 315)

frame (1 frame). To store 25 frames at startup: set the
:envvar:`PYTHONTRACEMALLOC` environment variable to ``25``, or use the
:option:`-X` ``tracemalloc=25`` command line option.
->

frame (1 frame). To store 25 frames at startup: set the
:envvar:`PYTHONTRACEMALLOC` environment variable to ``25``, or use the
:option:`-X` ``tracemalloc=25`` command line option.  If tracing is

started later, the maximum number of frames is a parameter to the 

 :func:`start` function.



(line 111)

If the system has little free memory, snapshots can be written on disk using
the :meth:`Snapshot.dump` method to analyze the snapshot offline. Then use the
:meth:`Snapshot.load` method reload the snapshot.

 ->

Snapshots can be stored to disk using :meth:`Snapshot.dump` and reloaded using :meth:`Snapshot.load`.



(line 180, new comment)
... The traceback is
where the :mod:`importlib` loaded data most recently: on the ``import pdb``
line of the :mod:`doctest` module. The traceback may change if a new module is
loaded.

->

The traceback represents the call stack when those allocations were made.  

As this particular summary is itemized by traceback, it also represents 

the call stack for all 903 of those allocations.


(line 252: new comment)
.. function:: clear_traces()

   Clear traces of memory blocks allocated by Python.

Add "Future allocations will still be traced."


Is this just a shortcut for stop();start()  ?  If so, please say so.  If not, please explain why.



(Line 311: new comment)
to measure how much memory is used
->
for an approximate measure of how much memory is used


I understand your reluctance to get into too many details, but ... well, it isn't a complete measure.  It misses the python objects of tracemalloc itself, it misses the overhead of the module, it misses any filenames that were kept alive only by tracing, etc.


(Line 372, new comment)
      If *inclusive* is ``True`` (include), only trace memory blocks allocated
      in a file with a name matching :attr:`filename_pattern` at line number
      :attr:`lineno`.

      If *inclusive* is ``False`` (exclude), ignore memory blocks allocated in
      a file with a name matching :attr:`filename_pattern` at line number
      :attr:`lineno`.
->
      If *inclusive* is ``True`` (include), then trace memory blocks allocated
      in a file with a name matching :attr:`filename_pattern` at line number
      :attr:`lineno`.  Also excludes any blocks not selected by any filter.

      If *inclusive* is ``False`` (exclude), ignore memory blocks allocated in
      a file with a name matching :attr:`filename_pattern` at line number
      :attr:`lineno`, even if they would otherwise be included.


(Line 394: new comment)
      This attribute is ignored if the traceback limit is less than ``2``.
->
      This attribute is meaningless if the traceback limit is ``1``.



Just after Line 428, not quite a new issue:
      Compute the differences with an old snapshot. Get statistics as a sorted
      list of :class:`StatisticDiff` instances grouped by *group_by*.

->

      Compute the differences with an old snapshot. Get statistics as a sorted
      list of :class:`StatisticDiff` instances grouped by *group_by*.

      Note that applying different Filters can cause spurious differences; users planning to archive a Snapshot may therefore wish to first add various annotations.


(Line 454, new comment)
      All inclusive filters are applied at once, a trace is ignored if no
      inclusive filters match it. A trace is ignored if at least one exclusive
      filter matchs it.
->
      If there are any inclusive filters, then they are all applied, and traces which do not match at least one of them are excluded.  A trace is also ignored if at least one exclusive
      filter matches it.


Line 544, new comment:

   .. attribute:: count_diff

      Difference of number of memory blocks between the old and the new
      snapshots (``int``): ``0`` if the memory blocks have been allocated in
      the new snapshot.
->
   .. attribute:: count_diff

      Difference of number of memory blocks between the old and the new
      snapshots (``int``).  count_diff==count if the memory blocks do not appear in the old snapshot.

Line 558, similar to above:
      the new snapshots (``int``): ``0`` if the memory blocks have been
      allocated in the new snapshot.
->
      the new snapshots (``int``).  size_diff==size if the memory blocks do not appear in the old snapshot.

----------
messages: 204620
nosy: Jim.Jewett, haypo, neologix
priority: normal
severity: normal
status: open
title: tracemalloc: comments on the doc
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov 28 00:51:14 2013
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 27 Nov 2013 23:51:14 +0000
Subject: [New-bugs-announce] [issue19819] reversing a Unicode ligature
	doesn't work
Message-ID: <1385596274.49.0.637567872946.issue19819@psf.upfronthosting.co.za>


New submission from Larry Hastings:

Read this today:

http://mortoray.com/2013/11/27/the-string-type-is-broken/

In it the author talks about how the 'ffl' ligature breaks some string processing.  He claimed that Python 3 doesn't uppercase it correctly--well, it does.  However I discovered that it doesn't reverse it properly.

    x = b'ba\xef\xac\x84e'.decode('utf-8') # "baffle", where "ffl" is a ligature
    print(x) # prints "baffle", with the ligature
    print(x.upper())  # prints "BAFFLE", no ligature, which is fine
    print("".join(reversed(x))) # prints "efflab"

Shouldn't that last line print "elffab"?

If this gets marked as "wontfix" I wouldn't complain.  Just wondering what the Right Thing is to do here.

----------
messages: 204628
nosy: larry
priority: low
severity: normal
stage: needs patch
status: open
title: reversing a Unicode ligature doesn't work
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Nov 28 07:42:21 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 28 Nov 2013 06:42:21 +0000
Subject: [New-bugs-announce] [issue19820] docs are missing info about module
	attributes
Message-ID: <1385620941.03.0.287546381963.issue19820@psf.upfronthosting.co.za>


New submission from Eric Snow:

The docs for the inspect module and the types module do not list all the import-related module attributes.  I'm guessing they've been out of sync a while.

The docstring for for inspect.ismodule() is likewise missing information.

----------
assignee: docs at python
components: Documentation
messages: 204642
nosy: docs at python, eric.snow
priority: low
severity: normal
stage: needs patch
status: open
title: docs are missing info about module attributes
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Nov 28 08:55:30 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 28 Nov 2013 07:55:30 +0000
Subject: [New-bugs-announce] [issue19821] pydoc.ispackage() could be more
	accurate
Message-ID: <1385625330.82.0.952141123031.issue19821@psf.upfronthosting.co.za>


New submission from Eric Snow:

pydoc.ispackage() is a best-effort guess at whether or not a path is the location of a package.  However, it uses hard-coded suffixes when matching file names, which can miss files (e.g. extension modules and sourceless packages on Windows).  It should probably use suffixes defined in importlib.util, as they're used elsewhere in pydoc.  The function also does not comprehend namespace packages, but I'm not sure that's worth worrying about.

FWIW, it isn't clear to me what is using pydoc.ispackage().  It may not be used in the stdlib at all.

----------
components: Library (Lib)
messages: 204646
nosy: eric.snow
priority: low
severity: normal
stage: needs patch
status: open
title: pydoc.ispackage() could be more accurate
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Nov 28 14:59:29 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 28 Nov 2013 13:59:29 +0000
Subject: [New-bugs-announce] [issue19822] PEP process entrypoint
Message-ID: <1385647169.27.0.622120668783.issue19822@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

https://bitbucket.org/rirror/peps

PEP repository readme lacks information about how to send Python Enhancement Proposal step-by-step.

1. hg clone https://bitbucket.org/rirror/peps
2. cd peps
3. # choose number
4. cp ??? pep-{{number}}.txt
5. # commit
6. # send pull request
7. # discuss

----------
assignee: docs at python
components: Devguide, Documentation
messages: 204652
nosy: docs at python, ezio.melotti, techtonik
priority: normal
severity: normal
status: open
title: PEP process entrypoint

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

From report at bugs.python.org  Thu Nov 28 15:03:18 2013
From: report at bugs.python.org (cost6)
Date: Thu, 28 Nov 2013 14:03:18 +0000
Subject: [New-bugs-announce] [issue19823] for-each on list aborts earlier
	than expected
Message-ID: <1385647398.27.0.505205145304.issue19823@psf.upfronthosting.co.za>


New submission from cost6:

for-each does not iterate over all entries of collection, if one removes elements during the iteration.

Example (misbehaving) code:

def keepByValue(self, key=None, value=[]):
    for row in self.flows:
        if not row[key] in value:
            flows.remove(row)

----------
components: Interpreter Core
messages: 204653
nosy: cost6
priority: normal
severity: normal
status: open
title: for-each on list aborts earlier than expected
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Nov 28 18:07:04 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 28 Nov 2013 17:07:04 +0000
Subject: [New-bugs-announce] [issue19824] string.Template: Add PHP-style
	variable expansion example
Message-ID: <1385658424.56.0.963803246137.issue19824@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

http://docs.python.org/2/library/string.html#template-strings

This class could be more useful with the following example:

>>> from string import Template
>>> t = Template('$who likes $what')
>>> who = 'tim'
>>> what = 'kung pao'
>>> t.substitute(locals())
'tim likes kung pao'

This will help PHP folks to transition their .php files.

----------
assignee: docs at python
components: Documentation
messages: 204677
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: string.Template: Add PHP-style variable expansion example

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

From report at bugs.python.org  Thu Nov 28 19:01:41 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 28 Nov 2013 18:01:41 +0000
Subject: [New-bugs-announce] [issue19825] test b.p.o email interface
Message-ID: <CAPkN8xJ6G+RUW+gtu-wDhKQ0bni0GNQwq_Q2nkyjuzaQ6FAoFA@mail.gmail.com>


New submission from anatoly techtonik:

--
anatoly t.

----------
messages: 204688
nosy: techtonik
priority: normal
severity: normal
status: open
title: test b.p.o email interface

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

From report at bugs.python.org  Thu Nov 28 20:50:45 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 28 Nov 2013 19:50:45 +0000
Subject: [New-bugs-announce] [issue19826] Document that bug reporting by
	email is possible
Message-ID: <1385668245.52.0.0107396832211.issue19826@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

I found this to be convenient: http://techtonik.rainforce.org/2013/11/roundup-tracker-create-issues-by-email.html

And this is missing from here: http://docs.python.org/release/2.7/bugs.html#using-the-python-issue-tracker
Anf from here:
http://docs.python.org/devguide/triaging.html

Disclaimer: I didn't sign the CLA, and people keep telling me that I need it to do documentation edits. But I edit Wikipedia freely and I find it wrong that I can not edit Python documentation without signing papers. So I am not sending patches until either Wikipedia requires CLA to edit its contents, or PSF abandons its ill FUD policies in favor of creating collaborative environment.

Regarding my aforementioned blog post, feel free to copy-paste it, as an author I release this into CC0/public domain. Ask python-legal-sig if it is enough.

----------
assignee: docs at python
components: Documentation
messages: 204693
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: Document that bug reporting by email is possible

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

From report at bugs.python.org  Thu Nov 28 22:10:09 2013
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Nov 2013 21:10:09 +0000
Subject: [New-bugs-announce] [issue19827] Optimize socket.settimeout() and
	socket.setblocking():	avoid syscall
Message-ID: <1385673009.77.0.328160102824.issue19827@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch avoids a syscall on socket.setblocking() and socket.settimeout() when possible: use ioctl(FIONBIO) when available (not only on VMS), or use fcntl() but only call fcntl() twice if the flags changed.

The fcntl() optimization was suggested by Peter Portante some months ago:
https://mail.python.org/pipermail/python-dev/2013-January/123661.html

See also the rejected issue #19813: "Add a new optional timeout parameter to socket.socket() constructor".

----------
components: Library (Lib)
files: socket.patch
keywords: patch
messages: 204698
nosy: haypo
priority: normal
severity: normal
status: open
title: Optimize socket.settimeout() and socket.setblocking(): avoid syscall
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file32882/socket.patch

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

From report at bugs.python.org  Fri Nov 29 11:02:31 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 29 Nov 2013 10:02:31 +0000
Subject: [New-bugs-announce] [issue19828] test_site fails with -S flag
Message-ID: <1385719351.7.0.144059286508.issue19828@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

$ ./python -S Lib/test/test_site.py 
Traceback (most recent call last):
  File "Lib/test/test_site.py", line 28, in <module>
    raise unittest.SkipTest("importation of site.py suppressed")
unittest.case.SkipTest: importation of site.py suppressed

This counts as fail test. So when you execute the whole unit test:

$ ./python -S Lib/test

You'll get 2 fail tests.

The first one is test_trace, already fixed in #19398, but not yet committed.

The second one is this one, test_site.

'raise unittest.SkipTest("importation of site.py suppressed")' will make the file counts as fail test.

Attached the patch to make it does not count as fail test.

----------
components: Tests
files: fix_test_site_with_s_flag.patch
keywords: patch
messages: 204711
nosy: vajrasky
priority: normal
severity: normal
status: open
title: test_site fails with -S flag
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32884/fix_test_site_with_s_flag.patch

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

From report at bugs.python.org  Fri Nov 29 11:37:01 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Nov 2013 10:37:01 +0000
Subject: [New-bugs-announce] [issue19829] _pyio.BufferedReader and
	_pyio.TextIOWrapper destructor	don't emit ResourceWarning if
	the file is not closed
Message-ID: <1385721421.95.0.384748799117.issue19829@psf.upfronthosting.co.za>


New submission from STINNER Victor:

$ ./python
Python 3.4.0b1 (default:acabd3f035fe, Nov 28 2013, 15:04:09) 
[GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import _pyio
>>> f=_pyio.open("/etc/issue"); f=None
>>> f=_pyio.open("/etc/issue", "rb"); f=None
>>> f=_pyio.open("/etc/issue", "rb", 0); f=None
__main__:1: ResourceWarning: unclosed file <_io.FileIO name='/etc/issue' mode='rb'>
>>> import io
>>> f=io.open("/etc/issue"); f=None
__main__:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/etc/issue' mode='r' encoding='UTF-8'>
>>> f=io.open("/etc/issue", "rb"); f=None
__main__:1: ResourceWarning: unclosed file <_io.BufferedReader name='/etc/issue'>
>>> f=io.open("/etc/issue", "rb", 0); f=None
__main__:1: ResourceWarning: unclosed file <_io.FileIO name='/etc/issue' mode='rb'>

I expect the same behaviour when I use _pyio or io module.

----------
messages: 204714
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: _pyio.BufferedReader and _pyio.TextIOWrapper destructor don't emit ResourceWarning if the file is not closed
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov 29 11:52:52 2013
From: report at bugs.python.org (Vajrasky Kok)
Date: Fri, 29 Nov 2013 10:52:52 +0000
Subject: [New-bugs-announce] [issue19830] test_poplib emits resource warning
Message-ID: <1385722372.69.0.175458653403.issue19830@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

$ ./python Lib/test/test_poplib.py
<omitted....>
test_uidl (__main__.TestPOP3_TLSClass) ... ok
test_user (__main__.TestPOP3_TLSClass) ... ok

----------------------------------------------------------------------
Ran 62 tests in 4.994s

OK
/home/ethan/Documents/code/python/cpython3.4/Lib/test/support/__init__.py:1331: ResourceWarning: unclosed <ssl.SSLSocket fd=5, family=AddressFamily.AF_INET, type=2049, proto=6, laddr=('127.0.0.1', 46785), raddr=('127.0.0.1', 55396)>
  gc.collect()


Attached the patch to fix the resource warning.

----------
components: Tests
files: fix_test_poplib_resource_warning.patch
keywords: patch
messages: 204716
nosy: vajrasky
priority: normal
severity: normal
status: open
title: test_poplib emits resource warning
type: resource usage
versions: Python 3.4
Added file: http://bugs.python.org/file32886/fix_test_poplib_resource_warning.patch

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

From report at bugs.python.org  Fri Nov 29 11:57:31 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Nov 2013 10:57:31 +0000
Subject: [New-bugs-announce] [issue19831] tracemalloc: stop the module later
Message-ID: <1385722651.55.0.86737779548.issue19831@psf.upfronthosting.co.za>


New submission from STINNER Victor:

tracemalloc cannot be used in object destructors because the module is stopped early at Python shutdown.

I would like to use tracemalloc.get_object_traceback() in object destructors to retrieve where an object was allocated.

Attached patch replaces the atexit handler with a builtin _PyTraceMalloc_Fini() function to stop tracemalloc much later. It does also simplify the C code of _tracemalloc.c.

----------
files: tracemalloc_fini.patch
keywords: patch
messages: 204717
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: tracemalloc: stop the module later
versions: Python 3.4
Added file: http://bugs.python.org/file32887/tracemalloc_fini.patch

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

From report at bugs.python.org  Fri Nov 29 14:33:09 2013
From: report at bugs.python.org (Tobias Kuhn)
Date: Fri, 29 Nov 2013 13:33:09 +0000
Subject: [New-bugs-announce] [issue19832] XML version is ignored
Message-ID: <1385731989.56.0.494206354245.issue19832@psf.upfronthosting.co.za>


New submission from Tobias Kuhn:

The first line of an XML file should be something like this:

    <?xml version='1.0' encoding='UTF-8'?>

The XML parser of xml.sax, however, seems to ignore the value of "version":

    <?xml version='X' encoding='UTF-8'?>

This should give an error, but it doesn't. It's not a very serious problem, but this should raise an error to be standards-compliant.

I experienced this bug in the rdflib package:

    https://github.com/RDFLib/rdflib/issues/347

----------
components: XML
messages: 204720
nosy: tkuhn
priority: normal
severity: normal
status: open
title: XML version is ignored
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 29 16:16:16 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Nov 2013 15:16:16 +0000
Subject: [New-bugs-announce] [issue19833] asyncio: patches to document
	EventLoop and add more	examples
Message-ID: <1385738176.38.0.477367051955.issue19833@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patches document get_event_loop() and BaseEventLoop; and add two "hello world" examples copied from:
http://code.google.com/p/tulip/source/browse/#hg%2Fexamples

----------
assignee: docs at python
components: Documentation
files: asyncio_doc_eventloop.patch
keywords: patch
messages: 204724
nosy: docs at python, gvanrossum, haypo, pitrou
priority: normal
severity: normal
status: open
title: asyncio: patches to document EventLoop and add more examples
versions: Python 3.4
Added file: http://bugs.python.org/file32889/asyncio_doc_eventloop.patch

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

From report at bugs.python.org  Fri Nov 29 16:49:14 2013
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Fri, 29 Nov 2013 15:49:14 +0000
Subject: [New-bugs-announce] [issue19834] Unpickling exceptions pickled by
	Python 2
Message-ID: <1385740154.87.0.494742260047.issue19834@psf.upfronthosting.co.za>


New submission from Walter D?rwald:

Exception objects that have been pickled with Python 2 can not be unpickled with Python 3, even when fix_imports=True is specified:

  $ python2.7
  Python 2.7.2 (default, Aug 30 2011, 11:04:13)
  [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import pickle
  >>> pickle.dumps(StopIteration())
  'cexceptions\nStopIteration\np0\n(tRp1\n.'
  >>>
  $ python3.3
  Python 3.3.2 (default, Nov 14 2013, 12:22:14)
  [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import pickle
  >>> pickle.loads(b'cexceptions\nStopIteration\np0\n(tRp1\n.', fix_imports=True)
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  ImportError: No module named 'exceptions'
  >>>

Adding an entry "exceptions": "builtins" to _compat_pickle.IMPORT_MAPPING seems to fix the problem.

----------
messages: 204733
nosy: doerwalter
priority: normal
severity: normal
status: open
title: Unpickling exceptions pickled by Python 2

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

From report at bugs.python.org  Fri Nov 29 18:24:02 2013
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Nov 2013 17:24:02 +0000
Subject: [New-bugs-announce] [issue19835] Add a MemoryError singleton to fix
	an unlimited loop	when the memory is exhausted
Message-ID: <1385745842.98.0.409110544048.issue19835@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Under very low memory condition, PyErr_NoMemory() or PyErr_NormalizeException() enters an unlimited loop when the free list of MemoryError becomes empty.

I propose to add a MemoryError read-only singleton to fix this corner case. Attributes cannot be modified, new attributes cannot be added. MemoryError attributes values:

* __cause__ = None
* __context__ = None
* __suppress_context__ = False
* __traceback__ = None
* args = ()

PyException_SetTraceback(), PyException_SetCause() and PyException_SetContext() do nothing when called on the MemoryError singleton.

A MemoryError can be raised on an integer overflow when computing the size of a memory block. In this case, you may still have available free memory and so you may be able to build a traceback object, chain exceptions, etc.

If you consider that attributes must be modifiable in this case, we can keep the MemoryError unchanged and keep the free list, but add a new special "ReadOnlyMemoryError" type which has exactly one instance, preallocated at startup (the singleton).

Read-only attributes are required to not keep references to objects when the MemoryError (singleton) is ne more used ("destroyed"): see for example test_memory_error_cleanup() of test_exceptions.

Python has already a PyExc_RecursionErrorInst singleton, which is used on recursion error. It is just a preallocated RuntimeError error, attributes are modifiable. Does this exception keep a traceback when it is no more used ("destroyed")?

Maybe using read-only attributes is overkill? Replacing the free list with a singleton is enough?

--

See also issue #5437: before Python had a MemoryError singleton, but it was replaced by a free list to not keep references.

changeset:   65690:c6d86439aa91
branch:      3.1
parent:      65672:e4425d68dadf
user:        Antoine Pitrou <solipsis at pitrou.net>
date:        Thu Oct 28 23:06:57 2010 +0000
files:       Include/pyerrors.h Lib/test/test_exceptions.py Misc/NEWS Objects/exceptions.c Python/errors.c
description:
Merged revisions 85896 via svnmerge from
svn+ssh://pythondev at svn.python.org/python/branches/py3k

........
  r85896 | antoine.pitrou | 2010-10-29 00:56:58 +0200 (ven., 29 oct. 2010) | 4 lines

  Issue #5437: A preallocated MemoryError instance should not hold traceback
  data (including local variables caught in the stack trace) alive infinitely.
........

--

Another option is maybe to clear frames of the traceback. Issue #17934 added a clear() method to frame objects for that.

----------
files: memerror_singleton.patch
keywords: patch
messages: 204742
nosy: haypo
priority: normal
severity: normal
status: open
title: Add a MemoryError singleton to fix an unlimited loop when the memory is exhausted
versions: Python 3.4
Added file: http://bugs.python.org/file32892/memerror_singleton.patch

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

From report at bugs.python.org  Fri Nov 29 20:52:15 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 29 Nov 2013 19:52:15 +0000
Subject: [New-bugs-announce] [issue19836] selectors: improve examples section
Message-ID: <1385754735.32.0.742504427925.issue19836@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Here's a patch improving the "examples" section for the selectors module.

----------
assignee: docs at python
components: Documentation
files: selectors_examples.diff
keywords: needs review, patch
messages: 204750
nosy: docs at python, neologix
priority: normal
severity: normal
stage: patch review
status: open
title: selectors: improve examples section
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file32894/selectors_examples.diff

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

From report at bugs.python.org  Sat Nov 30 03:30:45 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 30 Nov 2013 02:30:45 +0000
Subject: [New-bugs-announce] [issue19837] Wire protocol encoding for the
	JSON module
Message-ID: <1385778645.87.0.0800898315059.issue19837@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

In the Python 3 transition, we had to make a choice regarding whether we treated the JSON module as a text transform (with load[s] reading Unicode code points and dump[s] producing them), or as a text encoding (with load[s] reading binary sequences and dump[s] producing them).

To minimise the changes to the module API, the decision was made to treat it as a text transform, with the text encoding handled externally.

This API design decision doesn't appear to have worked out that well in the web development context, since JSON is typically encountered as a UTF-8 encoded wire protocol, not as already decoded text.

It also makes the module inconsistent with most of the other modules that offer "dumps" APIs, as those *are* specifically about wire protocols (Python 3.4):

>>> import json, marshal, pickle, plistlib, xmlrpc.client
>>> json.dumps('hello')
'"hello"'
>>> marshal.dumps('hello')
b'\xda\x05hello'
>>> pickle.dumps('hello')
b'\x80\x03X\x05\x00\x00\x00helloq\x00.'
>>> plistlib.dumps('hello')
b'<?xml version="1.0" encoding="UTF-8"?>\n<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">\n<plist version="1.0">\n<string>hello</string>\n</plist>\n'

The only module with a dumps function that (like the json module) returns a string, is the XML-RPC client module:

>>> xmlrpc.client.dumps(('hello',))
'<params>\n<param>\n<value><string>hello</string></value>\n</param>\n</params>\n'

And that's nonsensical, since that XML-RPC API *accepts an encoding argument*, which it now silently ignores:

>>> xmlrpc.client.dumps(('hello',), encoding='utf-8')
'<params>\n<param>\n<value><string>hello</string></value>\n</param>\n</params>\n'
>>> xmlrpc.client.dumps(('hello',), encoding='utf-16')
'<params>\n<param>\n<value><string>hello</string></value>\n</param>\n</params>\n'

I now believe that an "encoding" parameter should have been added to the json.dump API in the Py3k transition (defaulting to UTF-8), allowing all of the dump/load APIs in the standard library to be consistently about converting to and from a binary wire protocol.

Unfortunately, I don't have a solution to offer at this point (since backwards compatibility concerns rule out the simple solution of just changing the return type). I just wanted to get it on record as a problem (and internal inconsistency within the standard library for dump/load protocols) with the current API.

----------
components: Library (Lib)
messages: 204764
nosy: chrism, ncoghlan
priority: normal
severity: normal
status: open
title: Wire protocol encoding for the JSON module
versions: Python 3.5

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

From report at bugs.python.org  Sat Nov 30 09:44:09 2013
From: report at bugs.python.org (Claudiu.Popa)
Date: Sat, 30 Nov 2013 08:44:09 +0000
Subject: [New-bugs-announce] [issue19838]
	test.test_pathlib.PosixPathTest.test_touch_common fails	on
	FreeBSD with ZFS
Message-ID: <1385801049.84.0.483097954762.issue19838@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

Hi!

test_touch_common fails when using 8.3-STABLE FreeBSD 8.3-STABLE and Python 3.4.0b1 (default:a0ec33efa743+, Nov 30 2013, 10:36:58). 

Here are the tracebacks:


======================================================================
FAIL: test_touch_common (test.test_pathlib.PathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tank/libs/cpython/Lib/test/test_pathlib.py", line 1402, in test_touch_common
    self.assertGreaterEqual(st.st_mtime_ns, old_mtime_ns)
AssertionError: 1385800632000000000 not greater than or equal to 1385800632871814968

======================================================================
FAIL: test_touch_common (test.test_pathlib.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tank/libs/cpython/Lib/test/test_pathlib.py", line 1402, in test_touch_common
    self.assertGreaterEqual(st.st_mtime_ns, old_mtime_ns)
AssertionError: 1385800633000000000 not greater than or equal to 1385800633042814928

----------------------------------------------------------------------
Ran 319 tests in 0.368s

FAILED (failures=2, skipped=85)
test test_pathlib failed
1 test failed:
    test_pathlib

This issue seems to be related with issue15745.

----------
components: Tests
messages: 204786
nosy: Claudiu.Popa
priority: normal
severity: normal
status: open
title: test.test_pathlib.PosixPathTest.test_touch_common fails on FreeBSD with ZFS
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 30 11:16:59 2013
From: report at bugs.python.org (Fabio Erculiani)
Date: Sat, 30 Nov 2013 10:16:59 +0000
Subject: [New-bugs-announce] [issue19839] bz2: regression wrt supporting
	files with trailing	garbage after EOF
Message-ID: <1385806619.04.0.329117891617.issue19839@psf.upfronthosting.co.za>


New submission from Fabio Erculiani:

In Sabayon Linux and Gentoo Linux, distro package metadata is appended at the end of bz2 files. Python 2.7, 3.1, 3.2 bz2 modules were handling the following attached file just fine, trailing garbage was simply ignored like the bunzip2 utility does.

example test code:
f = bz2.BZ2File(path, mode="rb")
data = f.read(1024)
while data:
    data = f.read(1024)
f.close()

The following code doesn't work with Python 3.3.3 anymore, at some point I receive the following exception (that comes from the bz2 module C code):

  File "/usr/lib64/python3.3/bz2.py", line 278, in read
    return self._read_block(size)
  File "/usr/lib64/python3.3/bz2.py", line 239, in _read_block
    while n > 0 and self._fill_buffer():
  File "/usr/lib64/python3.3/bz2.py", line 203, in _fill_buffer
    self._buffer = self._decompressor.decompress(rawblock)
OSError: Invalid data stream

Please restore the compatibility with bz2 files with trailing garbage after EOF.

----------
components: Library (Lib)
files: sys-libs:zlib-1.2.3-r1~1.tbz2
messages: 204793
nosy: Fabio.Erculiani
priority: normal
severity: normal
status: open
title: bz2: regression wrt supporting files with trailing garbage after EOF
versions: Python 3.3
Added file: http://bugs.python.org/file32904/sys-libs:zlib-1.2.3-r1~1.tbz2

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

From report at bugs.python.org  Sat Nov 30 14:05:40 2013
From: report at bugs.python.org (zodalahtathi)
Date: Sat, 30 Nov 2013 13:05:40 +0000
Subject: [New-bugs-announce] [issue19840] The is no way to tell shutil.move
	to ignore metadata
Message-ID: <1385816740.15.0.284400453847.issue19840@psf.upfronthosting.co.za>


New submission from zodalahtathi:

shutil.move sometimes fail when the underlining filesystem has limitations.

Here is a part of a stacktrace I'm getting :

  File "/usr/local/lib/python3.3/shutil.py", line 534, in move
    copy2(src, real_dst)
  File "/usr/local/lib/python3.3/shutil.py", line 244, in copy2
    copystat(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/local/lib/python3.3/shutil.py", line 192, in copystat
    lookup("chmod")(dst, mode, follow_symlinks=follow)
OSError: [Errno 38]

This behaviour is expected because shutil.move uses shutil.copy2 under the hood to copy file data and metadata.

However there is no way to tell shutil.move to use shutil.copy and to ignore metadata.

Maybe a new copy_metadata parameter (defaulting to True) or copy_function (like in shutil.copytree) would be an elegant solution?

----------
components: Library (Lib)
messages: 204807
nosy: zodalahtathi
priority: normal
severity: normal
status: open
title: The is no way to tell shutil.move to ignore metadata
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sat Nov 30 14:16:59 2013
From: report at bugs.python.org (Ivailo Monev)
Date: Sat, 30 Nov 2013 13:16:59 +0000
Subject: [New-bugs-announce] [issue19841] ConfigParser PEP issues
Message-ID: <1385817419.05.0.067066998342.issue19841@psf.upfronthosting.co.za>


New submission from Ivailo Monev:

There are a few PEP violations like namespace clashes, the attached patch fixes some of them thus solving a problem for me where shared library build with Nuitka segmentation faults. The patch does not make the code backwards compatible with the vars and map arguments renames as there is no way to do that and maybe the new variable names, vvars and mmap are not appropriate but you can roll your own patch with the same idea.

Cheers!

----------
components: Library (Lib)
files: ConfigParser.patch
keywords: patch
messages: 204808
nosy: Ivailo.Monev
priority: normal
severity: normal
status: open
title: ConfigParser PEP issues
versions: Python 2.7
Added file: http://bugs.python.org/file32905/ConfigParser.patch

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

From report at bugs.python.org  Sat Nov 30 14:44:36 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 30 Nov 2013 13:44:36 +0000
Subject: [New-bugs-announce] [issue19842] selectors: refactor BaseSelector
	implementation
Message-ID: <1385819076.05.0.513809645025.issue19842@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

Initially, BaseSelector was simply designed as the base implementation used by concrete ones like SelectSelector & Co.

Then BaseSelector evolved to be an ABC, but the problem is that it's really not usable as such: the register() and unregister() methods are not abstract, and instead store the fileobj -> key association in a private dictionary (_fd_to_key). Since this attribute is private, it cannot be used by third-party selectors implementation which might want to implement the ABC. Also, such implementations might not want to use a dictionay internally, and generally, inheritance should be avoided in this type of situations (since it breaks encapsulation).

In short, BaseSelector mixes up the type definition (ABC) and base implementation, which cannot be reused by subclasses anyway.

The attached patch cleans things up by making BaseSelector.{register,unregister,get_map} methods abstract (raising NotImplementedError by default).
Together with select(), those methods are the bare minimum that a conform selector implementation should provide.
get_key() still has a default implementation (atop get_map()), and so does modify() (atop register()/unregister()).

The concrete base implementation (on top of which are built SelectSelector & friends) is moved in a private _BaseSelectorImpl.

I think that's a cleaner design.

The only problem is that it makes some methods abstract, so I had to update test_telnetlib and asyncio/test_utils because they are implementing BaseSelector for mock tests.

BTW, is there a consensus on ABC names? Like AbstractSelector vs BaseSelector?

----------
components: Library (Lib)
files: selectors_base_impl.diff
keywords: needs review, patch
messages: 204809
nosy: gvanrossum, neologix, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: selectors: refactor BaseSelector implementation
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file32906/selectors_base_impl.diff

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

From report at bugs.python.org  Sat Nov 30 16:53:33 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 30 Nov 2013 15:53:33 +0000
Subject: [New-bugs-announce] [issue19843] Wait for multiple sub-processes to
	terminate
Message-ID: <1385826813.77.0.0339260517434.issue19843@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

I recently implemented this in psutil and thought it would have been a nice addition for subprocess module as well:
https://code.google.com/p/psutil/issues/detail?id=440

Patch in attachment introduces a new subprocess.wait_procs() utility function which waits for multiple processes (Popen instances) to terminate.
The use case this covers is quote common: send SIGTERM to a list of processes, wait for them to terminate, send SIGKILL as last resort:


>>> def on_terminate(proc):
...     print("process {} terminated".format(proc))
...
>>> for p in procs:
...    p.terminate()
...
>>> gone, still_alive = wait_procs(procs, timeout=3, callback=on_terminate)
>>> for p in still_alive:
...     p.kill()


Are we still in time for Python 3.4?

----------
files: wait_procs.patch
keywords: patch
messages: 204824
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: Wait for multiple sub-processes to terminate
versions: Python 3.4
Added file: http://bugs.python.org/file32912/wait_procs.patch

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

From report at bugs.python.org  Sat Nov 30 17:56:21 2013
From: report at bugs.python.org (Hanz Kanst)
Date: Sat, 30 Nov 2013 16:56:21 +0000
Subject: [New-bugs-announce] [issue19844] os.path.split fails on windows path
Message-ID: <1385830581.12.0.81004283625.issue19844@psf.upfronthosting.co.za>


Changes by Hanz Kanst <bohemia33 at gmail.com>:


----------
components: Windows
nosy: Hanz
priority: normal
severity: normal
status: open
title: os.path.split fails on windows path
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Sat Nov 30 21:54:02 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 30 Nov 2013 20:54:02 +0000
Subject: [New-bugs-announce] [issue19845] Compiling Python on Windows docs
Message-ID: <1385844842.4.0.324477828597.issue19845@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

http://docs.python.org/3/using/windows.html#compiling-python-on-windows still refers to Visual Studio 97 but there's no mention of 2010.  Can we have this updated please?

----------
assignee: docs at python
components: Documentation
messages: 204844
nosy: BreamoreBoy, docs at python
priority: normal
severity: normal
status: open
title: Compiling Python on Windows docs
versions: Python 3.4

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

From report at bugs.python.org  Sat Nov 30 22:40:45 2013
From: report at bugs.python.org (Sworddragon)
Date: Sat, 30 Nov 2013 21:40:45 +0000
Subject: [New-bugs-announce] [issue19846] print() and write() are relying
	on	sys.getfilesystemencoding() instead of sys.getdefaultencoding()
Message-ID: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>


New submission from Sworddragon:

It seems that print() and write() (and maybe other of such I/O functions) are relying on sys.getfilesystemencoding(). But these functions are not operating with filenames but with their content. In the attachments is an example script which demonstrates this problem. Here is what I get:

sworddragon at ubuntu:~/tmp$ echo $LANG
de_DE.UTF-8
sworddragon at ubuntu:~/tmp$ python3 test.py
sys.getdefaultencoding(): utf-8
sys.getfilesystemencoding(): utf-8
?
sworddragon at ubuntu:~/tmp$ LANG=C
sworddragon at ubuntu:~/tmp$ python3 test.py
sys.getdefaultencoding(): utf-8
sys.getfilesystemencoding(): ascii
Traceback (most recent call last):
  File "test.py", line 4, in <module>
    print('\xe4')
UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in position 0: ordinal not in range(128)

----------
components: IO
files: test.py
messages: 204849
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: print() and write() are relying on sys.getfilesystemencoding() instead of sys.getdefaultencoding()
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file32914/test.py

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

From report at bugs.python.org  Sat Nov 30 23:29:52 2013
From: report at bugs.python.org (Sworddragon)
Date: Sat, 30 Nov 2013 22:29:52 +0000
Subject: [New-bugs-announce] [issue19847] Setting the default
	filesystem-encoding
Message-ID: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>


New submission from Sworddragon:

sys.getfilesystemencoding() says for Unix: On Unix, the encoding is the user?s preference according to the result of nl_langinfo(CODESET), or 'utf-8' if nl_langinfo(CODESET) failed.

In my opinion relying on the locale environment is risky since filesystem-encoding != locale. This is especially the case if working on a filesystem from an external media like an external hard disk drive. Operating on multiple media can also result in different filesystem-encodings.

It would be useful if the user can make his own checks and change the default filesystem-encoding if needed.

----------
components: IO
messages: 204853
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Setting the default filesystem-encoding
type: enhancement
versions: Python 3.3

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