From report at bugs.python.org  Sun Mar  1 00:04:10 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 28 Feb 2015 23:04:10 +0000
Subject: [issue23548] TypeError in event loop finalizer, new in Python 3.4.3
In-Reply-To: <1425139981.48.0.523334940185.issue23548@psf.upfronthosting.co.za>
Message-ID: <1425164650.51.0.613407013148.issue23548@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

So this is still strange. When you do this, does it give the same exception?

>>> import signal
>>> signal.signal(signal.SIGCHLD, signal.SIG_DFL)

----------

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

From report at bugs.python.org  Sun Mar  1 00:20:49 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Feb 2015 23:20:49 +0000
Subject: [issue23551] IDLE to provide menu options for using PIP
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1425165649.48.0.725722064194.issue23551@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Raymond, I have had a very vague idea of doing something like this.  Thanks for posting something more concrete.  I share the sentiments of your last sentence.

Reading Stackoverflow, it is apparent that some people with two+ Python versions do not know that a package must be installed for each version of Python, and have less idea how to install for the non-default version.  (All I know is to cd to pythonxy, or maybe pythonxy/scripts and run pip from there, or something like that.)  Running from Idle (x.y) would take of this.

Donald: at Raymond's behest, Idle now has a menu entry to run turtledemo, a separate application that is useful to beginners, in part to make turtledemo more visible. pip_gui could easily follow the same model.  No direct interaction with the Idle shell or edit windows is needed.  If you are less familiar with tkinter than I am, I would help with the gui part.  As hinted above, I am not the one to decide on menu options and write the implementation functions.

----------

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

From report at bugs.python.org  Sun Mar  1 00:24:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Feb 2015 23:24:36 +0000
Subject: [issue20128] Re-enable test_modules_search_builtin() in test_pydoc
In-Reply-To: <1388905827.82.0.948519018287.issue20128@psf.upfronthosting.co.za>
Message-ID: <1425165876.11.0.854645226307.issue20128@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sun Mar  1 00:56:12 2015
From: report at bugs.python.org (Donald Stufft)
Date: Sat, 28 Feb 2015 23:56:12 +0000
Subject: [issue23551] IDLE to provide menu options for using PIP
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1425167772.08.0.597616818778.issue23551@psf.upfronthosting.co.za>


Donald Stufft added the comment:

I'm unlikely to have the time or motivation to do this anytime soon (just to be clear). I would be able to advise anyone who does feel like doing it the best ways to interact with pip itself though.

----------

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

From report at bugs.python.org  Sun Mar  1 01:17:58 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Sun, 01 Mar 2015 00:17:58 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425169078.09.0.553414746557.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

*ALL Android devices have /dev/ptmx (adb even assumes it)...should the *configure script be modified to skip that check if cross-compiling for *Android?

Yes, definitely. See the mods to pyconfig.h here"
https://code.google.com/p/python-for-android/wiki/CrossCompilingPython

Ignore the #define ANDROID 1.  GCC 4.8.x and later add -mandroid and/or -mbionic which defines __ANDROID__; I've been putting android-related changes under that macro.

*Cyd (and anyone else who can), do you think you could test the binaries, *too? I'll get them to you somehow. You have a real device; I have an old *real device and an emulator.

Sure...especially since the KBOX env is needed.

*Side note for Cyd: I'd advise you just use the fork of CPython you have *and just push them to GitHub:

$ git remote add origin <url of your GitHub repo with .git at the end>
$ git push --all origin -u

*That will push your changes (and every branch of CPython, I have no clue *what your branch name is, so this just does everything) to the GitHub *mirror.

I forked the Cpython repo on Github, set 3.4 as the default branch and

$git clone https://github.com/cydhaselton/cpython.git

After modifying files and/or adding dirs, copying files

$git add <modified file>

Hopefully the above was ok.

Off to read up on commits

----------

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

From report at bugs.python.org  Sun Mar  1 01:21:02 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 01 Mar 2015 00:21:02 +0000
Subject: [issue23551] IDLE to provide menu options for using PIP
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1425169262.53.0.76782510951.issue23551@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thinking a bit more, the Idle entry point could be one entry, 'Install Packages' or 'Manage Packages' on the Options menu (or maybe Help menu).  I am not sure that the new window would need a submenu, as I think everything listed in the opening post could fit in a large window.

----------

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

From report at bugs.python.org  Sun Mar  1 01:50:38 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Mar 2015 00:50:38 +0000
Subject: [issue23553] Reduce the number of comparison for range checking.
Message-ID: <1425171038.63.0.240295916037.issue23553@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Python's core is full of bound checks like this one in Objects/listobject.c:

static PyObject *
list_item(PyListObject *a, Py_ssize_t i)
{
    if (i < 0 || i >= Py_SIZE(a)) {
    ...

Abner Fog's high-level language optimization guide,  http://www.agner.org/optimize/optimizing_cpp.pdf in section 14.2 Bounds Checking, shows a way to fold this into a single check:

-    if (i < 0 || i >= Py_SIZE(a)) {
+    if ((unsigned)i >= (unsigned)(Py_SIZE(a))) {
         if (indexerr == NULL) {
             indexerr = PyUnicode_FromString(
                 "list index out of range");

The old generated assembly code looks like this:

_list_item:
    subq    $8, %rsp
    testq   %rsi, %rsi
    js  L227
    cmpq    16(%rdi), %rsi
    jl  L228
L227:
    ... <error reporting and exit > ...
L228:
    movq    24(%rdi), %rax
    movq    (%rax,%rsi,8), %rax
    addq    $1, (%rax)
    addq    $8, %rsp
    ret

The new disassembly looks like this:

_list_item:
    cmpl    %esi, 16(%rdi)
    ja  L227
    ... <error reporting and exit > ...
L227:
    movq    24(%rdi), %rax
    movq    (%rax,%rsi,8), %rax
    addq    $1, (%rax)
    ret

Note, the new code not only saves a comparison/conditional-jump pair, it also avoids the need to adjust %rsp on the way in and the way out for a net savings of four instructions along the critical path.

When we have good branch prediction, the current approach is very low cost; however, Abner Fog's recommendation is never more expensive, is sometimes cheaper, saves a possible misprediction, and reduces the total code generated.  All in all, it is a net win.

I recommend we put in a macro of some sort so that this optimization gets expressed exactly once in the code and so that it has a good clear name with an explanation of what it does.

----------
components: Interpreter Core
messages: 236928
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Reduce the number of comparison for range checking.
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Sun Mar  1 02:26:36 2015
From: report at bugs.python.org (Demian Brecht)
Date: Sun, 01 Mar 2015 01:26:36 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425139994.56.0.126460216247.issue23539@psf.upfronthosting.co.za>
Message-ID: <DBF5286C-CD7C-4561-94C5-1EA5E8779ADC@gmail.com>


Demian Brecht added the comment:

> My feeling is that '' implies "present but empty" (so should have a content-length set to zero), whereas None implies "missing" (so should only have a content-length header set to zero if the method is expecting a body.

Although I understand your thinking here, I think that bodies that are either None or empty string should be treated identically. Whether or not the Content-Length header is set should be dependent on the method used.

>From a client standpoint, there?s no difference between sending a body with a value of None and an empty string (the latter will get further down the call stack, but no data is actually sent over the wire).

Likewise from the server standpoint, there is no functional difference between a missing or empty body. However, there?s still the possibility of unexpected behaviour due to the inclusion of a Content-Length header for a method not expecting it.

In light of that, I think that HTTPConnection(?example.com?).request(?GET?, ?/?, ??) and HTTPConnection(?example.com?).request(?GET?, ?/?) should result in identical headers with no Content-Length set.

If someone /really/ wants to set the Content-Length header for a method that doesn?t expect it, they still have the ability to do so: HTTPConnection(?example.com?).request(?GET?, ?/?, ??, {?Content-Length?: 0}). However, if the default behaviour is to include the Content-Length header for an empty string, the user then has to change what they?re sending to be None instead of empty string even though they should be functionally equivalent.

----------

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

From report at bugs.python.org  Sun Mar  1 02:30:06 2015
From: report at bugs.python.org (Demian Brecht)
Date: Sun, 01 Mar 2015 01:30:06 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425161259.96.0.947771337128.issue23539@psf.upfronthosting.co.za>
Message-ID: <25D26DD8-0EDF-4FD9-8D00-42F026420854@gmail.com>


Demian Brecht added the comment:

> I actually consider this a fix for the fix in 14721, rather than a new feature.

+1

----------

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

From report at bugs.python.org  Sun Mar  1 06:39:46 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Mar 2015 05:39:46 +0000
Subject: [issue23553] Reduce the number of comparison for range checking.
In-Reply-To: <1425171038.63.0.240295916037.issue23553@psf.upfronthosting.co.za>
Message-ID: <1425188386.54.0.539730831229.issue23553@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, this is a technique commonly used in STL implementations. This is why sizes and indices in STL are unsigned.

But in CPython implementation sizes are signed (Py_ssize_t). The problem with using this optimization (rather low-level than high-level) is that we need to know unsigned version of the type of compared values.

> -    if (i < 0 || i >= Py_SIZE(a)) {
> +    if ((unsigned)i >= (unsigned)(Py_SIZE(a))) {

Here is a bug. The type of i and Py_SIZE(a) is Py_ssize_t, so when casted to unsigned int, highest bits are lost. The correct casting type is size_t.

In changeset 5942fd9ab335 you introduced a bug.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sun Mar  1 06:59:32 2015
From: report at bugs.python.org (Giovanni Cannata)
Date: Sun, 01 Mar 2015 05:59:32 +0000
Subject: [issue23554] EchoServerClientProtocol class should be called
 EchoServerProtocol
Message-ID: <1425189572.41.0.939168822868.issue23554@psf.upfronthosting.co.za>


New submission from Giovanni Cannata:

In 18.5.4.3.2. TCP echo server protocol the class in the example code is called EchoServerClientProtocol.  It should be EchoServerProtocol. (The client protocol example is correctly called EchoClientProtocol).

----------
assignee: docs at python
components: Documentation
messages: 236932
nosy: docs at python, gc
priority: normal
severity: normal
status: open
title: EchoServerClientProtocol class should be called EchoServerProtocol
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar  1 07:09:15 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Mar 2015 06:09:15 +0000
Subject: [issue23553] Reduce the number of comparison for range checking.
In-Reply-To: <1425171038.63.0.240295916037.issue23553@psf.upfronthosting.co.za>
Message-ID: <1425190155.04.0.477629111053.issue23553@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> The type of i and Py_SIZE(a) is Py_ssize_t, so when casted to 
> unsigned int, highest bits are lost. The correct casting type is size_t.

Yes, I had just seen that a early today and deciding whether to substitute size_t for the unsigned cast or whether to just revert.   I believe size_t is guaranteed to hold any array index and that a cast from non-negative Py_ssize_t would not lose bits.

> But in CPython implementation sizes are signed (Py_ssize_t). 
> The problem with using this optimization (rather low-level 
> than high-level) is that we need to know unsigned version of
> the type of compared values.

Wouldn't size_t always work for Py_ssize_t?

----------

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

From report at bugs.python.org  Sun Mar  1 07:15:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Mar 2015 06:15:23 +0000
Subject: [issue23553] Reduce the number of comparison for range checking.
In-Reply-To: <1425171038.63.0.240295916037.issue23553@psf.upfronthosting.co.za>
Message-ID: <1425190523.66.0.548612558362.issue23553@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Wouldn't size_t always work for Py_ssize_t?

Yes. But it wouldn't work for say off_t.

The consistent way is always use size_t instead of Py_ssize_t. But this boat has sailed.

----------

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

From report at bugs.python.org  Sun Mar  1 07:19:20 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Mar 2015 06:19:20 +0000
Subject: [issue23553] Reduce the number of comparison for range checking.
In-Reply-To: <1425171038.63.0.240295916037.issue23553@psf.upfronthosting.co.za>
Message-ID: <1425190760.34.0.12520166551.issue23553@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file38281/size_t.diff

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

From report at bugs.python.org  Sun Mar  1 07:21:43 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Mar 2015 06:21:43 +0000
Subject: [issue23553] Reduce the number of comparison for range checking.
In-Reply-To: <1425171038.63.0.240295916037.issue23553@psf.upfronthosting.co.za>
Message-ID: <1425190903.2.0.814725974688.issue23553@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> But it wouldn't work for say off_t.

I'm only proposing a bounds checking macro for the Py_ssize_t case which is what all of our IndexError tests look for.

Also, please look at the attached deque fix.

----------

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

From report at bugs.python.org  Sun Mar  1 07:34:37 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 01 Mar 2015 06:34:37 +0000
Subject: [issue20204] pydocs fails for some C implemented classes
In-Reply-To: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za>
Message-ID: <1425191677.59.0.789685270385.issue20204@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

ImportWarning is slightly different - it's aimed at issues that happen during the operation of the import machinery itself.

This isn't that - it's a warning related to the extension module actually initialising itself, so it's akin to a warning issued due to the behaviour of top level module source code, rather than by the import system.

----------

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

From report at bugs.python.org  Sun Mar  1 07:44:07 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 01 Mar 2015 06:44:07 +0000
Subject: [issue21293] Remove "capsule hack" from object.c?
In-Reply-To: <1397778953.55.0.677894894827.issue21293@psf.upfronthosting.co.za>
Message-ID: <1425192247.01.0.674917059826.issue21293@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I'm inclined to suggest you try removing it and see what happens on the buildbots.

I remember we used to have a few interesting challenges at my old job convincing Visual Studio that we really were using a type definition and we should export it from the DLL. That was way back in the VC6 days though, so I expect the situation has improved by now.

Added Steve to the nosy list to see if he's aware of any current Windows specific reasons this might be needed.

----------
nosy: +steve.dower

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

From report at bugs.python.org  Sun Mar  1 07:59:06 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Mar 2015 06:59:06 +0000
Subject: [issue23553] Reduce the number of comparison for range checking.
In-Reply-To: <1425171038.63.0.240295916037.issue23553@psf.upfronthosting.co.za>
Message-ID: <1425193146.09.0.416239564917.issue23553@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It looks correct to me, but I would change type and introduce few new variables to get rid of casts.

----------

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

From report at bugs.python.org  Sun Mar  1 08:14:55 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Mar 2015 07:14:55 +0000
Subject: [issue23553] Reduce the number of comparison for range checking.
In-Reply-To: <1425171038.63.0.240295916037.issue23553@psf.upfronthosting.co.za>
Message-ID: <1425194095.87.0.062322365401.issue23553@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Attaching a diff for the bounds checking Objects/listobject.c.
It looks like elsewhere in that file, (size_t) casts are done
for various reasons.

----------
Added file: http://bugs.python.org/file38282/bounds_check_list.diff

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

From report at bugs.python.org  Sun Mar  1 08:50:31 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Mar 2015 07:50:31 +0000
Subject: [issue23553] Reduce the number of comparison for range checking.
In-Reply-To: <1425171038.63.0.240295916037.issue23553@psf.upfronthosting.co.za>
Message-ID: <1425196231.21.0.0900453588587.issue23553@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Also attaching a bounds checking patch for deques.

----------
Added file: http://bugs.python.org/file38283/bounds_check_deque.diff

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

From report at bugs.python.org  Sun Mar  1 09:04:30 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Mar 2015 08:04:30 +0000
Subject: [issue20204] pydocs fails for some C implemented classes
In-Reply-To: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za>
Message-ID: <20150301080427.34498.91537@psf.io>


Roundup Robot added the comment:

New changeset a192cc5a63be by Serhiy Storchaka in branch '3.4':
Issue #20204: Added the __module__ attribute to _tkinter classes.
https://hg.python.org/cpython/rev/a192cc5a63be

New changeset 3244142eeafb by Serhiy Storchaka in branch 'default':
Issue #20204: Added the __module__ attribute to _tkinter classes.
https://hg.python.org/cpython/rev/3244142eeafb

New changeset d6dff5a5290a by Serhiy Storchaka in branch 'default':
Issue #20204: Deprecation warning is now raised for builtin type without the
https://hg.python.org/cpython/rev/d6dff5a5290a

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Mar  1 09:13:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Mar 2015 08:13:59 +0000
Subject: [issue23553] Reduce the number of comparison for range checking.
In-Reply-To: <1425171038.63.0.240295916037.issue23553@psf.upfronthosting.co.za>
Message-ID: <1425197639.88.0.107377725706.issue23553@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Parenthesis around Py_SIZE() are redundant.

Are there any benchmarking results that show a speed up? Such microoptimization makes sense in tight loops, but optimized source code looks more cumbersome and errorprone.

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

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

From report at bugs.python.org  Sun Mar  1 09:33:44 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Mar 2015 08:33:44 +0000
Subject: [issue23290] Faster set copying
In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za>
Message-ID: <1425198824.06.0.751618242185.issue23290@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping. The last patch doesn't add more lookkey variants, it uses existing function.

----------

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

From report at bugs.python.org  Sun Mar  1 09:34:29 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Mar 2015 08:34:29 +0000
Subject: [issue23552] Have timeit warn about runs that are not independent of
 each other
In-Reply-To: <1425156172.0.0.931116052614.issue23552@psf.upfronthosting.co.za>
Message-ID: <1425198869.93.0.0788161378599.issue23552@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

How it looks?

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sun Mar  1 09:36:42 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Mar 2015 08:36:42 +0000
Subject: [issue23553] Reduce the number of comparison for range checking.
In-Reply-To: <1425171038.63.0.240295916037.issue23553@psf.upfronthosting.co.za>
Message-ID: <1425199002.77.0.00010601604597.issue23553@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I think the source in listobject.c would be benefit from a well-named macro for this.  That would provide the most clarity.   For deques, I'll just put in the simple patch because it only applies to a place that is already doing unsigned arithmetic/comparisons.

FWIW, I don't usually use benchmarking on these kinds of changes.  The generated assembler is sufficiently informative.   Benchmarking each tiny change risks getting trapped in a local minimum.  Also, little timeit tests tend to branch the same way every time (which won't show the cost of prediction misses) and it tends to have all code and data in cache (so you don't see the effects of cache misses) and it risks tuning to a single processor (in my case a haswell).   Instead, I look at the code generated by GCC and CLang to see that it does less work.

----------

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

From report at bugs.python.org  Sun Mar  1 09:38:09 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Mar 2015 08:38:09 +0000
Subject: [issue23553] Reduce the number of comparison for range checking.
In-Reply-To: <1425171038.63.0.240295916037.issue23553@psf.upfronthosting.co.za>
Message-ID: <20150301083806.10064.57522@psf.io>


Roundup Robot added the comment:

New changeset 1e89094998b2 by Raymond Hettinger in branch 'default':
Issue #23553:  Use an unsigned cast to tighten-up the bounds checking logic.
https://hg.python.org/cpython/rev/1e89094998b2

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Mar  1 09:47:47 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Mar 2015 08:47:47 +0000
Subject: [issue23290] Faster set copying
In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za>
Message-ID: <1425199667.14.0.821346099143.issue23290@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I still intend to apply some variant of your patch.  Am still looking at the options.

----------
priority: normal -> low

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

From report at bugs.python.org  Sun Mar  1 09:48:56 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Mar 2015 08:48:56 +0000
Subject: [issue23553] Reduce the number of comparison for range checking.
In-Reply-To: <1425199002.77.0.00010601604597.issue23553@psf.upfronthosting.co.za>
Message-ID: <4346711.S6ZHtEdQCL@raxxla>


Serhiy Storchaka added the comment:

My point is that if the benefit is too small (say < 5% in microbenchmarks), it 
is not worth code churning. Actually my bar for microbenchmarks is higher, 
about 20%.

----------

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

From report at bugs.python.org  Sun Mar  1 09:54:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Mar 2015 08:54:17 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425200057.94.0.297742605673.issue21619@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The test still sporadically fails on Windows:

http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/9323/steps/test/logs/stdio
======================================================================
FAIL: test_broken_pipe_cleanup (test.test_subprocess.ContextManagerTests)
Broken pipe error should not prevent wait() (Issue 21619)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_subprocess.py", line 2515, in test_broken_pipe_cleanup
    self.assertRaises(OSError, proc.__exit__, None, None, None)
AssertionError: OSError not raised by __exit__

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

----------
status: closed -> open

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

From report at bugs.python.org  Sun Mar  1 10:10:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Mar 2015 09:10:30 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425201030.31.0.290282418548.issue21619@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Why not ignoring BrokenPipeError like communicate()?

Why communicate() ignores BrokenPipeError?

----------

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

From report at bugs.python.org  Sun Mar  1 10:31:25 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Mar 2015 09:31:25 +0000
Subject: [issue10963] "subprocess" can raise OSError (EPIPE) when
 communicating with short-lived processes
In-Reply-To: <1295555014.31.0.879687826689.issue10963@psf.upfronthosting.co.za>
Message-ID: <1425202285.38.0.917413364675.issue10963@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

self.stdout.close() also can fail with EPIPE or EINVAL if the stream is buffered (text streams are buffered). I.e. communicate() in text mode can loss the data. See also issue21619.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sun Mar  1 10:32:39 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Mar 2015 09:32:39 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425202359.38.0.35629696124.issue21619@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It was added in issue10963. I don't know if this way is applicable to this issue.

----------
nosy: +dmalcolm, pitrou, rosslagerwall
resolution: fixed -> 
stage: resolved -> 

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

From report at bugs.python.org  Sun Mar  1 11:10:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Mar 2015 10:10:54 +0000
Subject: [issue20128] Re-enable test_modules_search_builtin() in test_pydoc
In-Reply-To: <1388905827.82.0.948519018287.issue20128@psf.upfronthosting.co.za>
Message-ID: <1425204654.41.0.335618487034.issue20128@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't know what errors was on FreeBSD (logs are no longer available), but these tests modify sys.path and the list of weakrefs to logging handlers. They also require relative long time to run.

----------

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

From report at bugs.python.org  Sun Mar  1 12:04:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Mar 2015 11:04:50 +0000
Subject: [issue22364] Improve some re error messages using regex for hints
In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za>
Message-ID: <1425207890.96.0.440947142362.issue22364@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could anyone please make a review? This patch is a prerequisite of other patches.

----------

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

From report at bugs.python.org  Sun Mar  1 12:14:58 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Mar 2015 11:14:58 +0000
Subject: [issue20128] Re-enable test_modules_search_builtin() in test_pydoc
In-Reply-To: <1388905827.82.0.948519018287.issue20128@psf.upfronthosting.co.za>
Message-ID: <1425208498.54.0.689109473262.issue20128@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

As said koobs, the full log was attached to issue20123.

----------

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

From report at bugs.python.org  Sun Mar  1 12:32:36 2015
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 01 Mar 2015 11:32:36 +0000
Subject: [issue23555] behavioural change in argparse set_defaults in python
 2.7.9
Message-ID: <1425209556.02.0.589190597278.issue23555@psf.upfronthosting.co.za>


New submission from Matthias Klose:

seen with ceph, https://launchpad.net/bugs/1413321

This appears to be a regression in the argparse package in python; under trusty ceph-disk works just fine, however in vivid, the cluster attribute remains unset (despite having a default of 'ceph'). Attached python demonstrates the problem.

----------
components: Library (Lib)
files: test.py
messages: 236956
nosy: doko
priority: normal
severity: normal
status: open
title: behavioural change in argparse set_defaults in python 2.7.9
versions: Python 2.7
Added file: http://bugs.python.org/file38284/test.py

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

From report at bugs.python.org  Sun Mar  1 12:34:50 2015
From: report at bugs.python.org (SilentGhost)
Date: Sun, 01 Mar 2015 11:34:50 +0000
Subject: [issue23555] behavioural change in argparse set_defaults in python
 2.7.9
In-Reply-To: <1425209556.02.0.589190597278.issue23555@psf.upfronthosting.co.za>
Message-ID: <1425209690.29.0.584964593396.issue23555@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +bethard

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

From report at bugs.python.org  Sun Mar  1 12:49:40 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Mar 2015 11:49:40 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425210580.89.0.701658547786.issue21619@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun Mar  1 12:58:22 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Mar 2015 11:58:22 +0000
Subject: [issue20204] pydocs fails for some C implemented classes
In-Reply-To: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za>
Message-ID: <1425211102.94.0.605334887069.issue20204@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun Mar  1 13:14:32 2015
From: report at bugs.python.org (Antoine Amarilli)
Date: Sun, 01 Mar 2015 12:14:32 +0000
Subject: [issue23556] Scope for raise without argument is different in Python
 2 and 3
Message-ID: <1425212072.31.0.66074782686.issue23556@psf.upfronthosting.co.za>


New submission from Antoine Amarilli:

Hello,

Python 2.7.8 and Python 3.4.2 (from Debian testing) have a different behavior on the attached file. Python 2 raises "bar", Python 3 raises "foo".

I can't find an adequate explanation in the documentation for this behavior difference. It probably relates to https://docs.python.org/3/reference/compound_stmts.html#try (search for "When an exception has been assigned") but this is unsatisfying because it only talks about the "as target" construction, which is not used in the example.

I think that at least the documentation should be clarified to point out what "raise" without arguments will do. Currently the documentation of this in Python 2 and 3 is the same even though the behavior is different https://docs.python.org/2/reference/simple_stmts.html#raise https://docs.python.org/3/reference/simple_stmts.html#raise.

Note: this question was originally asked on SO: http://stackoverflow.com/q/28698622/414272. I reported this as a bug at Terry Jan Reedy's request https://stackoverflow.com/q/28698622/414272#comment45707744_28698622.

----------
files: raise.py
messages: 236957
nosy: a3nm
priority: normal
severity: normal
status: open
title: Scope for raise without argument is different in Python 2 and 3
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file38285/raise.py

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

From report at bugs.python.org  Sun Mar  1 13:15:21 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 01 Mar 2015 12:15:21 +0000
Subject: [issue23553] Reduce the number of comparison for range checking.
In-Reply-To: <1425171038.63.0.240295916037.issue23553@psf.upfronthosting.co.za>
Message-ID: <1425212121.25.0.453863854346.issue23553@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun Mar  1 13:17:22 2015
From: report at bugs.python.org (Jakub Klama)
Date: Sun, 01 Mar 2015 12:17:22 +0000
Subject: [issue23557] Misc/SpecialBuilds.txt contains outdated information
 about PYMALLOC_DEBUG
Message-ID: <1425212242.29.0.401382556458.issue23557@psf.upfronthosting.co.za>


New submission from Jakub Klama:

Section describing block layout under PYMALLOC_DEBUG is wrong - it doesn't contain information about API type byte instead of one of forbidden bytes. That may lead to wrong assumption that one of forbidden bytes is being overwritten until you dig into obmalloc.c code.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 236958
nosy: Jakub Klama, docs at python
priority: normal
severity: normal
status: open
title: Misc/SpecialBuilds.txt contains outdated information about PYMALLOC_DEBUG
versions: Python 2.7

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

From report at bugs.python.org  Sun Mar  1 13:23:21 2015
From: report at bugs.python.org (SilentGhost)
Date: Sun, 01 Mar 2015 12:23:21 +0000
Subject: [issue23556] Scope for raise without argument is different in Python
 2 and 3
In-Reply-To: <1425212072.31.0.66074782686.issue23556@psf.upfronthosting.co.za>
Message-ID: <1425212601.86.0.499350241247.issue23556@psf.upfronthosting.co.za>


SilentGhost added the comment:

There is this bit in https://docs.python.org/3/library/exceptions.html : 

> When raising a new exception (rather than using a bare raise to re-raise the exception currently being handled),...

I presume this can be also suitable for tutorial if it's not already there.

----------
components: +Interpreter Core
nosy: +SilentGhost

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

From report at bugs.python.org  Sun Mar  1 13:26:36 2015
From: report at bugs.python.org (SilentGhost)
Date: Sun, 01 Mar 2015 12:26:36 +0000
Subject: [issue23556] Scope for raise without argument is different in Python
 2 and 3
In-Reply-To: <1425212072.31.0.66074782686.issue23556@psf.upfronthosting.co.za>
Message-ID: <1425212796.4.0.932208129458.issue23556@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +collinwinter

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

From report at bugs.python.org  Sun Mar  1 14:26:49 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 Mar 2015 13:26:49 +0000
Subject: [issue23548] TypeError in event loop finalizer, new in Python 3.4.3
In-Reply-To: <1425164650.51.0.613407013148.issue23548@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbqjuVH1pXuhZy-_aEcgJ-Pto8MVG0t614P7=jBd-WFYg@mail.gmail.com>


STINNER Victor added the comment:

I'm aware of the issue but I would prefer to not fix it.

The first problem is that you didn't close the event loop. I modified
recently the doc to explain at the begining that you should develop in the
debug mode. In this mode, you will see a warning if you don't close
explicitly the event loop.

The signal issue is that the event loop is closed very late during Python
finalization, and attributes of the signal module are already cleared.

Are you ok to not workaround this specific issue?

Closing an event loop implicitly late can lead to other various bugs.

----------

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

From report at bugs.python.org  Sun Mar  1 14:30:10 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 Mar 2015 13:30:10 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1425201030.31.0.290282418548.issue21619@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa=qrgGXadbnzgv3Ene9YcAcNjPmHtCLeGxQUbHh5v4Wg@mail.gmail.com>


STINNER Victor added the comment:

Le dimanche 1 mars 2015, Serhiy Storchaka <report at bugs.python.org> a ?crit :
>
> Why communicate() ignores BrokenPipeError?
>

It's more convinient. There is nothing useful you can do on pipe error in
communicate().

For __exit__, what do you want to on broken pipe error? I did't check yet:
the process always exit after __exit__?

----------

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

From report at bugs.python.org  Sun Mar  1 14:33:46 2015
From: report at bugs.python.org (Ismail Donmez)
Date: Sun, 01 Mar 2015 13:33:46 +0000
Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1425216826.47.0.864702627613.issue10716@psf.upfronthosting.co.za>


Ismail Donmez added the comment:

Any update on this? Would be nice to have this for 3.5 release.

----------
nosy: +cartman

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

From report at bugs.python.org  Sun Mar  1 14:35:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Mar 2015 13:35:26 +0000
Subject: [issue20128] Re-enable test_modules_search_builtin() in test_pydoc
In-Reply-To: <1388905827.82.0.948519018287.issue20128@psf.upfronthosting.co.za>
Message-ID: <1425216926.33.0.899387129106.issue20128@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

With test_synopsis_sourceless and test_non_ascii there were different issues, related to -OO. Fixed in changesets 663a83c1d42d, d7b3e722152d, 94edd0ef4c2a.

----------

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

From report at bugs.python.org  Sun Mar  1 14:48:43 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Mar 2015 13:48:43 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425217723.62.0.964041600428.issue21619@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

When you write to the file you don't want the error was silently ignored.

    with open(filename, 'w') as f:
        f.write(content)

And also I don't want the error was silently ignored when write to the subprocess.

    with subprocess.Popen(cmd, universal_newlines=True, stdin=subprocess.PIPE) as p:
        p.stdin.write(content)

----------

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

From report at bugs.python.org  Sun Mar  1 15:01:34 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 01 Mar 2015 14:01:34 +0000
Subject: [issue23555] behavioural change in argparse set_defaults in python
 2.7.9
In-Reply-To: <1425209556.02.0.589190597278.issue23555@psf.upfronthosting.co.za>
Message-ID: <1425218494.89.0.201223885019.issue23555@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy: +paul.j3

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

From report at bugs.python.org  Sun Mar  1 16:50:58 2015
From: report at bugs.python.org (Ryan Neve)
Date: Sun, 01 Mar 2015 15:50:58 +0000
Subject: [issue23558] Unable to install Python 3.4.3 amd64 on Windows 8.1
Message-ID: <1425225058.12.0.9521786559.issue23558@psf.upfronthosting.co.za>


New submission from Ryan Neve:

Much like issue 22648. Windows 8.1, I had version 3.4.1 and installed 3.4.3 without first uninstalling earlier version. Tried uninstalling older versions and it failed with:
 A program required for this install to complete could not be run.

Windows uninstall window showing 3.4.3 installed when it isn't really.
Tried re-installing 3.4.1 to then uninstall it, but install failed as well. Also tried repair, but that failed as well. Nothing will install or uninstall now. stuck.

----------
components: Installation, Windows
files: log.txt
messages: 236965
nosy: Ryan Neve, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Unable to install Python 3.4.3 amd64 on Windows 8.1
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file38286/log.txt

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

From report at bugs.python.org  Sun Mar  1 17:07:00 2015
From: report at bugs.python.org (Ryan Neve)
Date: Sun, 01 Mar 2015 16:07:00 +0000
Subject: [issue23558] Unable to install Python 3.4.3 amd64 on Windows 8.1
In-Reply-To: <1425225058.12.0.9521786559.issue23558@psf.upfronthosting.co.za>
Message-ID: <1425226020.38.0.133330203373.issue23558@psf.upfronthosting.co.za>


Ryan Neve added the comment:

Turns out I had accidentally installed 3.4.3 32 bit over 3.4.1 64 bit. I re-installed 3.4.1 32 bit, then un-installed it, then I was able to install 3.4.1 x64.

I also tried installing  and un-installing 3.5 which worked fine but didn't fix anything.

----------

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

From report at bugs.python.org  Sun Mar  1 17:07:09 2015
From: report at bugs.python.org (James Rutherford)
Date: Sun, 01 Mar 2015 16:07:09 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <1425226029.41.0.646585210296.issue23539@psf.upfronthosting.co.za>


James Rutherford added the comment:

>> My feeling is that '' implies "present but empty" (so should have a content-length set to zero), whereas None implies "missing" (so should only have a content-length header set to zero if the method is expecting a body.
> ...
> In light of that, I think that HTTPConnection(?example.com?).request(?GET?, ?/?, ??) and HTTPConnection(?example.com?).request(?GET?, ?/?) should result in identical headers with no Content-Length set.

I get your reasoning here, but I wonder if that goes beyond the scope of this issue? My initial thinking was the same, but then realised that was inconsistent with the current behaviour. For example, a GET with '' in the body already sets content-length: 0, but a GET with None for the body doesn't set a content length at all. I haven't changed this behaviour in my patch, except for PUT, POST, and PATCH where None and '' are now equivalent for those methods.

----------

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

From report at bugs.python.org  Sun Mar  1 18:00:36 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 01 Mar 2015 17:00:36 +0000
Subject: [issue20210] Provide configure options to enable/disable Python
 modules and extensions
In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za>
Message-ID: <1425229236.34.0.327824171557.issue20210@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Thomas do you intend following this up as people certainly seem interested?

----------

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

From report at bugs.python.org  Sun Mar  1 18:04:27 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 01 Mar 2015 17:04:27 +0000
Subject: [issue6701] Make custom xmlrpc extension easier
In-Reply-To: <1250240628.37.0.491365957246.issue6701@psf.upfronthosting.co.za>
Message-ID: <1425229467.62.0.793178684905.issue6701@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy: +loewis
versions: +Python 3.5 -Python 3.2

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

From report at bugs.python.org  Sun Mar  1 18:28:57 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 01 Mar 2015 17:28:57 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
 on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1425230937.88.0.557692957078.issue8576@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

find_unused_port is only defined in test.support. It is tested in test.test_support.

This solution might not be ideal but if it ain't broke, don't fix it?

----------

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

From report at bugs.python.org  Sun Mar  1 18:30:10 2015
From: report at bugs.python.org (Demian Brecht)
Date: Sun, 01 Mar 2015 17:30:10 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425226029.41.0.646585210296.issue23539@psf.upfronthosting.co.za>
Message-ID: <B0E6F676-D230-4B91-9347-F9D46D95D19F@gmail.com>


Demian Brecht added the comment:

> but I wonder if that goes beyond the scope of this issue?

I think it?s worthwhile to fix it while you?re already working on the logic there. I?d consider Content-Type being set for methods not expecting it as a (very) minor bug and it?s better to clear up the inconsistent behaviour. That said, it /is/ breaking backwards compatibility (however slightly) and would likely need to get sign-off from a couple core devs.

----------

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

From report at bugs.python.org  Sun Mar  1 19:27:37 2015
From: report at bugs.python.org (Demian Brecht)
Date: Sun, 01 Mar 2015 18:27:37 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <1425234457.81.0.213221977711.issue23539@psf.upfronthosting.co.za>


Demian Brecht added the comment:

+David, Senthil: Thoughts on this?

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

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

From report at bugs.python.org  Sun Mar  1 19:29:10 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 01 Mar 2015 18:29:10 +0000
Subject: [issue4071] ntpath.abspath fails for long str paths
In-Reply-To: <1223425635.48.0.940202056696.issue4071@psf.upfronthosting.co.za>
Message-ID: <1425234550.15.0.836554803041.issue4071@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Can we close this as I'm not aware of any possible way to fix this?  See also issue1776160.

----------
nosy: +steve.dower, tim.golden, zach.ware

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

From report at bugs.python.org  Sun Mar  1 20:13:55 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 01 Mar 2015 19:13:55 +0000
Subject: [issue20408] memoryview() constructor documentation error
In-Reply-To: <1390823591.54.0.904712473888.issue20408@psf.upfronthosting.co.za>
Message-ID: <1425237235.75.0.341725637965.issue20408@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I agree that "obj" would be nicer.  On the other hand we explicitly
test for "object" in the tests, help(memoryview) says "object" and pypy
accepts "object".

Also, I think there may be other instances in the tree where reserved
names are used for parameters.

----------
nosy: +skrah

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

From report at bugs.python.org  Sun Mar  1 20:52:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Mar 2015 19:52:18 +0000
Subject: [issue22791] datetime.utcfromtimestamp() shoud have option for create
 tz aware datetime
In-Reply-To: <1415090680.18.0.893315125162.issue22791@psf.upfronthosting.co.za>
Message-ID: <20150301195215.16426.22754@psf.io>


Roundup Robot added the comment:

New changeset 4a590c66070d by Alexander Belopolsky in branch 'default':
Closes issue #22791: Improved datetime from timestamp methods documentation.
https://hg.python.org/cpython/rev/4a590c66070d

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Mar  1 20:53:17 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 01 Mar 2015 19:53:17 +0000
Subject: [issue22791] datetime.utcfromtimestamp() shoud have option for create
 tz aware datetime
In-Reply-To: <1415090680.18.0.893315125162.issue22791@psf.upfronthosting.co.za>
Message-ID: <1425239597.8.0.0855129984136.issue22791@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Mar  1 20:56:57 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 01 Mar 2015 19:56:57 +0000
Subject: [issue22752] incorrect time.timezone value
In-Reply-To: <1414506398.58.0.3585243804.issue22752@psf.upfronthosting.co.za>
Message-ID: <1425239817.16.0.143661920525.issue22752@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
status: open -> closed

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

From report at bugs.python.org  Sun Mar  1 20:58:23 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 01 Mar 2015 19:58:23 +0000
Subject: [issue22840] strpdate('20141110', '%Y%m%d%H%S') returns wrong date
In-Reply-To: <1415656891.03.0.356837597091.issue22840@psf.upfronthosting.co.za>
Message-ID: <1425239903.25.0.455730896105.issue22840@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Mar  1 21:08:31 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 Mar 2015 20:08:31 +0000
Subject: [issue7830] Flatten nested functools.partial
In-Reply-To: <1265051251.66.0.305258896073.issue7830@psf.upfronthosting.co.za>
Message-ID: <20150301200828.77550.19718@psf.io>


Roundup Robot added the comment:

New changeset 7839681ca931 by Alexander Belopolsky in branch 'default':
Issue #7830: Flatten nested functools.partial.
https://hg.python.org/cpython/rev/7839681ca931

----------
nosy: +python-dev

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

From report at bugs.python.org  Sun Mar  1 21:09:11 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 01 Mar 2015 20:09:11 +0000
Subject: [issue7830] Flatten nested functools.partial
In-Reply-To: <1265051251.66.0.305258896073.issue7830@psf.upfronthosting.co.za>
Message-ID: <1425240551.39.0.507961942035.issue7830@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Mar  1 21:14:57 2015
From: report at bugs.python.org (Ian Cordasco)
Date: Sun, 01 Mar 2015 20:14:57 +0000
Subject: [issue23476] SSL cert verify fail for "www.verisign.com"
In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za>
Message-ID: <1425240897.74.0.794700343976.issue23476@psf.upfronthosting.co.za>


Ian Cordasco added the comment:

So it seems like https://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=3621 includes a fix that we may be able to update Python to use (safely) by default. If we don't then this will continue to be an issue.

Other references:

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

For now RedHat is keeping the 1024-bit certificates around for backwards compatibility and only because that option isn't set by default.

----------

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

From report at bugs.python.org  Sun Mar  1 21:18:22 2015
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 01 Mar 2015 20:18:22 +0000
Subject: [issue23476] SSL cert verify fail for "www.verisign.com"
In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za>
Message-ID: <1425241102.27.0.648368761694.issue23476@psf.upfronthosting.co.za>


Donald Stufft added the comment:

There actually *is* an API that can be set that will cause OpenSSL to use the shortest trust path it can, however it's only available in OpenSSL 1.0.2+ which means it'll solve it for a handful of people but not the bulk of people.

----------

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

From report at bugs.python.org  Sun Mar  1 21:19:45 2015
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 01 Mar 2015 20:19:45 +0000
Subject: [issue23476] SSL cert verify fail for "www.verisign.com"
In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za>
Message-ID: <1425241185.9.0.751806091496.issue23476@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

I'm attaching a patch that does what Donald suggests.

----------
keywords: +patch
Added file: http://bugs.python.org/file38287/store.diff

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

From report at bugs.python.org  Sun Mar  1 21:55:12 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 Mar 2015 20:55:12 +0000
Subject: [issue7830] Flatten nested functools.partial
In-Reply-To: <1425240551.42.0.220529919983.issue7830@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwax=axXGu4zmtUimBw2baw=kQmikEyL5rMexfVGkYKnsw@mail.gmail.com>


STINNER Victor added the comment:

I forgot this issue. Thanks for the enhancement. It will help asyncio for
example. It was surprised the first time i tested nested partial.

----------

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

From report at bugs.python.org  Sun Mar  1 22:15:14 2015
From: report at bugs.python.org (johnkw)
Date: Sun, 01 Mar 2015 21:15:14 +0000
Subject: [issue23531] SSL operations cause entire process to hang
In-Reply-To: <1424980715.38.0.880892658959.issue23531@psf.upfronthosting.co.za>
Message-ID: <1425244514.25.0.123933308964.issue23531@psf.upfronthosting.co.za>


Changes by johnkw <johnkw at gmail.com>:


Added file: http://bugs.python.org/file38288/sslbug.py

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

From report at bugs.python.org  Sun Mar  1 22:16:06 2015
From: report at bugs.python.org (johnkw)
Date: Sun, 01 Mar 2015 21:16:06 +0000
Subject: [issue23531] SSL operations cause entire process to hang
In-Reply-To: <1424980715.38.0.880892658959.issue23531@psf.upfronthosting.co.za>
Message-ID: <1425244566.96.0.823953540197.issue23531@psf.upfronthosting.co.za>


johnkw added the comment:

New testcase submitted without "requests". Don't have access to the non-cygwin build so don't know there.

----------

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

From report at bugs.python.org  Sun Mar  1 22:37:09 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 01 Mar 2015 21:37:09 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1425245829.62.0.305557766871.issue13312@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I believe that this can be closed as the test code was changed completely in #17960.

----------

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

From report at bugs.python.org  Sun Mar  1 22:39:27 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 01 Mar 2015 21:39:27 +0000
Subject: [issue23556] Scope for raise without argument is different in Python
 2 and 3
In-Reply-To: <1425212072.31.0.66074782686.issue23556@psf.upfronthosting.co.za>
Message-ID: <1425245967.45.0.829791266353.issue23556@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

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

From report at bugs.python.org  Sun Mar  1 22:41:30 2015
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 01 Mar 2015 21:41:30 +0000
Subject: [issue23476] SSL cert verify fail for "www.verisign.com"
In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za>
Message-ID: <1425246090.58.0.670916345074.issue23476@psf.upfronthosting.co.za>


Christian Heimes added the comment:

With the patch the flag is always set. Are there any possible side effects? IMHO it's better to add a store_flags property and make the feature optional.

----------

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

From report at bugs.python.org  Sun Mar  1 22:42:42 2015
From: report at bugs.python.org (Alex Gaynor)
Date: Sun, 01 Mar 2015 21:42:42 +0000
Subject: [issue23476] SSL cert verify fail for "www.verisign.com"
In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za>
Message-ID: <1425246162.72.0.112530832133.issue23476@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

It looks like the existing `verify_flags` param is actually the same thing, so we can just use it. That said, I think this should be on by default, I can't think of a scenario you don't want it.

----------

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

From report at bugs.python.org  Sun Mar  1 22:44:59 2015
From: report at bugs.python.org (Cory Benfield)
Date: Sun, 01 Mar 2015 21:44:59 +0000
Subject: [issue23476] SSL cert verify fail for "www.verisign.com"
In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za>
Message-ID: <1425246299.42.0.157684293078.issue23476@psf.upfronthosting.co.za>


Cory Benfield added the comment:

My reading of the OpenSSL issue is that there are no negative side effects from turning this on.

----------

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

From report at bugs.python.org  Sun Mar  1 22:45:10 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 01 Mar 2015 21:45:10 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1425246310.27.0.330686418486.issue13312@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Mark,

Issue #17960 ("Clarify the required behaviour of locals()") does not seem to be relevant here.  I think you meant to refer to a changeset, not issue number.  If so please use hash number such as d877d7f3b679.

----------

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

From report at bugs.python.org  Sun Mar  1 22:53:05 2015
From: report at bugs.python.org (Davin Potts)
Date: Sun, 01 Mar 2015 21:53:05 +0000
Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1425246785.35.0.513458563058.issue23484@psf.upfronthosting.co.za>


Davin Potts added the comment:

In the docs for 2.7, multiprocessing.Lock refers to threading.Lock in which the signature for acquire looks like:

    threading.Lock.acquire([blocking])


However, in the current code in 2.7, Modules/_multiprocessing/semaphore.c implements multiprocessing.Lock.acquire to support two arguments:  'block' and 'timeout'.


In the docs for 3.4, threading.Lock.acquire now has both 'blocking' and 'timeout' arguments.  Notably, it specifies: "It is forbidden to specify a timeout when blocking is false."  This is indeed enforced by threading.Lock but not at all by multiprocessing.Lock.  In a 3.4.3 shell:

    >>> import multiprocessing
    >>> import threading
    >>> ml = multiprocessing.Lock()
    >>> ml.acquire(False, 20.0)
    True
    >>> ml.release()
    >>> tl = threading.Lock()
    >>> tl.acquire(False, 20.0)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: can't specify a timeout for a non-blocking call


In 2.7, acquire similarly permits a supplied value for timeout even when set to be non-blocking.

A further difference:  the code in Modules/_multiprocessing/semaphore.c appears to translate a timeout=None into an infinite wait whereas the threading implementation rejects any attempt to supply a None for timeout, demanding a float instead.  (In 3.4, threading uses timeout=-1 to request an infinite wait.)


Given these discrepancies between threading's and multiprocessing's implementations for Lock and given the difficulties in renaming an argument that can be supplied as a non-keyword parameter, the right thing to do at this point is to properly document multiprocessing.Lock's acquire as using 'block' and 'timeout'.

----------
assignee:  -> docs at python
components: +Documentation -Extension Modules
nosy: +docs at python

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

From report at bugs.python.org  Sun Mar  1 22:54:58 2015
From: report at bugs.python.org (Isaac Schwabacher)
Date: Sun, 01 Mar 2015 21:54:58 +0000
Subject: [issue20876] python -m test test_pathlib fails
In-Reply-To: <1394395116.03.0.645933571525.issue20876@psf.upfronthosting.co.za>
Message-ID: <1425246898.14.0.509961318475.issue20876@psf.upfronthosting.co.za>


Isaac Schwabacher added the comment:

This behavior is caused by the way NFS clients implement unlinking open files: instead of unlinking an open file, the filesystem renames it to .nfsXXXX and unlinks it on close.  (The search term you want is "silly rename".)  The reason this problem appears is that `test.support.fs_is_case_insensitive()` unlinks but fails to close the temporary file that it creates.  Of course, any attempt to unlink the .nfsXXXX file (for instance, by `shutil.rmtree`) just succeeds in renaming it to .nfsYYYY, so there is no way to delete the parent directory until the file is closed.

The attached patch modifies the offending function to use the `tempfile.NamedTemporaryFile` context manager, which closes the file on leaving the block.

----------
keywords: +patch
nosy: +ischwabacher
Added file: http://bugs.python.org/file38289/test_support.patch

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

From report at bugs.python.org  Sun Mar  1 23:00:00 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 01 Mar 2015 22:00:00 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1425247200.51.0.919084877318.issue13312@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

As far as I can tell, the original report was about a test failing due to a system-dependent behavior of time.asctime().  However, since changeset 1e62a0cee092 (see issue #8013), we no longer call system asctime.  I believe the test disabled in 1a0bfc26af57 can now be restored.

----------
components: +Tests -Library (Lib)
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Sun Mar  1 23:03:41 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 01 Mar 2015 22:03:41 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1425247421.37.0.278326194273.issue13312@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Sorry should have been #17690.

----------

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

From report at bugs.python.org  Sun Mar  1 23:09:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Mar 2015 22:09:09 +0000
Subject: [issue20271] urllib.parse.urlparse() accepts wrong URLs
In-Reply-To: <1389789129.93.0.775761654638.issue20271@psf.upfronthosting.co.za>
Message-ID: <1425247749.12.0.326522997426.issue20271@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

splitport() shouldn't handle auth, it should be called after auth is dropped with splituser().

The patch makes URL parsing slower, especially URLs with IPv6 addresses.

$ ./python -m timeit -s "from urllib.parse import urlparse, clear_cache" -- "urlparse('http://python.org:80'); clear_cache()"
Unpatched: 10000 loops, best of 3: 70.3 usec per loop
Patched:   10000 loops, best of 3: 105 usec per loop

$ ./python -m timeit -s "from urllib.parse import urlparse, clear_cache" -- "urlparse('http://[2001:4802:7901:0:e60a:1375:0:5]:80'); clear_cache()"
Unpatched: 10000 loops, best of 3: 71.1 usec per loop
Patched:   1000 loops, best of 3: 239 usec per loop

----------

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

From report at bugs.python.org  Sun Mar  1 23:20:20 2015
From: report at bugs.python.org (Davin Potts)
Date: Sun, 01 Mar 2015 22:20:20 +0000
Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1425248420.9.0.0163247389946.issue23484@psf.upfronthosting.co.za>


Davin Potts added the comment:

To be fair, the docs in 2.7 do actually mention the use of 'block' instead of 'blocking' in acquire though it does so inside a "Note" block a bit later in the docs after first claiming that multiprocessing.Lock is a "clone".

In 3.4, that important detail has been inexplicably stripped from this distended "Note" block.


Ultimately, this use of the "Note" block seems to misplace important information that should appear in the description of the multiprocessing.Lock class and its siblings in the synchronization section.

----------

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

From report at bugs.python.org  Sun Mar  1 23:22:22 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 01 Mar 2015 22:22:22 +0000
Subject: [issue15286] normpath does not work with local literal paths
In-Reply-To: <1341679642.43.0.277228630346.issue15286@psf.upfronthosting.co.za>
Message-ID: <1425248542.16.0.482090861565.issue15286@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

As ntpath was cleaned up on #15275 do we need this patch or not, especially given that pathlib made it into 3.4?

----------

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

From report at bugs.python.org  Sun Mar  1 23:30:58 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 01 Mar 2015 22:30:58 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1425249058.26.0.276403152484.issue13312@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

We still have the following in Lib/test/test_time.py:

        # Issue #13312: it may return wrong value for year < TIME_MINYEAR + 1900
        # Skip the value test, but check that no error is raised
        self.yearstr(TIME_MINYEAR)


I reviewed the current time.asctime() code and it does look like it invokes undefined behavior for extremely large negative years.

The problem is that in C struct tm, year is stored as year - 1900 and for year < -2147481748 (= -2**31 + 1900) we trigger an overflow of a signed integer.

Can someone confirm that on AMD64 FreeBSD subtracting 1900 from -2147483648 and then adding it back does not give -2147483648?

----------

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

From report at bugs.python.org  Mon Mar  2 00:07:52 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 01 Mar 2015 23:07:52 +0000
Subject: [issue13312] test_time fails: strftime('%Y', y) for negative year
In-Reply-To: <1320166359.06.0.160451222607.issue13312@psf.upfronthosting.co.za>
Message-ID: <1425251272.49.0.506067562285.issue13312@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Attached patch eliminates undefined behavior, but I am not sure fixing this is worth the trouble.

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file38290/issue13312.patch

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

From report at bugs.python.org  Mon Mar  2 00:17:21 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 01 Mar 2015 23:17:21 +0000
Subject: [issue12989] Consistently handle path separator in Py_GetPath on
 Windows
In-Reply-To: <1316131696.55.0.834479609561.issue12989@psf.upfronthosting.co.za>
Message-ID: <1425251841.94.0.687662767986.issue12989@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

The patch is three parts that adds one line, moves one line and deletes one line.  I've checked 2.6, 2.7, 3.2, 3.3, 3.4 and default.  In all cases the second part has already been implemented, the first and third have not.  Assuming that these changes must still be done, do we also need additional unit tests?

----------
nosy: +steve.dower, tim.golden, zach.ware

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

From report at bugs.python.org  Mon Mar  2 00:51:20 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 01 Mar 2015 23:51:20 +0000
Subject: [issue19873] There is a duplicate function in Lib/test/test_pathlib.py
In-Reply-To: <1386059449.85.0.979457911898.issue19873@psf.upfronthosting.co.za>
Message-ID: <1425253880.19.0.722331707139.issue19873@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Pang :(

----------

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

From report at bugs.python.org  Mon Mar  2 00:53:28 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 01 Mar 2015 23:53:28 +0000
Subject: [issue6911] Document changes in asynchat
In-Reply-To: <1252942019.67.0.473669726807.issue6911@psf.upfronthosting.co.za>
Message-ID: <1425254008.87.0.440943545193.issue6911@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
versions: +Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Mar  2 00:55:55 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 01 Mar 2015 23:55:55 +0000
Subject: [issue12137] Error EBADF in test_urllibnet
In-Reply-To: <1305995654.0.0.162674044436.issue12137@psf.upfronthosting.co.za>
Message-ID: <1425254155.4.0.826291185409.issue12137@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Can this be closed as it's stated to be a transient failure and it's nearly four years old?

----------

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

From report at bugs.python.org  Mon Mar  2 00:58:21 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 01 Mar 2015 23:58:21 +0000
Subject: [issue9784] _msi.c warnings under 64-bit Windows
In-Reply-To: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>
Message-ID: <1425254301.52.0.622303702736.issue9784@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
components: +Windows
nosy: +steve.dower, tim.golden, zach.ware

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

From report at bugs.python.org  Mon Mar  2 01:10:17 2015
From: report at bugs.python.org (Isaac Schwabacher)
Date: Mon, 02 Mar 2015 00:10:17 +0000
Subject: [issue21483] Skip os.utime() test on NFS?
In-Reply-To: <CANc-5Uwwdg6YrkjAf6CsUaSj35OjpEmyru3vtSAz4QMMo7E8Dw@mail.gmail.com>
Message-ID: <1425255017.95.0.0604352077365.issue21483@psf.upfronthosting.co.za>


Isaac Schwabacher added the comment:

Patch to do precisely this.  Wish I'd spent more time searching for this thread and less time debugging; it would have saved me a lot of trouble.

----------
keywords: +patch
nosy: +ischwabacher
Added file: http://bugs.python.org/file38291/test_import.patch

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

From report at bugs.python.org  Mon Mar  2 01:47:47 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Mon, 02 Mar 2015 00:47:47 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425257267.48.0.252863253954.issue23496@psf.upfronthosting.co.za>


Ryan Gonzalez added the comment:

Cyd:

Just run:

$ git commit -m "Put some message here" # commit the changes
$ git push # push the changes

I'm working on it, but I haven't even gotten it to build (CURSE YOU, AUTOCONF!)

----------

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

From report at bugs.python.org  Mon Mar  2 01:53:58 2015
From: report at bugs.python.org (koobs)
Date: Mon, 02 Mar 2015 00:53:58 +0000
Subject: [issue20210] Provide configure options to enable/disable Python
 modules and extensions
In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za>
Message-ID: <1425257638.94.0.172239710984.issue20210@psf.upfronthosting.co.za>


koobs added the comment:

For what it's worth, we've been running with patch 0001 on FreeBSD's Python 3.4 port for 8 months with no issues [1].

It allows downstreams like us to easily customise what modules gets built, and offers substantial flexibility and benefits for various packaging scenarios.

This patch is the simplest approach that offers benefits without complicating the existing built infrastructure, or precluding a more 'elegant' solution if one is forthcoming in the future.

[1] https://svnweb.freebsd.org/ports/head/lang/python34/files/patch-issue20210

----------

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

From report at bugs.python.org  Mon Mar  2 02:10:53 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 02 Mar 2015 01:10:53 +0000
Subject: [issue20271] urllib.parse.urlparse() accepts wrong URLs
In-Reply-To: <1389789129.93.0.775761654638.issue20271@psf.upfronthosting.co.za>
Message-ID: <1425258653.53.0.0565689278257.issue20271@psf.upfronthosting.co.za>


Martin Panter added the comment:

I suspect the proposed patch here would make some of the special error handling for the ?port? property redundant, and would compete with my patch for Issue 20059, which raises ValueError in more cases when ?port? is accessed, rather than returning None.

There should also be test cases (and maybe documentation or fixes?) to illustrate the behaviour of parsing:

* http://[fe80::a%25en1] (RFC 6874-style scoped IPv6 address with zone identifier)
* http://[v1.fe80::a+en1] (RFC 3986 IPvFuture format, using <https://tools.ietf.org/html/draft-sweet-uri-zoneid-01> style address)

----------
nosy: +vadmium

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

From report at bugs.python.org  Mon Mar  2 02:27:07 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 02 Mar 2015 01:27:07 +0000
Subject: [issue20059] Inconsistent urlparse/urllib.parse handling of invalid
 port values?
In-Reply-To: <1387842710.57.0.78188368243.issue20059@psf.upfronthosting.co.za>
Message-ID: <1425259627.11.0.549865786068.issue20059@psf.upfronthosting.co.za>


Martin Panter added the comment:

See also Issue 20271, which has a proposed patch with more strict urlsplit() etc behaviour before even returning a SplitResult object.

----------

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

From report at bugs.python.org  Mon Mar  2 02:41:52 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 02 Mar 2015 01:41:52 +0000
Subject: [issue18082] Inconsistent behavior of IOBase methods on closed files
In-Reply-To: <1369758688.03.0.231740499906.issue18082@psf.upfronthosting.co.za>
Message-ID: <1425260512.32.0.349320120393.issue18082@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Anybody?

----------

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

From report at bugs.python.org  Mon Mar  2 02:47:14 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 02 Mar 2015 01:47:14 +0000
Subject: [issue1724366] cPickle module doesn't work with universal line endings
Message-ID: <1425260834.38.0.0656681043487.issue1724366@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

msg185431 from  #616013 states "Three years later, I don't think anyone is interested in documenting the outdated cPickle." so I believe this should suffer the same fate.

----------

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

From report at bugs.python.org  Mon Mar  2 03:19:20 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 02 Mar 2015 02:19:20 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425262760.47.0.577046900189.issue21619@psf.upfronthosting.co.za>


Martin Panter added the comment:

It seems two different issues have popped up:

## 1. Windows behaviour ##

Windows apparently doesn?t handle broken pipes consistently, sometimes raising an EINVAL error, and sometimes not raising any error. I don?t know if this is a problem with Python, or a quirk with Windows. (Just tried with Wine, and it always raises ENOSPC instead, but I guess that?s a Wine-specific quirk.)

Perhaps we can change the offending test case to the following, at least until someone can investigate and explain what is going on:

...
if mswindows:
    try:
        proc.__exit__(None, None, None)
    except OSError:  # Sometimes raises EINVAL, sometimes no error
        pass
else:
    self.assertRaises(BrokenPipeError, proc.__exit__, None, None, None)
...

## 2. Suppressing BrokenPipeError ##

I don?t have any strong opinions. I think in the past when writing to a process?s input raises BrokenPipeError, I have tended to skip the writing and go on to analyse the process?s output and/or exit status (the same as if writing succeeded).

Some arguments for raising BrokenPipeError (current behaviour):

* No change in behaviour
* Slightly simpler implementation
* Consistent with the way stdin.close() works
* Potentially more flexible if the user cares about handling a broken pipe specially.
* Exiting the context manager does not return any data, so no return value is lost by raising an exception. In contrast, one of the reasons communicate() was changed to sometimes suppress the exception is so that the captured output is returned and not lost.

Arguments for suppressing BrokenPipeError:

* Consistent with the way communicate() is meant to work, according to Issue 10963.
* Probably more useful in normal use cases
* User can always explicitly call stdin.close() if they really want to handle the BrokenPipeError
* Avoid possible confusion and hiding a more important exception, if one was already raised inside the context manager, for example if a subprocess crash was detected, or if stdin.write() already raised its own BrokenPipeError.

Replying to Victor: ?the process always exit after __exit__??:

__exit__ is meant to call wait(), so it only returns when the subprocess exits. It could potentially still be running despite closing its input pipe. This issue was originally about making sure __exit__ called wait() in all cases.

----------

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

From report at bugs.python.org  Mon Mar  2 03:36:05 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 02 Mar 2015 02:36:05 +0000
Subject: [issue3931] codecs.charmap_build is untested and undocumented
In-Reply-To: <1222085190.52.0.690275455212.issue3931@psf.upfronthosting.co.za>
Message-ID: <1425263765.34.0.540061759998.issue3931@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I do not see much purpose in documenting and testing this one function alone.  I think that all functions in _codecsmodule.c should be looked at to see if they are private or public, but I'm certainly not volunteering to do it.

----------

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

From report at bugs.python.org  Mon Mar  2 03:42:20 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 02 Mar 2015 02:42:20 +0000
Subject: [issue23485] PEP 475: handle EINTR in the select and selectors module
In-Reply-To: <1424352775.64.0.420442648443.issue23485@psf.upfronthosting.co.za>
Message-ID: <1425264140.25.0.16709846772.issue23485@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

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

From report at bugs.python.org  Mon Mar  2 03:47:22 2015
From: report at bugs.python.org (eryksun)
Date: Mon, 02 Mar 2015 02:47:22 +0000
Subject: [issue4071] ntpath.abspath fails for long str paths
In-Reply-To: <1223425635.48.0.940202056696.issue4071@psf.upfronthosting.co.za>
Message-ID: <1425264442.2.0.916025312805.issue4071@psf.upfronthosting.co.za>


eryksun added the comment:

> Can we close this as I'm not aware of any possible way to fix this? 

Windows system and C runtime calls that take paths could be restricted to wide-character APIs, such as calling GetFullPathnameW in this case, or _wexecve instead of execve (issue 23462). Then for bytes paths an extension can call PyUnicode_FSDecoder (PyUnicode_DecodeMBCS). In posxmodule.c this can be handled in the path_converter function.

path_converter
https://hg.python.org/cpython/file/5d4b6a57d5fd/Modules/posixmodule.c#l698

path_converter could be moved to Python/fileutils.c to make it available for use by other modules such as io.

----------
nosy: +eryksun

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

From report at bugs.python.org  Mon Mar  2 04:12:03 2015
From: report at bugs.python.org (Davin Potts)
Date: Mon, 02 Mar 2015 03:12:03 +0000
Subject: [issue23513] Add support for classes/object model in
 multiprocessing/pickle
In-Reply-To: <1424797303.36.0.545069200968.issue23513@psf.upfronthosting.co.za>
Message-ID: <1425265923.74.0.829875705167.issue23513@psf.upfronthosting.co.za>


Davin Potts added the comment:

The runnable example in the attached file, issue_23513_play.py, suggests a way to preserve the inheritance of the Result class in any subclasses of Thing yet leaves the definition of Thing.worker as the OP first had it (in the most straightforward way).

In creating other processes, the authors of multiprocessing needed a way to communicate objects from one process to another and the choice of pickle for serialization does require us to adjust our thinking a little but it does not mean we have to lose being pythonic.  Independent of whether multiprocessing is involved or not, returning a Result object from an instancemethod of another class might work without the definition of the Result class being in the current namespace, but it feels like a much more comprehensive solution to have the Result class available in the current namespace.  The attached proposes defining the Result class outside of the Thing class yet then adding it as a class attribute of Thing -- this gives both inheritability (which was missing in the "simple example") and visibility for pickling.  The convenience of a function like wrap_worker is just one tool that helps pickle figure out how to do its job -- this is part of a larger discussion around pickle and how to gracefully deal with non-trivial situations.

The attached is not being proposed as a final solution but does it help with your situation in particular?  Do parts of it look useful?

----------
Added file: http://bugs.python.org/file38292/issue_23513_play.py

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

From report at bugs.python.org  Mon Mar  2 04:23:18 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Mon, 02 Mar 2015 03:23:18 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425266598.25.0.589091835794.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

Ryan,
Thanks. First commit in; all fixes for Android's broken mbstowcs, new plat-android and plat-android/DLFCN.py.

What are you trying to build?

----------

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

From report at bugs.python.org  Mon Mar  2 05:01:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Mar 2015 04:01:32 +0000
Subject: [issue23387] test_urllib2 fails with HTTP Error 502: Bad Gateway
In-Reply-To: <1422961904.97.0.978548371135.issue23387@psf.upfronthosting.co.za>
Message-ID: <20150302040126.34518.68875@psf.io>


Roundup Robot added the comment:

New changeset 7e783289bc12 by Berker Peksag in branch '3.4':
Issue #23387: Skip test_issue16464 if it raises an 5xx error.
https://hg.python.org/cpython/rev/7e783289bc12

New changeset 4cadc2c65609 by Berker Peksag in branch 'default':
Issue #23387: Skip test_issue16464 if it raises an 5xx error.
https://hg.python.org/cpython/rev/4cadc2c65609

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Mar  2 05:02:38 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 Mar 2015 04:02:38 +0000
Subject: [issue23387] test_urllib2 fails with HTTP Error 502: Bad Gateway
In-Reply-To: <1422961904.97.0.978548371135.issue23387@psf.upfronthosting.co.za>
Message-ID: <1425268958.24.0.421653810566.issue23387@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Mar  2 05:13:50 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 02 Mar 2015 04:13:50 +0000
Subject: [issue23553] Reduce the number of comparisons for range checking.
In-Reply-To: <1425171038.63.0.240295916037.issue23553@psf.upfronthosting.co.za>
Message-ID: <1425269630.13.0.318515247253.issue23553@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, here is a small patch to show how this could can be done consistently and with code clarity.

----------
title: Reduce the number of comparison for range checking. -> Reduce the number of comparisons for range checking.
Added file: http://bugs.python.org/file38293/valid_index.diff

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

From report at bugs.python.org  Mon Mar  2 05:24:28 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 02 Mar 2015 04:24:28 +0000
Subject: [issue23552] Have timeit warn about runs that are not independent of
 each other
In-Reply-To: <1425156172.0.0.931116052614.issue23552@psf.upfronthosting.co.za>
Message-ID: <1425270268.81.0.434222380789.issue23552@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

See attached

----------
keywords: +patch
Added file: http://bugs.python.org/file38294/timeit_warning.diff

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

From report at bugs.python.org  Mon Mar  2 05:26:18 2015
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 02 Mar 2015 04:26:18 +0000
Subject: [issue23552] Have timeit warn about runs that are not independent of
 each other
In-Reply-To: <1425156172.0.0.931116052614.issue23552@psf.upfronthosting.co.za>
Message-ID: <1425270378.09.0.972546154336.issue23552@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

This seems like it probably will report something useless (and ultimately be disabled) on PyPy, where runs before and after the JIT will display significant variance.

----------
nosy: +alex, arigo, fijall

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

From report at bugs.python.org  Mon Mar  2 05:33:53 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Mar 2015 04:33:53 +0000
Subject: [issue20521] [PATCH] Cleanup for "dis" module documentation
In-Reply-To: <1391608572.54.0.381225308012.issue20521@psf.upfronthosting.co.za>
Message-ID: <20150302043350.20295.14909@psf.io>


Roundup Robot added the comment:

New changeset 617feb5d8af2 by Berker Peksag in branch '3.4':
Issue #20521: Change ``TOS`` to TOS in dis documentation.
https://hg.python.org/cpython/rev/617feb5d8af2

New changeset a331d71bdc0a by Berker Peksag in branch 'default':
Issue #20521: Change ``TOS`` to TOS in dis documentation.
https://hg.python.org/cpython/rev/a331d71bdc0a

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Mar  2 05:35:10 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 Mar 2015 04:35:10 +0000
Subject: [issue20521] Cleanup for "dis" module documentation
In-Reply-To: <1391608572.54.0.381225308012.issue20521@psf.upfronthosting.co.za>
Message-ID: <1425270910.01.0.135391339001.issue20521@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Sven. Most of the changes in your patch have already been fixed in issue 22845. Just committed the "``TOS`` -> TOS" part of the patch.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: [PATCH] Cleanup for "dis" module documentation -> Cleanup for "dis" module documentation

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

From report at bugs.python.org  Mon Mar  2 05:54:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Mar 2015 04:54:24 +0000
Subject: [issue23477] Increase coverage for wsgiref module
In-Reply-To: <1424271437.72.0.0459822564302.issue23477@psf.upfronthosting.co.za>
Message-ID: <20150302045420.15300.27928@psf.io>


Roundup Robot added the comment:

New changeset 9f2ef8654bf8 by Berker Peksag in branch '3.4':
Issue #23477: Improve test coverage of wsgiref.simple_server.
https://hg.python.org/cpython/rev/9f2ef8654bf8

New changeset 0c786d1fb372 by Berker Peksag in branch 'default':
Issue #23477: Improve test coverage of wsgiref.simple_server.
https://hg.python.org/cpython/rev/0c786d1fb372

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Mar  2 05:55:47 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 Mar 2015 04:55:47 +0000
Subject: [issue23477] Increase coverage for wsgiref module
In-Reply-To: <1424271437.72.0.0459822564302.issue23477@psf.upfronthosting.co.za>
Message-ID: <1425272147.37.0.552396467533.issue23477@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Alex.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

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

From report at bugs.python.org  Mon Mar  2 06:40:57 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Mar 2015 05:40:57 +0000
Subject: [issue23527] test_smtpnet uses incorrect port for STARTTLS
In-Reply-To: <1424944896.48.0.616589540337.issue23527@psf.upfronthosting.co.za>
Message-ID: <20150302054049.53151.87385@psf.io>


Roundup Robot added the comment:

New changeset 06d69688ea06 by Berker Peksag in branch '3.4':
Issue #23527: Update Gmail port number for STARTTLS to 587.
https://hg.python.org/cpython/rev/06d69688ea06

New changeset 9ff477cd79da by Berker Peksag in branch 'default':
Issue #23527: Update Gmail port number for STARTTLS to 587.
https://hg.python.org/cpython/rev/9ff477cd79da

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Mar  2 06:43:11 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 Mar 2015 05:43:11 +0000
Subject: [issue23527] test_smtpnet uses incorrect port for STARTTLS
In-Reply-To: <1424944896.48.0.616589540337.issue23527@psf.upfronthosting.co.za>
Message-ID: <1425274991.4.0.488081288234.issue23527@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Good catch. The test is skipped as "Resource 'smtp.gmail.com' is not available" on my machine.

See https://support.google.com/mail/answer/13287 for reference.

Thanks for the patch.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.4

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

From report at bugs.python.org  Mon Mar  2 06:46:01 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 Mar 2015 05:46:01 +0000
Subject: [issue23004] mock_open() should allow reading binary data
In-Reply-To: <1417965857.24.0.521739131396.issue23004@psf.upfronthosting.co.za>
Message-ID: <1425275161.35.0.354646204006.issue23004@psf.upfronthosting.co.za>


Berker Peksag added the comment:

LGTM.

----------
components: +Library (Lib)
stage: patch review -> commit review

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

From report at bugs.python.org  Mon Mar  2 07:37:56 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Mar 2015 06:37:56 +0000
Subject: [issue23512] The list of built-in functions is not alphabetical on
 https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425278276.26.0.761127848263.issue23512@psf.upfronthosting.co.za>


?ric Araujo added the comment:

IIRC the table was added in a 3.x branch and backported to 2.7; the developer doing the backport added the functions missing in 3.x to the end of the table, thinking that re-ordering was not worth the trouble.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Mon Mar  2 07:45:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 06:45:55 +0000
Subject: [issue23552] Have timeit warn about runs that are not independent of
 each other
In-Reply-To: <1425156172.0.0.931116052614.issue23552@psf.upfronthosting.co.za>
Message-ID: <1425278755.62.0.981707522318.issue23552@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be add an option to control a warning (e.g. turn it off when Python run with -Wignore)? May be write warning to stderr?

----------

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

From report at bugs.python.org  Mon Mar  2 07:52:56 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 06:52:56 +0000
Subject: [issue23512] The list of built-in functions is not alphabetical on
 https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425279176.84.0.0415238364851.issue23512@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

That was me in #10299 (the issue contains a discussion about the ordering in the last few messages).

Since there are only 4 functions, I think it would be ok removing them from the table and instead add a sentence like "In addition, there are other 4 built-in functions that are no longer considered essential: apply, buffer, coerce, and intern.  They are documented in the Non-essential Built-in Functions section.".

See also #16927 for a proposed grouping that might help solve this issue.

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

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

From report at bugs.python.org  Mon Mar  2 08:31:46 2015
From: report at bugs.python.org (Alex Shkop)
Date: Mon, 02 Mar 2015 07:31:46 +0000
Subject: [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1425281506.18.0.615357651444.issue22832@psf.upfronthosting.co.za>


Alex Shkop added the comment:

This patch fixes pointed out bugs in documentation and docstring for ioctl() function.

----------
Added file: http://bugs.python.org/file38295/issue22832_v2.patch

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

From report at bugs.python.org  Mon Mar  2 08:39:02 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 07:39:02 +0000
Subject: [issue23504] Add __all__ into types
In-Reply-To: <1424729645.56.0.912988413489.issue23504@psf.upfronthosting.co.za>
Message-ID: <1425281942.92.0.454902607803.issue23504@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar  2 08:43:48 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 07:43:48 +0000
Subject: [issue23455] file iterator "deemed broken";
 can resume after StopIteration
In-Reply-To: <1423766934.46.0.3718920034.issue23455@psf.upfronthosting.co.za>
Message-ID: <1425282228.47.0.20235444843.issue23455@psf.upfronthosting.co.za>


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


----------
nosy: +pitrou
type:  -> behavior

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

From report at bugs.python.org  Mon Mar  2 08:46:41 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 07:46:41 +0000
Subject: [issue23460] Decimals do not obey ':g' exponential notation
 formatting rules
In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za>
Message-ID: <1425282401.72.0.21774413074.issue23460@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Should we add a note to the format docs, or just close this?

----------
nosy: +ezio.melotti, mark.dickinson

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

From report at bugs.python.org  Mon Mar  2 08:48:15 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 07:48:15 +0000
Subject: [issue23469] Delete Misc/*.wpr files
In-Reply-To: <1424048342.99.0.00819785192711.issue23469@psf.upfronthosting.co.za>
Message-ID: <1425282495.68.0.22798451107.issue23469@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar  2 08:49:06 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 07:49:06 +0000
Subject: [issue433028] SRE: (?flag:...) is not supported
Message-ID: <1425282546.99.0.899797183364.issue433028@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar  2 08:58:25 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 07:58:25 +0000
Subject: [issue23493] optimize sort_keys in json module by using
 operator.itemgetter()
In-Reply-To: <1424449556.4.0.766318893285.issue23493@psf.upfronthosting.co.za>
Message-ID: <1425283105.02.0.80613291892.issue23493@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar  2 09:04:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 08:04:09 +0000
Subject: [issue433028] SRE: (?flag:...) is not supported
Message-ID: <1425283449.39.0.756342992448.issue433028@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is preliminary patch.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file38296/re_scoped_flags.diff

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

From report at bugs.python.org  Mon Mar  2 09:04:39 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 08:04:39 +0000
Subject: [issue433028] SRE: (?flag:...) is not supported
Message-ID: <1425283479.79.0.39746821961.issue433028@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +Improve some re error messages using regex for hints

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

From report at bugs.python.org  Mon Mar  2 09:06:38 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:06:38 +0000
Subject: [issue23262] webbrowser module broken with Firefox 36+
In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za>
Message-ID: <1425283598.85.0.644580479148.issue23262@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar  2 09:12:39 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:12:39 +0000
Subject: [issue23263] Python 3 gives misleading errors when validating unicode
 identifiers
In-Reply-To: <1421559881.85.0.938769960217.issue23263@psf.upfronthosting.co.za>
Message-ID: <1425283959.58.0.197339139726.issue23263@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

While the request is reasonable, the patch seems to touch quite some code.
Since this is just to improve an error message in a somewhat obscure corner case, I'm not sure it's worth applying it.

----------
nosy: +serhiy.storchaka
stage:  -> patch review
versions:  -Python 3.2, Python 3.3, Python 3.4, Python 3.6

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

From report at bugs.python.org  Mon Mar  2 09:14:16 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:14:16 +0000
Subject: [issue23275] Can assign [] = (), but not () = []
In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za>
Message-ID: <1425284056.63.0.190493479542.issue23275@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar  2 09:16:32 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:16:32 +0000
Subject: [issue23312] google thinks the docs are mobile unfriendly
In-Reply-To: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za>
Message-ID: <1425284192.34.0.652001488034.issue23312@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar  2 09:18:40 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:18:40 +0000
Subject: [issue23320] devguide should mention rules about "paragraph reflow"
 in the documentation
In-Reply-To: <1422219993.92.0.674256323538.issue23320@psf.upfronthosting.co.za>
Message-ID: <1425284320.8.0.291970178009.issue23320@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Agreed with what Georg said and I think the devguide can be update accordingly.

----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy
nosy: +docs at python
stage:  -> needs patch

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

From report at bugs.python.org  Mon Mar  2 09:20:34 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:20:34 +0000
Subject: [issue23330] h2py.py regular expression missing
In-Reply-To: <1422357197.95.0.836847227653.issue23330@psf.upfronthosting.co.za>
Message-ID: <1425284434.54.0.322823949356.issue23330@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar  2 09:21:16 2015
From: report at bugs.python.org (=?utf-8?q?Rapha=C3=ABl_Bleuse?=)
Date: Mon, 02 Mar 2015 08:21:16 +0000
Subject: [issue23559] [doc] inconsistent range example output
Message-ID: <1425284476.5.0.408396499523.issue23559@psf.upfronthosting.co.za>


New submission from Rapha?l Bleuse:

Reading the documentation for ranges (see https://docs.python.org/3.5/library/stdtypes.html#ranges), the example using a negative index output is inconsistent with the range effective behaviour.

One can read:
"
>>> r[-1]
18
"

while (in my understanding) it should be:
"
>>> r[-1]
8
"

Note the output should be 8 and not 18.

Rapha?l

----------
assignee: docs at python
components: Documentation
messages: 237029
nosy: bleuse, docs at python
priority: normal
severity: normal
status: open
title: [doc] inconsistent range example output
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar  2 09:21:26 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:21:26 +0000
Subject: [issue23367] integer overflow in unicodedata.normalize
In-Reply-To: <1422799035.27.0.978256662941.issue23367@psf.upfronthosting.co.za>
Message-ID: <1425284486.31.0.845531699229.issue23367@psf.upfronthosting.co.za>


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


----------
components: +Unicode
nosy: +ezio.melotti, haypo, serhiy.storchaka

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

From report at bugs.python.org  Mon Mar  2 09:29:57 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:29:57 +0000
Subject: [issue23192] Generator return value ignored in lambda function
In-Reply-To: <1420728125.93.0.910147391239.issue23192@psf.upfronthosting.co.za>
Message-ID: <1425284997.15.0.105309146806.issue23192@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar  2 09:31:44 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:31:44 +0000
Subject: [issue22933] Misleading sentence in doc for shutil.move
In-Reply-To: <1416849036.72.0.766895523282.issue22933@psf.upfronthosting.co.za>
Message-ID: <1425285104.66.0.0248134719092.issue22933@psf.upfronthosting.co.za>


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


----------
keywords: +easy
stage:  -> needs patch

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

From report at bugs.python.org  Mon Mar  2 09:34:04 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:34:04 +0000
Subject: [issue22942] Language Reference - optional comma
In-Reply-To: <1416945158.04.0.329806790258.issue22942@psf.upfronthosting.co.za>
Message-ID: <1425285244.0.0.353963511382.issue22942@psf.upfronthosting.co.za>


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


----------
nosy: +Joshua.Landau, neil.g

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

From report at bugs.python.org  Mon Mar  2 09:34:51 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 08:34:51 +0000
Subject: [issue23263] Python 3 gives misleading errors when validating unicode
 identifiers
In-Reply-To: <1421559881.85.0.938769960217.issue23263@psf.upfronthosting.co.za>
Message-ID: <1425285291.63.0.136232854154.issue23263@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Agreed with Ezio. Adding 7 new public names just to enhance one rare error message looks too hight cost. I am inclined to left all as is. Original message is not so bad.

----------

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

From report at bugs.python.org  Mon Mar  2 09:36:57 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:36:57 +0000
Subject: [issue22785] range docstring is less useful than in python 2
In-Reply-To: <1414962423.59.0.0293441090984.issue22785@psf.upfronthosting.co.za>
Message-ID: <1425285417.96.0.00239115003318.issue22785@psf.upfronthosting.co.za>


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


----------
nosy: +benjamin.peterson
type:  -> enhancement

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

From report at bugs.python.org  Mon Mar  2 09:38:34 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:38:34 +0000
Subject: [issue22801] collections.Counter, when empty,
 doesn't raise an error with &= when other is an incompatible type
In-Reply-To: <1415209471.77.0.966779934151.issue22801@psf.upfronthosting.co.za>
Message-ID: <1425285514.93.0.388309120269.issue22801@psf.upfronthosting.co.za>


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


----------
stage: patch review -> test needed

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

From report at bugs.python.org  Mon Mar  2 09:40:01 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:40:01 +0000
Subject: [issue22812] Documentation of unittest -p usage wrong on windows.
In-Reply-To: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>
Message-ID: <1425285601.73.0.837442401317.issue22812@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch
type:  -> enhancement

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

From report at bugs.python.org  Mon Mar  2 09:40:31 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:40:31 +0000
Subject: [issue22813] No facility for test randomisation
In-Reply-To: <1415354759.63.0.40223019389.issue22813@psf.upfronthosting.co.za>
Message-ID: <1425285631.87.0.916843694061.issue22813@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch
type:  -> enhancement

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

From report at bugs.python.org  Mon Mar  2 09:41:12 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 08:41:12 +0000
Subject: [issue23330] h2py.py regular expression missing
In-Reply-To: <1422357197.95.0.836847227653.issue23330@psf.upfronthosting.co.za>
Message-ID: <1425285672.45.0.801338176701.issue23330@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

my be change the pattern to '<([^>\n]+)>'?

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Mon Mar  2 09:42:44 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 02 Mar 2015 08:42:44 +0000
Subject: [issue23460] Decimals do not obey ':g' exponential notation
 formatting rules
In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za>
Message-ID: <1425285764.43.0.506403814234.issue23460@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I don't think we should close: the documentation as written explicitly says that the rules apply to both Decimal and float: "The available presentation types for floating point and decimal values are ...".  But the details listed for 'g' are incorrect.  We could either fix the description for 'g' to explain what happens for `Decimal`, or state up front that the table only applies directly to the `float` type, and that `Decimal` is similar but not identical.

----------

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

From report at bugs.python.org  Mon Mar  2 09:54:50 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:54:50 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za>
Message-ID: <1425286490.2.0.397873047889.issue22831@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar  2 09:56:30 2015
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 02 Mar 2015 08:56:30 +0000
Subject: [issue23559] [doc] inconsistent range example output
In-Reply-To: <1425284476.5.0.408396499523.issue23559@psf.upfronthosting.co.za>
Message-ID: <1425286590.22.0.434326720892.issue23559@psf.upfronthosting.co.za>


Georg Brandl added the comment:

The example is correct.  "r" is a range(0, 20, 2), whose last element is 18.

----------
nosy: +georg.brandl
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Mon Mar  2 09:57:59 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:57:59 +0000
Subject: [issue433030] SRE: Atomic Grouping (?>...) is not supported
Message-ID: <1425286679.84.0.47542967432.issue433030@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar  2 09:59:16 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 08:59:16 +0000
Subject: [issue22817] re.split fails with lookahead/behind
In-Reply-To: <1415396521.35.0.326233142281.issue22817@psf.upfronthosting.co.za>
Message-ID: <1425286756.41.0.520806339391.issue22817@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

re.split() with the r'(?<CA)(?=GCTG)' pattern raises a ValueError in 3.5 (see issue22818). In future releases it could be changed to work with zero-width patterns (such as lookaround assertions).

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Mar  2 10:08:10 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 09:08:10 +0000
Subject: [issue23541] Re module's match() fails to halt on a particular input
In-Reply-To: <1425068315.25.0.0642664750871.issue23541@psf.upfronthosting.co.za>
Message-ID: <1425287290.39.0.686626453096.issue23541@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Mar  2 10:12:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 09:12:08 +0000
Subject: [issue22801] collections.Counter, when empty,
 doesn't raise an error with &= when other is an incompatible type
In-Reply-To: <1415209471.77.0.966779934151.issue22801@psf.upfronthosting.co.za>
Message-ID: <1425287528.65.0.868275705882.issue22801@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Additional check is not for free.

$ ./python -m timeit -s "from collections import Counter; a = Counter(); b = Counter(range(10))" -- "a &= b"

Unpatched: 100000 loops, best of 3: 8.4 usec per loop
Patched:   100000 loops, best of 3: 9.7 usec per loop

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Mon Mar  2 10:12:24 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 09:12:24 +0000
Subject: [issue23460] Decimals do not obey ':g' exponential notation
 formatting rules
In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za>
Message-ID: <1425287544.61.0.715712476752.issue23460@psf.upfronthosting.co.za>


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


----------
keywords: +easy
stage:  -> needs patch
type:  -> enhancement
versions: +Python 2.7, Python 3.5

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

From report at bugs.python.org  Mon Mar  2 10:28:10 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 09:28:10 +0000
Subject: [issue23560] Group the docs of similar methods in stdtypes.rst
Message-ID: <1425288490.4.0.288876913126.issue23560@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

The Doc/library/stdtypes.rst page describes in detail the built-in types and their methods.  As suggested in #21777 (see the comments on Rietveld), it might be a good idea to group the documentation of some similar methods, such as {r|l|}just, {r|l|}strip, {r|}partition, {r|}index, and {r|}find.

This will remove some duplication, make the page shorter and easier to navigate, and make the methods easier to discover.  Adding tables containing the methods for each types has also been proposed.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 237036
nosy: docs at python, ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: Group the docs of similar methods in stdtypes.rst
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Mar  2 10:29:35 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 09:29:35 +0000
Subject: [issue21777] Separate out documentation of binary sequence methods
In-Reply-To: <1402918605.38.0.604956966245.issue21777@psf.upfronthosting.co.za>
Message-ID: <1425288575.05.0.26588388275.issue21777@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Zach, Ezio - if there are any other refactorings from the reviews that
> you'd like to pursue, consider pulling them out to separate issues so
> we don't forget about them.

See #23560.

----------

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

From report at bugs.python.org  Mon Mar  2 11:19:12 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 10:19:12 +0000
Subject: [issue20059] Inconsistent urlparse/urllib.parse handling of invalid
 port values?
In-Reply-To: <1387842710.57.0.78188368243.issue20059@psf.upfronthosting.co.za>
Message-ID: <1425291552.66.0.791514245724.issue20059@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM and I think it is worth to be applied to maintained releases.

----------
nosy: +orsenthil
stage:  -> commit review

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

From report at bugs.python.org  Mon Mar  2 11:42:30 2015
From: report at bugs.python.org (Novice Live)
Date: Mon, 02 Mar 2015 10:42:30 +0000
Subject: [issue23561] a little typo in dis.rst;
 need a non-trivial preceding dot
Message-ID: <1425292950.76.0.483712370522.issue23561@psf.upfronthosting.co.za>


New submission from Novice Live:

it is likely that the author of dis.rst omitted two non-trivial preceding dots.

in the 'Bytecode analysis' section,
both :meth:`dis` and :func:`dis` have no preceding dots before 'dis'.

the dots may be trivial elsewhere, but they are non-trivial here. 
otherwise, the hyperlinks will be unexpectedly targeted to the top of the dis module, rather than the corresponding dis method or function.

ref.
:meth:`.timeit`, where the 'timeit' was preceded by a dot, in timeit.rst.

:)

----------
assignee: docs at python
components: Documentation
files: dis_typo.patch
keywords: patch
messages: 237039
nosy: docs at python, n0vicelive
priority: normal
severity: normal
status: open
title: a little typo in dis.rst; need a non-trivial preceding dot
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38297/dis_typo.patch

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

From report at bugs.python.org  Mon Mar  2 11:51:28 2015
From: report at bugs.python.org (Thomas Roos)
Date: Mon, 02 Mar 2015 10:51:28 +0000
Subject: [issue23330] h2py.py regular expression missing
In-Reply-To: <1422357197.95.0.836847227653.issue23330@psf.upfronthosting.co.za>
Message-ID: <1425293488.88.0.434986551341.issue23330@psf.upfronthosting.co.za>


Thomas Roos added the comment:

works for me

----------

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

From report at bugs.python.org  Mon Mar  2 12:16:23 2015
From: report at bugs.python.org (Bruno Cauet)
Date: Mon, 02 Mar 2015 11:16:23 +0000
Subject: [issue23192] Generator return value ignored in lambda function
In-Reply-To: <1420728125.93.0.910147391239.issue23192@psf.upfronthosting.co.za>
Message-ID: <1425294983.2.0.351520065113.issue23192@psf.upfronthosting.co.za>


Bruno Cauet added the comment:

Here are the operations being emitted (line, macro used and eventual argument):

>>> f = lambda: (yield 5)
3487: ADDOP_O LOAD_CONST e->v.Num.n
3472: ADDOP YIELD_VALUE
1907: ADDOP_IN_SCOPE POP_TOP
4349: ADDOP_O LOAD_CONST Py_None
4350: ADDOP RETURN_VALUE
1457: ADDOP_O LOAD_CONST (PyObject*)co
1458: ADDOP_O LOAD_CONST qualname
1459: ADDOP_I MAKE_FUNCTION args
4349: ADDOP_O LOAD_CONST Py_None
4350: ADDOP RETURN_VALUE
>>> def g(): return (yield 5)
... 
3487: ADDOP_O LOAD_CONST e->v.Num.n
3472: ADDOP YIELD_VALUE
2533: ADDOP RETURN_VALUE
1457: ADDOP_O LOAD_CONST (PyObject*)co
1458: ADDOP_O LOAD_CONST qualname
1459: ADDOP_I MAKE_FUNCTION args
4349: ADDOP_O LOAD_CONST Py_None
4350: ADDOP RETURN_VALUE

So there's an extra POP_TOP + LOAD_CONST Py_NONE for the lambda version that throws away the "123" (in the exemple).

The attached patch (0001-...) fixes it. However please note that I'm not knowledgable about that part of the code and devised the patch empirically.
Moreover a test should probably added but I did not know where (test_dis? tried and failed... see patch 0002-...).

----------
keywords: +patch
nosy: +bru
Added file: http://bugs.python.org/file38298/0001-lambda-generators-don-t-throw-away-stack-top.patch

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

From report at bugs.python.org  Mon Mar  2 12:16:40 2015
From: report at bugs.python.org (Bruno Cauet)
Date: Mon, 02 Mar 2015 11:16:40 +0000
Subject: [issue23192] Generator return value ignored in lambda function
In-Reply-To: <1420728125.93.0.910147391239.issue23192@psf.upfronthosting.co.za>
Message-ID: <1425295000.61.0.79934669468.issue23192@psf.upfronthosting.co.za>


Changes by Bruno Cauet <brunocauet at gmail.com>:


Added file: http://bugs.python.org/file38299/0002-lambda-generator-fix-try-to-add-a-dis-test.patch

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

From report at bugs.python.org  Mon Mar  2 14:11:44 2015
From: report at bugs.python.org (Matt Bachmann)
Date: Mon, 02 Mar 2015 13:11:44 +0000
Subject: [issue23263] Python 3 gives misleading errors when validating unicode
 identifiers
In-Reply-To: <1421559881.85.0.938769960217.issue23263@psf.upfronthosting.co.za>
Message-ID: <1425301904.36.0.209546963115.issue23263@psf.upfronthosting.co.za>


Matt Bachmann added the comment:

Alrighty. I'll investigate and see if I can cut down the code some. If I can't significantly I'll let the issue die quietly. I agree that it's a pretty nitpick ticket. 

I noticed it while doing some research into unicode and made the patch when I saw how languages like swift handle this case. 

Thanks for looking at it though!

----------

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

From report at bugs.python.org  Mon Mar  2 14:39:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Mar 2015 13:39:45 +0000
Subject: [issue23263] Python 3 gives misleading errors when validating unicode
 identifiers
In-Reply-To: <1421559881.85.0.938769960217.issue23263@psf.upfronthosting.co.za>
Message-ID: <1425303585.04.0.294709026267.issue23263@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The attached patch attempts to clarify this by providing a different error when the start character is invalid.

I dislike the patch. The error message "invalid character in identifier" is correct. I don't want to modify so much code for a little better error message.

If you start to use non-ASCII identifier, you are probably already aware that you may get some issues. I close the issue.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Mon Mar  2 15:26:48 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 02 Mar 2015 14:26:48 +0000
Subject: [issue19035] tokenize.generate_tokens treat '\f' symbol as the end of
 file (when reading in unicode)
In-Reply-To: <1379340774.03.0.601384573394.issue19035@psf.upfronthosting.co.za>
Message-ID: <1425306408.93.0.113008013118.issue19035@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

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

From report at bugs.python.org  Mon Mar  2 15:27:38 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 02 Mar 2015 14:27:38 +0000
Subject: [issue19035] tokenize.generate_tokens treat '\f' symbol as the end of
 file (when reading in unicode)
In-Reply-To: <1379340774.03.0.601384573394.issue19035@psf.upfronthosting.co.za>
Message-ID: <1425306458.61.0.532012098433.issue19035@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Ha!  Apparently this bug broke coverage for the Mailman 3 source code:

https://bitbucket.org/ned/coveragepy/issue/360/html-reports-get-confused-by-l-in-the-code

----------

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

From report at bugs.python.org  Mon Mar  2 15:37:39 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Mar 2015 14:37:39 +0000
Subject: [issue23561] a little typo in dis.rst;
 need a non-trivial preceding dot
In-Reply-To: <1425292950.76.0.483712370522.issue23561@psf.upfronthosting.co.za>
Message-ID: <20150302143707.53137.79691@psf.io>


Roundup Robot added the comment:

New changeset 10b563c32f9d by Benjamin Peterson in branch '3.4':
link to the correct dis method or function (closes #23561)
https://hg.python.org/cpython/rev/10b563c32f9d

New changeset 760f222103c7 by Benjamin Peterson in branch 'default':
merge 3.4 (#23561)
https://hg.python.org/cpython/rev/760f222103c7

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Mar  2 15:37:41 2015
From: report at bugs.python.org (Maxime S)
Date: Mon, 02 Mar 2015 14:37:41 +0000
Subject: [issue23562] file.read() followed by file.write() result in incorrect
 behavior
Message-ID: <1425307061.83.0.558328246639.issue23562@psf.upfronthosting.co.za>


New submission from Maxime S:

Observed Behavior:

$python3
Python 3.5.0a1+ (default, Mar  2 2015, 14:30:05) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open("test", "w+")
>>> f.write("Hello World")
11
>>> f.seek(0)
0
>>> f.read(5)
'Hello'
>>> f.write(" people")
7
>>> f.seek(0)
0
>>> f.read()
'Hello World people'


Expected Behavior

According to POSIX, the last f.read() should return "Hello people", like in Python 2:


$ python2
Python 2.7.3 (default, Feb 27 2014, 20:00:17) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open("test", "w+")
>>> f.write("Hello World")
>>> f.seek(0)
>>> f.read(5)
'Hello'
>>> f.write(" people")
>>> f.seek(0)
>>> f.read()
'Hello people'

Workaround:

f.seek(f.tell()) immediately after f.read(5) restore the correct behavior.

----------
components: IO
messages: 237046
nosy: Maxime S
priority: normal
severity: normal
status: open
title: file.read() followed by file.write() result in incorrect behavior
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Mar  2 15:50:03 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Mar 2015 14:50:03 +0000
Subject: [issue23562] file.read() followed by file.write() result in incorrect
 behavior
In-Reply-To: <1425307061.83.0.558328246639.issue23562@psf.upfronthosting.co.za>
Message-ID: <1425307803.83.0.0287562532853.issue23562@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue is probably a duplicate of the issue #12215 (see also #12513 for the codecs moduile).

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

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

From report at bugs.python.org  Mon Mar  2 16:05:03 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 15:05:03 +0000
Subject: [issue23563] Faster urllib.urlparse utility functions
Message-ID: <1425308703.33.0.595640490502.issue23563@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch optimizes utility functions in the urllib.parse module.

$ ./python -m timeit -s "from urllib.parse import splittype" -- "splittype('type:'+'x'*1000)"
Unpatched: 100000 loops, best of 3: 17 usec per loop
Patched:   100000 loops, best of 3: 15 usec per loop

$ ./python -m timeit -s "from urllib.parse import splithost" -- "splithost('//www.example.org:80/foo/bar/baz.html')"
Unpatched: 100000 loops, best of 3: 12.7 usec per loop
Patched:   100000 loops, best of 3: 10.6 usec per loop

$ ./python -m timeit -s "from urllib.parse import splithost" -- "splithost('//www.example.org:80')"
Unpatched: 100000 loops, best of 3: 9.34 usec per loop
Patched:   100000 loops, best of 3: 9.09 usec per loop

$ ./python -m timeit -s "from urllib.parse import splituser" -- "splituser('username:password at example.org:80')"
Unpatched: 100000 loops, best of 3: 8.76 usec per loop
Patched:   100000 loops, best of 3: 3.1 usec per loop

$ ./python -m timeit -s "from urllib.parse import splituser" -- "splituser('example.org:80')"
Unpatched: 100000 loops, best of 3: 5.89 usec per loop
Patched:   100000 loops, best of 3: 1.98 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitpasswd" -- "splitpasswd('username:password')"
Unpatched: 100000 loops, best of 3: 7.38 usec per loop
Patched:   100000 loops, best of 3: 3.08 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitpasswd" -- "splitpasswd('username')"
Unpatched: 100000 loops, best of 3: 5.35 usec per loop
Patched:   100000 loops, best of 3: 1.92 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitnport" -- "splitnport('example.org:80')"
Unpatched: 100000 loops, best of 3: 13.2 usec per loop
Patched:   100000 loops, best of 3: 6.58 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitnport" -- "splitnport('example.org')"
Unpatched: 100000 loops, best of 3: 6.03 usec per loop
Patched:   100000 loops, best of 3: 2.37 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitquery" -- "splitquery('/path?query')"
Unpatched: 100000 loops, best of 3: 8.03 usec per loop
Patched:   100000 loops, best of 3: 3.01 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitquery" -- "splitquery('/path')"
Unpatched: 100000 loops, best of 3: 5.21 usec per loop
Patched:   1000000 loops, best of 3: 1.91 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitvalue" -- "splitvalue('attr=value')"
Unpatched: 100000 loops, best of 3: 7.37 usec per loop
Patched:   100000 loops, best of 3: 2.97 usec per loop

$ ./python -m timeit -s "from urllib.parse import splitvalue" -- "splitvalue('attr')"
Unpatched: 100000 loops, best of 3: 5.13 usec per loop
Patched:   1000000 loops, best of 3: 1.9 usec per loop

This functions are not documented but used in the stdlib and third-party code.

----------
assignee: serhiy.storchaka
components: Library (Lib)
files: urlparse_split_faster.patch
keywords: patch
messages: 237048
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Faster urllib.urlparse utility functions
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file38300/urlparse_split_faster.patch

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

From report at bugs.python.org  Mon Mar  2 16:19:07 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 02 Mar 2015 15:19:07 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <1425309547.34.0.459677590953.issue23539@psf.upfronthosting.co.za>


R. David Murray added the comment:

Don't break backward compatibility.  It's not like this was reported as a bug that caused a problem for real world code, it is about theoretical consistency.  The risk of breaking someone code is much higher than the benefit of any such consistency, when talking about a bug fix.

Aside from that, however, I see request.('GET', '/') and request.('GET', '/', '') as clearly *different* from an API call standpoint, so I would in any case preserve the existing behavior.

----------

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

From report at bugs.python.org  Mon Mar  2 16:24:04 2015
From: report at bugs.python.org (Alex Shkop)
Date: Mon, 02 Mar 2015 15:24:04 +0000
Subject: [issue18383] test_warnings modifies warnings.filters when running
 with "-W default"
In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za>
Message-ID: <1425309844.51.0.837899954192.issue18383@psf.upfronthosting.co.za>


Alex Shkop added the comment:

The issue occurs only if C implementation of _warnings is available. It is caused by re-use of global filters variable from _warnings when warnings is being re-imported.
So warnings modifies _warnings.filters on first import. Then, when you import warnings again it uses already modified version of _warnings.filters and adds same filter for the second time.

I attach a simple patch that prevents duplicates in filters. I'm not sure if this is a best way to fix the problem, but it works. It certainly affects performance of filterwarnings(), but there shouldn't be a lot of filters anyway.

Making filters a set() will solve the problem also, but will require API changes. Although I didn't find anywhere in documentation that warnings.filters should be a list, someone might rely on its .append() method.

----------
nosy: +ashkop
Added file: http://bugs.python.org/file38301/issue18383_remove_dups.patch

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

From report at bugs.python.org  Mon Mar  2 16:45:52 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 02 Mar 2015 15:45:52 +0000
Subject: [issue23562] file.read() followed by file.write() result in incorrect
 behavior
In-Reply-To: <1425307061.83.0.558328246639.issue23562@psf.upfronthosting.co.za>
Message-ID: <1425311152.03.0.288215857372.issue23562@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> TextIOWrapper: issues with interlaced read-write

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

From report at bugs.python.org  Mon Mar  2 16:48:49 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 02 Mar 2015 15:48:49 +0000
Subject: [issue21293] Remove "capsule hack" from object.c?
In-Reply-To: <1397778953.55.0.677894894827.issue21293@psf.upfronthosting.co.za>
Message-ID: <1425311329.21.0.582388825476.issue21293@psf.upfronthosting.co.za>


Steve Dower added the comment:

No current reasons I'm aware of (apart from not having a working up-to-date Windows buildbot right now - blocked on #23524) so I'd say go ahead. Pull it out and see what breaks.

The fact that the comment says "pycapsule.o" and not "pycapsule.obj" probably means this wasn't a Windows issue in the first place.

----------

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

From report at bugs.python.org  Mon Mar  2 16:52:41 2015
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 02 Mar 2015 15:52:41 +0000
Subject: [issue21293] Remove "capsule hack" from object.c?
In-Reply-To: <1397778953.55.0.677894894827.issue21293@psf.upfronthosting.co.za>
Message-ID: <1425311561.6.0.72463779933.issue21293@psf.upfronthosting.co.za>


Larry Hastings added the comment:

You give me too much credit.  I'm the chimp who put it there in the first place.  Though, admittedly, it was a copy&paste job based on the ancient CObject.

My guess is this was very helpful in 1.4, or something.  ;-)

----------

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

From report at bugs.python.org  Mon Mar  2 16:53:25 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 02 Mar 2015 15:53:25 +0000
Subject: [issue9784] _msi.c warnings under 64-bit Windows
In-Reply-To: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>
Message-ID: <1425311605.37.0.71333131455.issue9784@psf.upfronthosting.co.za>


Steve Dower added the comment:

We'd need a contributor agreement from Jon anyway, so unless he rejoins this thread and is willing to sign that, there's little point looking at the patch.

----------

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

From report at bugs.python.org  Mon Mar  2 16:56:57 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 02 Mar 2015 15:56:57 +0000
Subject: [issue23558] Unable to install Python 3.4.3 amd64 on Windows 8.1
In-Reply-To: <1425225058.12.0.9521786559.issue23558@psf.upfronthosting.co.za>
Message-ID: <1425311817.16.0.283617358456.issue23558@psf.upfronthosting.co.za>


Steve Dower added the comment:

Glad you got it sorted out. I've done exactly the same thing too.

The 3.5 installer is designed to have no impact on earlier versions, and also has different default directories for 32-bit vs. 64-bit, which will help prevent these problems in the future.

----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Mon Mar  2 17:01:50 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Mar 2015 16:01:50 +0000
Subject: [issue23451] Deprecation warnings building 3.5 Visual Studio Windows
 8.1 64 bit
In-Reply-To: <1423697646.35.0.470486317043.issue23451@psf.upfronthosting.co.za>
Message-ID: <20150302160133.53145.52679@psf.io>


Roundup Robot added the comment:

New changeset 57e2549cc9a6 by Steve Dower in branch 'default':
Issue #23451: Update pyconfig.h for Windows to require Vista headers and remove unnecessary version checks.
https://hg.python.org/cpython/rev/57e2549cc9a6

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Mar  2 17:03:13 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 02 Mar 2015 16:03:13 +0000
Subject: [issue23451] Deprecation warnings building 3.5 Visual Studio Windows
 8.1 64 bit
In-Reply-To: <1423697646.35.0.470486317043.issue23451@psf.upfronthosting.co.za>
Message-ID: <1425312193.42.0.621477936494.issue23451@psf.upfronthosting.co.za>


Steve Dower added the comment:

The _WINSOCK_DEPRECATED_NO_WARNINGS question is still open, but the rest of the deprecations should be clear now.

----------

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

From report at bugs.python.org  Mon Mar  2 17:06:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Mar 2015 16:06:58 +0000
Subject: [issue18382] multiprocessing's overlapped PipeConnection issues on
 Windows 8
In-Reply-To: <1373114737.55.0.0779572840335.issue18382@psf.upfronthosting.co.za>
Message-ID: <20150302160645.34518.43763@psf.io>


Roundup Robot added the comment:

New changeset 7401a28d3d41 by Steve Dower in branch '3.4':
Issue #18382: Zero-length messages are consumed by ReadFile on Windows 8 and later
https://hg.python.org/cpython/rev/7401a28d3d41

New changeset 6ccbcf1df7bd by Steve Dower in branch 'default':
Issue #18382: Zero-length messages are consumed by ReadFile on Windows 8 and later
https://hg.python.org/cpython/rev/6ccbcf1df7bd

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Mar  2 17:07:30 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 02 Mar 2015 16:07:30 +0000
Subject: [issue18382] multiprocessing's overlapped PipeConnection issues on
 Windows 8
In-Reply-To: <1373114737.55.0.0779572840335.issue18382@psf.upfronthosting.co.za>
Message-ID: <1425312450.51.0.268271996357.issue18382@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at microsoft.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Mar  2 17:21:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Mar 2015 16:21:38 +0000
Subject: [issue23367] integer overflow in unicodedata.normalize
In-Reply-To: <1422799035.27.0.978256662941.issue23367@psf.upfronthosting.co.za>
Message-ID: <20150302162134.16404.34175@psf.io>


Roundup Robot added the comment:

New changeset 84025a32fa2b by Benjamin Peterson in branch '3.3':
fix possible overflow bugs in unicodedata (closes #23367)
https://hg.python.org/cpython/rev/84025a32fa2b

New changeset 90f960e79c9e by Benjamin Peterson in branch '3.4':
merge 3.3 (#23367)
https://hg.python.org/cpython/rev/90f960e79c9e

New changeset 93244000efea by Benjamin Peterson in branch 'default':
merge 3.4 (#23367)
https://hg.python.org/cpython/rev/93244000efea

New changeset 3019effc44f2 by Benjamin Peterson in branch '2.7':
fix possible overflow bugs in unicodedata (closes #23367)
https://hg.python.org/cpython/rev/3019effc44f2

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Mar  2 17:45:40 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Mar 2015 16:45:40 +0000
Subject: [issue21293] Remove "capsule hack" from object.c?
In-Reply-To: <1397778953.55.0.677894894827.issue21293@psf.upfronthosting.co.za>
Message-ID: <20150302164504.39492.56330@psf.io>


Roundup Robot added the comment:

New changeset b22755f8ab5f by Larry Hastings in branch 'default':
Issue #21293: Remove unnecessary "capsule hack".
https://hg.python.org/cpython/rev/b22755f8ab5f

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Mar  2 17:46:51 2015
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 02 Mar 2015 16:46:51 +0000
Subject: [issue21293] Remove "capsule hack" from object.c?
In-Reply-To: <1397778953.55.0.677894894827.issue21293@psf.upfronthosting.co.za>
Message-ID: <1425314811.84.0.531900960231.issue21293@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Yeah, I went ahead and checked this in.  I'm living life on the *edge*.

To the EXTREME!

----------
assignee:  -> larry
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Mar  2 17:50:12 2015
From: report at bugs.python.org (Hisham Muhammad)
Date: Mon, 02 Mar 2015 16:50:12 +0000
Subject: [issue23564] Patch fixing sanity check for ordered fd sequence in
 _posixsubprocess.c
Message-ID: <1425315012.54.0.714244886784.issue23564@psf.upfronthosting.co.za>


New submission from Hisham Muhammad:

In Modules/_posixsubprocess.c, (the helper module for Lib/subprocess.py) there's a function called _sanity_check_python_fd_sequence which checks, as its comment says, if the fds in the sequence are all positive and sorted.

The check to verify if it is sorted is incorrect (missing the update to the prev_fd variable), and also it is missing a test to see if fd's are repeated (which they shouldn't be, so the test should use <= rather than <). 

The attached patch, written against Python 3.4.3 source code, fixes it.

----------
components: Extension Modules
files: python-3.4.3-_posixsubprocess.c.fix.patch
keywords: patch
messages: 237061
nosy: Hisham Muhammad
priority: normal
severity: normal
status: open
title: Patch fixing sanity check for ordered fd sequence in _posixsubprocess.c
versions: Python 3.4
Added file: http://bugs.python.org/file38302/python-3.4.3-_posixsubprocess.c.fix.patch

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

From report at bugs.python.org  Mon Mar  2 17:58:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 16:58:28 +0000
Subject: [issue23367] integer overflow in unicodedata.normalize
In-Reply-To: <1422799035.27.0.978256662941.issue23367@psf.upfronthosting.co.za>
Message-ID: <1425315508.1.0.719346148534.issue23367@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Actually integer overflow in the line

    space = (isize > 10 ? 10 : isize) + isize;

is not possible.

Integer overflows in PyMem_Malloc were fixed in issue23446.

----------

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

From report at bugs.python.org  Mon Mar  2 18:01:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 17:01:04 +0000
Subject: [issue23368] integer overflow in _PyUnicode_AsKind
In-Reply-To: <1422799119.61.0.313717828667.issue23368@psf.upfronthosting.co.za>
Message-ID: <1425315664.88.0.185156129009.issue23368@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Mon Mar  2 18:02:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 17:02:15 +0000
Subject: [issue23362] integer overflow in string translate
In-Reply-To: <1422798800.96.0.0931437199134.issue23362@psf.upfronthosting.co.za>
Message-ID: <1425315735.54.0.0334952908054.issue23362@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

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

From report at bugs.python.org  Mon Mar  2 18:14:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 17:14:41 +0000
Subject: [issue23446] Use PyMem_New instead of PyMem_Malloc
In-Reply-To: <1423675815.31.0.721977402363.issue23446@psf.upfronthosting.co.za>
Message-ID: <1425316481.85.0.911780733751.issue23446@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be apply the fix to 3.3?

----------

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

From report at bugs.python.org  Mon Mar  2 18:15:38 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 17:15:38 +0000
Subject: [issue23368] integer overflow in _PyUnicode_AsKind
In-Reply-To: <1422799119.61.0.313717828667.issue23368@psf.upfronthosting.co.za>
Message-ID: <1425316538.07.0.854307110741.issue23368@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Was fixed as part of issue23446.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Mar  2 18:16:33 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 17:16:33 +0000
Subject: [issue23368] integer overflow in _PyUnicode_AsKind
In-Reply-To: <1422799119.61.0.313717828667.issue23368@psf.upfronthosting.co.za>
Message-ID: <1425316593.74.0.600582718009.issue23368@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution: fixed -> out of date

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

From report at bugs.python.org  Mon Mar  2 18:19:31 2015
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 02 Mar 2015 17:19:31 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425309547.34.0.459677590953.issue23539@psf.upfronthosting.co.za>
Message-ID: <AD2B0643-5E47-47B2-BAC0-24A1F0CBF8F8@gmail.com>


Demian Brecht added the comment:

> Aside from that, however, I see request.('GET', '/') and request.('GET', '/', '') as clearly *different* from an API call standpoint, so I would in any case preserve the existing behavior.

I do understand the case that the the two examples look different from a caller?s standpoint. However as a user, I?d expect the library to do the Right Thing due to a deeper understanding of the theory behind the API that I?m using. Perhaps it would have made more sense to default body to empty string rather than None in which case there wouldn?t be a need for this distinction.

That said, I do understand the reasoning behind not breaking backwards compatibility and it?s not a problem until reported and am not looking to get into an API design argument (especially for something as low impact as what I was proposing). So @James, I stand corrected :)

----------

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

From report at bugs.python.org  Mon Mar  2 18:41:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 02 Mar 2015 17:41:15 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <1425318075.44.0.984104568378.issue23539@psf.upfronthosting.co.za>


R. David Murray added the comment:

Not to get into an API argument, but rather to convey some Python philosophy as I understand it: there *is* often a distinction in Python between the value 'None' and a boolean-False-value like ''.  It is often the case in Python APIs that None means something different from other arguably-semantically-equivalent values.  In this case I believe it is entirely logical that 'None' (the default value) for a method that does not normally take a body and makes a distinction based on Content-Length (or some other header) makes sense, and that explicitly saying "I want an empty body, including the standard headers" is actually a sensible Python API.  If we were designing it from scratch with these issues in mind, we might well come up with exactly what we've got...or we might not, because wanting to specify an empty body on such a command is a really low probability event :)

Regardless, we're constrained by backward compatibility here, so the question is moot.

----------

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

From report at bugs.python.org  Mon Mar  2 18:51:39 2015
From: report at bugs.python.org (James Rutherford)
Date: Mon, 02 Mar 2015 17:51:39 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <1425318699.23.0.0621470824173.issue23539@psf.upfronthosting.co.za>


James Rutherford added the comment:

OK, sounds like we're approaching consensus? And I believe that the patch as-is captures that consensus, so should I proceed and make another for 3.X for review?

----------

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

From report at bugs.python.org  Mon Mar  2 18:58:09 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 02 Mar 2015 17:58:09 +0000
Subject: [issue23367] integer overflow in unicodedata.normalize
In-Reply-To: <1422799035.27.0.978256662941.issue23367@psf.upfronthosting.co.za>
Message-ID: <1425319089.28.0.699626033939.issue23367@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Why can't (isize > 10 ? 10 : isize) + isize overflow?

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Mon Mar  2 19:05:08 2015
From: report at bugs.python.org (Andy Maier)
Date: Mon, 02 Mar 2015 18:05:08 +0000
Subject: [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1425319508.39.0.53807448501.issue12067@psf.upfronthosting.co.za>


Changes by Andy Maier <andreas.r.maier at gmx.de>:


Added file: http://bugs.python.org/file38303/issue12067-expressions-py3.5_v14.diff

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

From report at bugs.python.org  Mon Mar  2 19:12:09 2015
From: report at bugs.python.org (Andy Maier)
Date: Mon, 02 Mar 2015 18:12:09 +0000
Subject: [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1425319929.16.0.585512140955.issue12067@psf.upfronthosting.co.za>


Andy Maier added the comment:

I have posted v14 of the patch (for the 3.5 'default' branch), based on Martin's v13. v14 addresses all comments Martin made, as described in my responses to them (see patch set 10).

On Issue 4395: That issue should be pursued in addition to this issue; it seems Martin's patch for it is complementary to the patch for this issue here.

On Issue 22000: I agree that that issue is addressed by the patch for this issue here.

All: Please review the v14 patch.

----------

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

From report at bugs.python.org  Mon Mar  2 19:24:37 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Mar 2015 18:24:37 +0000
Subject: [issue23362] integer overflow in string translate
In-Reply-To: <1422798800.96.0.0931437199134.issue23362@psf.upfronthosting.co.za>
Message-ID: <20150302182427.20299.4585@psf.io>


Roundup Robot added the comment:

New changeset 21cd7f83e0aa by Benjamin Peterson in branch '3.3':
use PyMem_NEW to detect overflow (closes #23362)
https://hg.python.org/cpython/rev/21cd7f83e0aa

New changeset 880906bbf792 by Benjamin Peterson in branch '3.4':
merge 3.3 (#23362)
https://hg.python.org/cpython/rev/880906bbf792

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Mar  2 19:24:55 2015
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 02 Mar 2015 18:24:55 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425318699.23.0.0621470824173.issue23539@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOTXydpUy41R3y1JhTQq-HRtXeEnWjTR=uQ8N_QHU-Remw@mail.gmail.com>


Senthil Kumaran added the comment:

One patch should be enough, @James. The committer will take care of
porting. Thanks!  ( I am yet to completely read the discussion/ review the
patch and I will do that shortly.)

----------

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

From report at bugs.python.org  Mon Mar  2 19:24:58 2015
From: report at bugs.python.org (Eldar Abusalimov)
Date: Mon, 02 Mar 2015 18:24:58 +0000
Subject: [issue21919] Changing cls.__bases__ must ensure proper metaclass
 inheritance
In-Reply-To: <1404506725.35.0.943770437276.issue21919@psf.upfronthosting.co.za>
Message-ID: <1425320698.13.0.855595602074.issue21919@psf.upfronthosting.co.za>


Eldar Abusalimov added the comment:

@Mark, that OK, for the issue without a patch. :)

I could make a patch, but I'm not sure whether the proposed behavior is right. It could be considered arguable, I guess...

----------

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

From report at bugs.python.org  Mon Mar  2 19:44:12 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Mon, 02 Mar 2015 18:44:12 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425321852.76.0.944491652803.issue23496@psf.upfronthosting.co.za>


Ryan Gonzalez added the comment:

Cyd:

I was trying to see if I could build the latest Python for Android (not to get it to run; just to get it to compile) so that your changes would (theoretically) easier to update to the latest Python. That failed. Miserably. Joys of cross-compiling Python.

So...I'm just going to wait for you to finish uploaded the changes and work from there. :)

----------

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

From report at bugs.python.org  Mon Mar  2 19:46:54 2015
From: report at bugs.python.org (Michael Foord)
Date: Mon, 02 Mar 2015 18:46:54 +0000
Subject: [issue23469] Delete Misc/*.wpr files
In-Reply-To: <1424048342.99.0.00819785192711.issue23469@psf.upfronthosting.co.za>
Message-ID: <1425322014.17.0.881658979324.issue23469@psf.upfronthosting.co.za>


Michael Foord added the comment:

What is the advantage to deleting the Wing IDE project files, other than making it harder to use Wing to work on Python?

----------

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

From report at bugs.python.org  Mon Mar  2 19:55:44 2015
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 02 Mar 2015 18:55:44 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425318699.23.0.0621470824173.issue23539@psf.upfronthosting.co.za>
Message-ID: <DC7E355C-522E-489B-941E-9CB076AD75A4@gmail.com>


Demian Brecht added the comment:

> OK, sounds like we're approaching consensus? And I believe that the patch as-is captures that consensus

Yes, I believe that we?ve reached a consensus and that your patch captures it. Thanks for the work!

----------

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

From report at bugs.python.org  Mon Mar  2 19:56:05 2015
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 02 Mar 2015 18:56:05 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <1425322565.69.0.645399643362.issue23539@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
stage: patch review -> commit review

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

From report at bugs.python.org  Mon Mar  2 19:59:12 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 02 Mar 2015 18:59:12 +0000
Subject: [issue23446] Use PyMem_New instead of PyMem_Malloc
In-Reply-To: <1423675815.31.0.721977402363.issue23446@psf.upfronthosting.co.za>
Message-ID: <1425322752.39.0.022437630005.issue23446@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

That would be nice.

----------

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

From report at bugs.python.org  Mon Mar  2 20:24:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 19:24:18 +0000
Subject: [issue23367] integer overflow in unicodedata.normalize
In-Reply-To: <1422799035.27.0.978256662941.issue23367@psf.upfronthosting.co.za>
Message-ID: <1425324258.32.0.480984805114.issue23367@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Because isize is the size of real PyUnicode object. It's maximal value is PY_SSIZE_T_MAX - sizeof(PyASCIIObject) - 1.

----------

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

From report at bugs.python.org  Mon Mar  2 20:25:43 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Mar 2015 19:25:43 +0000
Subject: [issue23362] integer overflow in string translate
In-Reply-To: <1422798800.96.0.0931437199134.issue23362@psf.upfronthosting.co.za>
Message-ID: <1425324343.88.0.232028132577.issue23362@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee: serhiy.storchaka -> benjamin.peterson
nosy: +benjamin.peterson

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

From report at bugs.python.org  Mon Mar  2 20:45:23 2015
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 02 Mar 2015 19:45:23 +0000
Subject: [issue23565] local_clear walks the list of threads without holding
 head_lock.
Message-ID: <1425325523.34.0.879276411027.issue23565@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach:

local_clear in _threadmodule.c walks the list of threads without holding head_mutex.  Since the list of threads can change when holding only head_mutex and not on the GIL, the list can change while local_clear is executing, which may cause Bad Things to happen.

----------
components: Library (Lib)
messages: 237078
nosy: stutzbach
priority: normal
severity: normal
status: open
title: local_clear walks the list of threads without holding head_lock.
type: behavior

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

From report at bugs.python.org  Mon Mar  2 21:07:21 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 02 Mar 2015 20:07:21 +0000
Subject: [issue23342] run() - unified high-level interface for subprocess
In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za>
Message-ID: <1425326841.89.0.367448249393.issue23342@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Is there anything further I should be doing for this?

----------

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

From report at bugs.python.org  Mon Mar  2 21:17:09 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Mar 2015 20:17:09 +0000
Subject: [issue23367] integer overflow in unicodedata.normalize
In-Reply-To: <1425324258.32.0.480984805114.issue23367@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaS1bwdysXhzvX1+mUGXqjALuv-Q3unVAsGzhWj9hZd_A@mail.gmail.com>


STINNER Victor added the comment:

Well, the test doesn't hurt.

----------

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

From report at bugs.python.org  Mon Mar  2 21:18:17 2015
From: report at bugs.python.org (Carlo Beccarini)
Date: Mon, 02 Mar 2015 20:18:17 +0000
Subject: [issue23512] The list of built-in functions is not alphabetical on
 https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425327497.55.0.878361746534.issue23512@psf.upfronthosting.co.za>


Carlo Beccarini added the comment:

diff -r 3019effc44f2 Doc/library/functions.rst
--- a/Doc/library/functions.rst	Mon Mar 02 11:17:05 2015 -0500
+++ b/Doc/library/functions.rst	Mon Mar 02 21:13:27 2015 +0100
@@ -22,10 +22,10 @@
 :func:`classmethod`  :func:`getattr`    :func:`map`         |func-repr|_       :func:`xrange`
 :func:`cmp`          :func:`globals`    :func:`max`         :func:`reversed`   :func:`zip`
 :func:`compile`      :func:`hasattr`    |func-memoryview|_  :func:`round`      :func:`__import__`
-:func:`complex`      :func:`hash`       :func:`min`         |func-set|_        :func:`apply`
-:func:`delattr`      :func:`help`       :func:`next`        :func:`setattr`    :func:`buffer`
-|func-dict|_         :func:`hex`        :func:`object`      :func:`slice`      :func:`coerce`
-:func:`dir`          :func:`id`         :func:`oct`         :func:`sorted`     :func:`intern`
+:func:`complex`      :func:`hash`       :func:`min`         |func-set|_        ..
+:func:`delattr`      :func:`help`       :func:`next`        :func:`setattr`    ..
+|func-dict|_         :func:`hex`        :func:`object`      :func:`slice`      ..
+:func:`dir`          :func:`id`         :func:`oct`         :func:`sorted`     ..
 ===================  =================  ==================  =================  ====================
 
 .. using :func:`dict` would create a link to another page, so local targets are
@@ -1699,6 +1699,11 @@
 Python programmers, trainers, students and book writers should feel free to
 bypass these functions without concerns about missing something important.
 
+===================  =================  ==================  =================
+..                     Non-essential    Built-in Functions  ..
+===================  =================  ==================  =================
+:func:`apply`        :func:`buffer`     :func:`coerce`      :func:`intern`
+===================  =================  ==================  =================
 
 .. function:: apply(function, args[, keywords])

----------
Added file: http://bugs.python.org/file38304/functools.rst

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

From report at bugs.python.org  Mon Mar  2 21:23:09 2015
From: report at bugs.python.org (SilentGhost)
Date: Mon, 02 Mar 2015 20:23:09 +0000
Subject: [issue23512] The list of built-in functions is not alphabetical on
 https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425327789.57.0.845668058344.issue23512@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Removed file: http://bugs.python.org/file38304/functools.rst

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

From report at bugs.python.org  Mon Mar  2 21:27:08 2015
From: report at bugs.python.org (Carlo Beccarini)
Date: Mon, 02 Mar 2015 20:27:08 +0000
Subject: [issue23512] The list of built-in functions is not alphabetical on
 https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425328028.4.0.93613035216.issue23512@psf.upfronthosting.co.za>


Changes by Carlo Beccarini <hackdiablo.cb at gmail.com>:


Added file: http://bugs.python.org/file38305/functions.rst

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

From report at bugs.python.org  Mon Mar  2 21:30:56 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Mar 2015 20:30:56 +0000
Subject: [issue19075] Add sorting algorithm visualization to turtledemo
In-Reply-To: <1379872942.6.0.509488553247.issue19075@psf.upfronthosting.co.za>
Message-ID: <20150302203030.19140.92656@psf.io>


Roundup Robot added the comment:

New changeset 596228491890 by Ethan Furman in branch 'default':
issue19075: add visual sorting algorithms to turtledemo; original code from Jason Yeo
https://hg.python.org/cpython/rev/596228491890

----------
nosy: +python-dev

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

From report at bugs.python.org  Mon Mar  2 21:32:42 2015
From: report at bugs.python.org (Davin Potts)
Date: Mon, 02 Mar 2015 20:32:42 +0000
Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if
 sem_open is not implemented
In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za>
Message-ID: <1425328362.47.0.077640720292.issue23400@psf.upfronthosting.co.za>


Davin Potts added the comment:

Attaching a further revised patch for 3.4 and 3.5/default, now with cleaned-up code style per the discussion in the review.

No changes are prompted for the patch to 2.7 as it only contained changes to the docs and nothing code-related.

Thanks again goes to Berker for the guidance.

----------
Added file: http://bugs.python.org/file38306/issue23400_py35_and_py34_improveddocsandstyle.patch

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

From report at bugs.python.org  Mon Mar  2 21:50:11 2015
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 02 Mar 2015 20:50:11 +0000
Subject: [issue19075] Add sorting algorithm visualization to turtledemo
In-Reply-To: <1379872942.6.0.509488553247.issue19075@psf.upfronthosting.co.za>
Message-ID: <1425329411.48.0.196501790096.issue19075@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee:  -> ethan.furman
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Mar  2 21:54:26 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 02 Mar 2015 20:54:26 +0000
Subject: [issue23367] integer overflow in unicodedata.normalize
In-Reply-To: <1425324258.32.0.480984805114.issue23367@psf.upfronthosting.co.za>
Message-ID: <1425329662.939405.234536397.48733850@webmail.messagingengine.com>


Benjamin Peterson added the comment:

True, but that could change and is not true in Python 2. I suppose we
could revert the change and add a static assertion.
On Mon, Mar 2, 2015, at 14:24, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
> Because isize is the size of real PyUnicode object. It's maximal value is
> PY_SSIZE_T_MAX - sizeof(PyASCIIObject) - 1.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue23367>
> _______________________________________

----------

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

From report at bugs.python.org  Mon Mar  2 22:03:46 2015
From: report at bugs.python.org (Davin Potts)
Date: Mon, 02 Mar 2015 21:03:46 +0000
Subject: [issue21342] multiprocessing RLock and Lock raise incorrect
 exceptions when releasing an unlocked lock.
In-Reply-To: <1398319251.34.0.871128764935.issue21342@psf.upfronthosting.co.za>
Message-ID: <1425330226.92.0.589879888181.issue21342@psf.upfronthosting.co.za>


Davin Potts added the comment:

The discussion in issue23484 is leading to a recommendation that the docs be changed to reflect the actual behavior of multiprocessing's Lock and its close relatives.

As far back as 2.6.9, calling release() on an unlocked threading.Lock triggered a thread.error Exception whereas doing the same on multiprocessing.Lock triggered a ValueError.  This discrepancy in the behavior of Lock between modules turns out to not be a recent development.

If issue23484 moves forward with changing the documentation to reflect reality, this issue would be addressed as well.

----------
dependencies: +SemLock acquire() keyword arg 'blocking' is invalid
nosy: +davin

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

From report at bugs.python.org  Mon Mar  2 22:14:26 2015
From: report at bugs.python.org (Edward D'Souza)
Date: Mon, 02 Mar 2015 21:14:26 +0000
Subject: [issue23512] The list of built-in functions is not alphabetical on
 https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425330866.05.0.368173524955.issue23512@psf.upfronthosting.co.za>


Edward D'Souza added the comment:

I think putting them in a separate table is good, but I think it makes more sense to appear right below the existing table at the top of the page. For better or worse, these "non-essential" functions are still builtins in Python 2.

It would be disconcerting if you went to this page looking for a builtin (eg. coerce) and couldn't find it at the top of the page with the other builtins.

Above all, the list of "builtins" should be accurate as to what builtins actually exist in Python 2.

----------

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

From report at bugs.python.org  Mon Mar  2 22:59:58 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 02 Mar 2015 21:59:58 +0000
Subject: [issue23512] The list of built-in functions is not alphabetical on
 https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425333598.65.0.142252211486.issue23512@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

> It would be disconcerting if you went to this page looking for a builtin [and had trouble finding it]

I agree with this premise.  Since Idle, and I presume other IDEs, color code apply, coerce, intern, and buffer as builtins indistinguishably from all the others, these 4 should somehow be easy to find in or just below the rest.  I have no particular opinion on the best way to do so.

----------

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

From report at bugs.python.org  Mon Mar  2 23:00:46 2015
From: report at bugs.python.org (Carlo Beccarini)
Date: Mon, 02 Mar 2015 22:00:46 +0000
Subject: [issue23512] The list of built-in functions is not alphabetical on
 https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425333646.72.0.482178570348.issue23512@psf.upfronthosting.co.za>


Changes by Carlo Beccarini <hackdiablo.cb at gmail.com>:


Added file: http://bugs.python.org/file38307/functions.rst

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

From report at bugs.python.org  Mon Mar  2 23:35:45 2015
From: report at bugs.python.org (Yassine ABOUKIR)
Date: Mon, 02 Mar 2015 22:35:45 +0000
Subject: [issue23505] Urlparse insufficient validation leads to open redirect
In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za>
Message-ID: <1425335745.07.0.785799257837.issue23505@psf.upfronthosting.co.za>


Yassine ABOUKIR added the comment:

For your information, this security issue has been assigned a CVE ID : CVE-2015-2104

----------

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

From report at bugs.python.org  Tue Mar  3 00:53:20 2015
From: report at bugs.python.org (Akira Li)
Date: Mon, 02 Mar 2015 23:53:20 +0000
Subject: [issue23494] adding timedelta to datetime object is not timezone aware
In-Reply-To: <1424461574.53.0.989762969133.issue23494@psf.upfronthosting.co.za>
Message-ID: <1425340400.48.0.400725291305.issue23494@psf.upfronthosting.co.za>


Akira Li added the comment:

pytz explicitly documents this case (crossing DST boundary). There is 
tz.normalize() method.

> the tzinfo object is responsible for handling daylight savings time.  This looks like a bug in pytz.

Are any of tzinfo methods even called during `before + timedelta(days=2)`?

Also a DST transition is not the only reason the utc offset or tzname may 
change.

----------
nosy: +akira

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

From report at bugs.python.org  Tue Mar  3 00:54:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Mar 2015 23:54:15 +0000
Subject: [issue23505] Urlparse insufficient validation leads to open redirect
In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za>
Message-ID: <1425340455.72.0.458086049055.issue23505@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> This can be practically exploited this way : http://example.com/login?next=/////evil.com

Can you please elaborate on the "exploit" part? 

In Firefox, the "////etc/passwd" link shows me my local file /etc/passwd. Ok, but how is it an issue?

"//etc/passwd" also shows me file:////etc/passwd.

The OWASP article on Open Redirect shows example to redirect to a different website. Can you should an example how redirect to a website and not a file:// URL?

https://www.owasp.org/index.php/Open_redirect

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

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

From report at bugs.python.org  Tue Mar  3 01:00:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 00:00:15 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
Message-ID: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Currently, functions of the faulthandler module require a file-like object (with a fileno() method). It would be nice to accept also file descriptors (int).

Example of code using faulthandler which creates an useless file object just to pass a file descriptor:
https://github.com/nicoddemus/pytest-faulthandler/blob/master/pytest_faulthandler.py#L13

----------
keywords: easy
messages: 237091
nosy: haypo
priority: normal
severity: normal
status: open
title: RFE: faulthandler.register() should support file descriptors
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar  3 01:01:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 00:01:15 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>
Message-ID: <1425340875.0.0.549747218975.issue23566@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Only faulthandler_get_fileno() should be modified, but a new unit test should be added.

----------

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

From report at bugs.python.org  Tue Mar  3 01:04:30 2015
From: report at bugs.python.org (Yassine ABOUKIR)
Date: Tue, 03 Mar 2015 00:04:30 +0000
Subject: [issue23505] Urlparse insufficient validation leads to open redirect
In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za>
Message-ID: <1425341070.56.0.117468743202.issue23505@psf.upfronthosting.co.za>


Yassine ABOUKIR added the comment:

Yes, exploiting this bug an attacker may redirect a specific vitim to a malicious website, in our case evil.com

>>> x = urlparse("////evil.com")

///evil.com will be parsed as relative-path URL which is the correct expected behaviour

>>> print x
>>> ParseResult(scheme='', netloc='', path='//evil.com', params='', query='', fragment='')

As you see two slashes are removed and it is marked as a relative-path URL but when we reconstruct the URL using urlunparse() function, the URL is treated as an absolute URL to which you will be redirected.

>>> x = urlunparse(urlparse("////evil.com"))
>>> urlparse(x)
ParseResult(scheme='', netloc='evil.com', path='', params='', query='', fragment='')

----------

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

From report at bugs.python.org  Tue Mar  3 01:09:29 2015
From: report at bugs.python.org (Hammerite)
Date: Tue, 03 Mar 2015 00:09:29 +0000
Subject: [issue23550] Add to unicodedata a function to query the "Quick_Check"
 property for a character
In-Reply-To: <1425147670.05.0.762030398058.issue23550@psf.upfronthosting.co.za>
Message-ID: <1425341369.08.0.718569071625.issue23550@psf.upfronthosting.co.za>


Hammerite added the comment:

Here is an initial attempt at a patch that implements the new function.

Notes on this patch:

- The function as implemented here returns a string: "Yes", "No", or "Maybe". In light of the fact that Python now has enums, it is probably more appropriate that unicodedata contain an enum (QuickCheckValue, say) that has Yes, No and Maybe as values, and that the function return values from the enum. However, I do not know how to implement this in C and I do not know where I might look for an example of where something like this is done (in C) already in the CPython codebase, so I have not done that.

- My example code in the initial message on this issue was in error, as it assumed that the new function would return a Boolean value. In fact, there are three possible return values (Yes, No and Maybe), and corrected code would test the return value for equality with a string (as I have implemented the function) or for equality or identity with an enum value.

- When I first generated a patch, it was very long and consisted mostly of changes to three generated header files; these changes accounted for a total of about 60,000 lines' worth of patch file and appeared to be almost entirely spurious. Although one or more of these header files will genuinely be generated differently on account of my changes (a new string array _PyUnicode_QuickCheckNames is now present, along the same lines as the pre-existing 'Names' arrays), I have omitted them from the diff for being extremely bulky and for being generated code in any case.

----------
keywords: +patch
Added file: http://bugs.python.org/file38308/quick_check_x.patch

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

From report at bugs.python.org  Tue Mar  3 01:10:20 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 03 Mar 2015 00:10:20 +0000
Subject: [issue17352] Be clear that __prepare__ must be declared as a class
 method
In-Reply-To: <1362409892.83.0.717786566871.issue17352@psf.upfronthosting.co.za>
Message-ID: <1425341420.2.0.557808953232.issue17352@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Should __prepare__ be special-cased as a classmethod, like __new__ is?  Is there any reason to ever have __prepare__ /not/ be a classmethod?

----------

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

From report at bugs.python.org  Tue Mar  3 01:11:47 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 00:11:47 +0000
Subject: [issue23505] Urlparse insufficient validation leads to open redirect
In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za>
Message-ID: <1425341507.11.0.406157106116.issue23505@psf.upfronthosting.co.za>


STINNER Victor added the comment:

>>> urlparse("//evil.com")
ParseResult(scheme='', netloc='evil.com', path='', params='', query='', fragment='')

I see evil.com in the netloc field, ok. But Firefox doesn't use Python to parse and url, and typing //evil.com in the address bar converts the address to file:////evil.com. Not a website, but a local file.

So I don't understand the redirection part. Could you maybe write a vulnerable CGI script to demonstrate the bug?

I wrote the following HTML file to try to understand the bug, but I was only able to show the content of my local file /etc/issue:

<head>
    <META http-equiv="refresh" content="5;URL=////etc/issue">
</head>
<p><a href="////etc/issue">issue</a></p>

----------

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

From report at bugs.python.org  Tue Mar  3 01:21:44 2015
From: report at bugs.python.org (Yassine ABOUKIR)
Date: Tue, 03 Mar 2015 00:21:44 +0000
Subject: [issue23505] Urlparse insufficient validation leads to open redirect
In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za>
Message-ID: <1425342104.28.0.189830519695.issue23505@psf.upfronthosting.co.za>


Yassine ABOUKIR added the comment:

When you directly type //evil.com or ////evil.com in Firefox URL bar you will be redirect to evil.com and that is very known, read this : 

http://homakov.blogspot.com/2014/01/evolution-of-open-redirect-vulnerability.html

Here is a video demonstration of the vulnerability : http://youtu.be/l0uDAqpRPpo

----------

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

From report at bugs.python.org  Tue Mar  3 01:34:23 2015
From: report at bugs.python.org (Akira Li)
Date: Tue, 03 Mar 2015 00:34:23 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425342863.97.0.109656160155.issue21619@psf.upfronthosting.co.za>


Akira Li added the comment:

On Windows behavior
http://stackoverflow.com/questions/23688492/oserror-errno-22-invalid-argument-in-subprocess

----------
nosy: +akira

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

From report at bugs.python.org  Tue Mar  3 02:16:11 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 03 Mar 2015 01:16:11 +0000
Subject: [issue23567] os.stat() tuple access vs named attribute access int vs
 float
Message-ID: <1425345371.02.0.709789700046.issue23567@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
>>> import os, stat
>>> os.stat('/')
posix.stat_result(st_mode=16877, st_ino=2, st_dev=64513L, st_nlink=29, st_uid=0, st_gid=0, st_size=4096, st_atime=1425341751, st_mtime=1424824650, st_ctime=1424824650)
>>> x =os.stat('/')
>>> x.st_mtime
1424824650.653934
>>> x[stat.ST_MTIME]
1424824650
>>> os.stat_result
<type 'posix.stat_result'>


I have also confirmed the same behavior in 3.4.2.

This may be intentional.  Tuple [stat.ST_XXX] access to the stat return value is the old legacy way to access these prior to Python 2.2 when the stat_result object was introduced.  At that point they were likely all ints.

The os.stat_float_times() API exists to change the behavior of stat_result objects to return ints instead of floats by default, but the behavior of the tuple indexed values is always ints.

We need to explicitly document this behavior difference.  Changing the legacy tuple indexing behavior to return a float would likely break code.

Why file this?  We just ran into a bug due to code comparing a [stat.ST_MTIME] value to a stored stat_result.st_mtime thus continually reporting a difference due to the precision difference between the two but the numeric comparison doing its job regardless.

----------
components: Library (Lib)
messages: 237099
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: os.stat() tuple access vs named attribute access int vs float
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar  3 02:46:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 01:46:05 +0000
Subject: [issue23285] PEP 475 - EINTR handling
In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za>
Message-ID: <1425347165.89.0.0960055979323.issue23285@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The change on Modules/_io/fileio.c is wrong: functions may return None with an exception set. It is wrong because a function must return a result with no exception set, or NULL and an exception set.

Attached patch fixes this issue.

----------
Added file: http://bugs.python.org/file38309/fileio.patch

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

From report at bugs.python.org  Tue Mar  3 02:49:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 01:49:15 +0000
Subject: [issue23285] PEP 475 - EINTR handling
In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za>
Message-ID: <1425347355.3.0.570071996512.issue23285@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Note: I found the bug while working on a patch for #22181.

My test is this shell script:

$ while true; do ./python -c 'import os, signal; signal.setitimer(signal.ITIMER_REAL, 0.001, 0.0001); signal.signal(signal.SIGALRM, lambda *args: print(".", end="")); print("urandom"); x=os.urandom(5000); print("ok"); signal.alarm(0)'; if [ $? -ne 142 -a $? -ne 0 ]; then break; fi done  

The test calls print() in a signal handler which can likely create a reentrant call, which is forbidden. But Python handles this case, it's fine.

After removing all debug prints and reverting the fix on fileio.c, the test doesn't crash with the assertion error anymore. Before, an assertion failed because fileio_write() returned Py_None with an exception set.

----------

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

From report at bugs.python.org  Tue Mar  3 03:04:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 02:04:17 +0000
Subject: [issue22181] os.urandom() should use Linux 3.17 getrandom() syscall
In-Reply-To: <1407713563.4.0.264701036097.issue22181@psf.upfronthosting.co.za>
Message-ID: <1425348257.63.0.160018665876.issue22181@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Commit in the Linux kernel:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c6e9d6f38894798696f23c8084ca7edbf16ee895

--

Here is a patch to use the new getrandom() syscall of Linux 3.17 in the Python function os.urandom().

The function falls back to reading /dev/urandom if getrandom() is not supported (returns ENOSYS at runtime).

On my Linux 3.18, the EINTR path is never taken. But I was able to test it manually by setting flags to GRND_RANDOM (2) and injecting many signals using signal.setitimer(): see my http://bugs.python.org/issue23285#msg237100

----------
keywords: +patch
Added file: http://bugs.python.org/file38310/random.patch

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

From report at bugs.python.org  Tue Mar  3 03:31:35 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 02:31:35 +0000
Subject: [issue23567] os.stat() tuple access vs named attribute access int vs
 float
In-Reply-To: <1425345371.02.0.709789700046.issue23567@psf.upfronthosting.co.za>
Message-ID: <1425349895.37.0.442756579055.issue23567@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It's already documented:

https://docs.python.org/dev/library/os.html#os.stat_result

"For compatibility with older Python versions, accessing stat_result as a tuple always returns integers."

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

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

From report at bugs.python.org  Tue Mar  3 03:38:50 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 03 Mar 2015 02:38:50 +0000
Subject: [issue23567] os.stat() tuple access vs named attribute access int vs
 float
In-Reply-To: <1425345371.02.0.709789700046.issue23567@psf.upfronthosting.co.za>
Message-ID: <1425350330.51.0.565087597964.issue23567@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I missed that because i was looking for it to be called out under 2.7 os.stat() docs rather than under 2.7's os.stat_float_times() which is a method nobody is likely to read the documentation for as floats have been the default since 2.5.

The 2.7 docs are much less organized around this than the 3.x.

Adding that note in the same paragraph on 2.7's os.stat() docs would be sufficient.

"For backward compatibility, the return value of stat() is also accessible as a tuple of at least 10 integers" implies it, but doesn't explicitly call out the integer [ST_XXX] vs float .st_xxx difference as adding that sentence does.

----------
versions:  -Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar  3 03:40:29 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Mar 2015 02:40:29 +0000
Subject: [issue23564] Patch fixing sanity check for ordered fd sequence in
 _posixsubprocess.c
In-Reply-To: <1425315012.54.0.714244886784.issue23564@psf.upfronthosting.co.za>
Message-ID: <1425350429.58.0.218051096041.issue23564@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


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

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

From report at bugs.python.org  Tue Mar  3 03:47:27 2015
From: report at bugs.python.org (Carlo Beccarini)
Date: Tue, 03 Mar 2015 02:47:27 +0000
Subject: [issue23512] The list of built-in functions is not alphabetical on
 https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425350847.35.0.759430184529.issue23512@psf.upfronthosting.co.za>


Changes by Carlo Beccarini <hackdiablo.cb at gmail.com>:


Removed file: http://bugs.python.org/file38305/functions.rst

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

From report at bugs.python.org  Tue Mar  3 05:31:34 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 03 Mar 2015 04:31:34 +0000
Subject: [issue23560] Group the docs of similar methods in stdtypes.rst
In-Reply-To: <1425288490.4.0.288876913126.issue23560@psf.upfronthosting.co.za>
Message-ID: <1425357094.19.0.536928187517.issue23560@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

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

From report at bugs.python.org  Tue Mar  3 05:47:30 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 03 Mar 2015 04:47:30 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425358050.39.0.622229142204.issue21619@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for that link; the answer by Eryksun <https://stackoverflow.com/questions/23688492/oserror-errno-22-invalid-argument-in-subprocess#28020096> is particularly enlightening. Apparently EINVAL actually represents an underlying broken pipe condition in Windows. Anyway, as far as the test is concerned, it doesn?t matter what particular exception is raised.

This still doesn?t explain Serhiy?s observation that sometimes no exception is raised at all, <https://bugs.python.org/issue21619#msg236949>. Does Windows sometimes not report broken pipe errors, or is my signalling logic not working and there is a race condition? The whole point of the test is to trigger an exception when stdin is closed, so it would be nice to be able to reliably do that on Windows.

----------

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

From report at bugs.python.org  Tue Mar  3 06:10:21 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 03 Mar 2015 05:10:21 +0000
Subject: [issue23362] integer overflow in string translate
In-Reply-To: <1422798800.96.0.0931437199134.issue23362@psf.upfronthosting.co.za>
Message-ID: <1425359421.2.0.770350020334.issue23362@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
versions: +Python 3.3, Python 3.5

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

From report at bugs.python.org  Tue Mar  3 06:13:01 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 03 Mar 2015 05:13:01 +0000
Subject: [issue23367] integer overflow in unicodedata.normalize
In-Reply-To: <1422799035.27.0.978256662941.issue23367@psf.upfronthosting.co.za>
Message-ID: <1425359581.23.0.923394097053.issue23367@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
versions: +Python 2.7, Python 3.3, Python 3.5

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

From report at bugs.python.org  Tue Mar  3 06:16:51 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 03 Mar 2015 05:16:51 +0000
Subject: [issue23505] Urlparse insufficient validation leads to open redirect
In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za>
Message-ID: <1425359811.66.0.522847300609.issue23505@psf.upfronthosting.co.za>


Martin Panter added the comment:

Do you think it would be enough to ensure the urlparse() result remembers whether the empty ?//? was present or not? In other words, something like the following mockup (based on the Issue 22852 proposal). An example vunerable program would help me understand this as well.

>>> urlparse("////evil.com")
ParseResult(scheme="", netloc="", has_netloc=True, path="//evil.com", ...)
>>> urlunparse(_)
"////evil.com"

Or would we still need special handling of a path that starts with a double slash despite that; either URL-encoding the second slash, or maybe just raising an exception? Consider that the components are already supposed to be URL-encoded, and you can still generate unexpected valid URLs by giving other invalid components, such as

>>> urlunparse(("", "netloc/with/path", "/more/path", "", "", ""))
'//netloc/with/path/more/path'

----------

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

From report at bugs.python.org  Tue Mar  3 06:33:53 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 03 Mar 2015 05:33:53 +0000
Subject: [issue22801] collections.Counter, when empty,
 doesn't raise an error with &= when other is an incompatible type
In-Reply-To: <1415209471.77.0.966779934151.issue22801@psf.upfronthosting.co.za>
Message-ID: <1425360833.32.0.701859590619.issue22801@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I see no reason pure python code to have to detect and report such oddities.
Closing as not worth it.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Tue Mar  3 07:25:09 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 03 Mar 2015 06:25:09 +0000
Subject: [issue22555] Tracking issue for adjustments to binary/text boundary
 handling
In-Reply-To: <1412481703.35.0.528069461639.issue22555@psf.upfronthosting.co.za>
Message-ID: <1425363909.51.0.224797859831.issue22555@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

PEP 461 landed, restoring binary interpolation support: https://hg.python.org/cpython/rev/8d802fb6ae32

There are also some relevant around standardising the C.UTF-8 locale currently available on some Linux systems:

Fedora RFE: https://bugzilla.redhat.com/show_bug.cgi?id=902094
glibc RFE: https://sourceware.org/bugzilla/show_bug.cgi?id=17318
glibc-alpha discussion: https://sourceware.org/ml/libc-alpha/2015-02/msg00247.html

----------

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

From report at bugs.python.org  Tue Mar  3 08:12:21 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 07:12:21 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1425358050.39.0.622229142204.issue21619@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYjEWdh0X2gzjsqMaMg+=pBcKaSrwx1joNqo2TcBXRrng@mail.gmail.com>


STINNER Victor added the comment:

A few months ago, I modified Popen.communicate() to handle EINVAL on
Windows.

----------

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

From report at bugs.python.org  Tue Mar  3 08:34:45 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 03 Mar 2015 07:34:45 +0000
Subject: [issue23564] Patch fixing sanity check for ordered fd sequence in
 _posixsubprocess.c
In-Reply-To: <1425315012.54.0.714244886784.issue23564@psf.upfronthosting.co.za>
Message-ID: <1425368085.02.0.264448146912.issue23564@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

Haha, yes, that description and patch look correct.  Thanks!

Fortunately this bug is low impact as this was just a sanity check and the calling code from subprocess.py was already passing the correct data in.

An ideal regression test: An explicit unittest that calls the _posixsubprocess API with some bad sequences of values in fds_to_keep and uses assertRaises to check for the appropriate ValueError("bad value(s) in fds_to_keep") coming out of it...

----------
assignee:  -> gregory.p.smith
priority: normal -> low
stage:  -> patch review
type:  -> behavior

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

From report at bugs.python.org  Tue Mar  3 09:24:37 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 03 Mar 2015 08:24:37 +0000
Subject: [issue11097] MSI: Remove win32com dependency from installer generator
In-Reply-To: <1296634472.0.0.346787074034.issue11097@psf.upfronthosting.co.za>
Message-ID: <1425371077.07.0.722277306466.issue11097@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

This can now be closed as out of date.

----------
components: +Windows
nosy: +steve.dower, tim.golden, zach.ware

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

From report at bugs.python.org  Tue Mar  3 09:36:26 2015
From: report at bugs.python.org (Zygmunt Krynicki)
Date: Tue, 03 Mar 2015 08:36:26 +0000
Subject: [issue23568] unittest.mock.MagicMock doesn't support __rdivmod__t
Message-ID: <1425371785.99.0.969035398065.issue23568@psf.upfronthosting.co.za>


New submission from Zygmunt Krynicki:

Hey.

I'm the upstream developer of padme https://github.com/zyga/padme -- the mostly transparent proxy class for Python. While working on unit tests for proxying numeric methods I realized that there are a few bugs in the mock library.

The bug I'd like to report now is that __rdivmod__ cannot be mocked by MagicMock. This seems to be caused by the fact that it is listed as magic but not as numeric (for which right-hand-side variants are created).

Note that it cannot be simply added to numeric as it doesn't have the augmented assignment variant (there is no __idivmod__).

The bug is present in all versions of Python that come with unittest.mock (3.3, 3.4 and 3.5) and it is also present in the upstream/standalone version of mock

----------
components: Library (Lib)
messages: 237112
nosy: zkrynicki
priority: normal
severity: normal
status: open
title: unittest.mock.MagicMock doesn't support __rdivmod__t
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar  3 09:36:32 2015
From: report at bugs.python.org (Zygmunt Krynicki)
Date: Tue, 03 Mar 2015 08:36:32 +0000
Subject: [issue23568] unittest.mock.MagicMock doesn't support __rdivmod__
In-Reply-To: <1425371785.99.0.969035398065.issue23568@psf.upfronthosting.co.za>
Message-ID: <1425371792.03.0.59698121701.issue23568@psf.upfronthosting.co.za>


Changes by Zygmunt Krynicki <zygmunt.krynicki at canonical.com>:


----------
title: unittest.mock.MagicMock doesn't support __rdivmod__t -> unittest.mock.MagicMock doesn't support __rdivmod__

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

From report at bugs.python.org  Tue Mar  3 09:41:21 2015
From: report at bugs.python.org (Zygmunt Krynicki)
Date: Tue, 03 Mar 2015 08:41:21 +0000
Subject: [issue23569] unittest.mock.MagicMock.__div__ works but __truediv__
 doesn't (3.3 only)
Message-ID: <1425372081.7.0.586383148765.issue23569@psf.upfronthosting.co.za>


New submission from Zygmunt Krynicki:

Hey.

I'm the upstream developer of padme https://github.com/zyga/padme -- the mostly transparent proxy class for Python. While working on unit tests for proxying numeric methods I realized that there are a few bugs in the mock library.

The bug I'd like to report now is that __truemod__ cannot be mocked by MagicMock but __div__ can (despite __div__ being gone from Python 3 entirely). This bug is specific to Python 3.3 and it is fixed in 3.4 and 3.5a1

----------
messages: 237113
nosy: zkrynicki
priority: normal
severity: normal
status: open
title: unittest.mock.MagicMock.__div__ works  but  __truediv__ doesn't (3.3 only)
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Mar  3 09:42:49 2015
From: report at bugs.python.org (Zygmunt Krynicki)
Date: Tue, 03 Mar 2015 08:42:49 +0000
Subject: [issue23568] unittest.mock.MagicMock doesn't support __rdivmod__
In-Reply-To: <1425371785.99.0.969035398065.issue23568@psf.upfronthosting.co.za>
Message-ID: <1425372169.84.0.38974417263.issue23568@psf.upfronthosting.co.za>


Changes by Zygmunt Krynicki <zygmunt.krynicki at canonical.com>:


----------
type:  -> behavior
versions: +Python 3.3 -Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar  3 10:27:19 2015
From: report at bugs.python.org (Thomas Petazzoni)
Date: Tue, 03 Mar 2015 09:27:19 +0000
Subject: [issue20210] Provide configure options to enable/disable Python
 modules and extensions
In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za>
Message-ID: <1425374839.83.0.255306899964.issue20210@psf.upfronthosting.co.za>


Thomas Petazzoni added the comment:

@Mark I would be happy to, but if you refer to the previous discussion about this bug report, the feedback was quite negative. And since I'm not really willing to do some clean up to finally get the patches rejected, I'd like to at least have 1/ an agreement on the principle itself, and 2/ some guidance as to what needs to be changed in the currently proposed patches to get them accepted.

----------

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

From report at bugs.python.org  Tue Mar  3 10:49:16 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 09:49:16 +0000
Subject: [issue23570] Change "with subprocess.Popen():" (context manager) to
 ignore broken pipe error
Message-ID: <1425376156.84.0.317071254674.issue23570@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The Popen.communicate() method ignores broken pipe error when writing to stdin. I propose to modify Popen.__exit__() to do the same in Python 3.5.

Attached patch implements this suggestion and document it. I added this paragraph to Popen doc:

"The context manager ignores broken pipe errors when closing the process?s stdin: call explicitly proc.stdin.flush() and proc.stdin.close() to get broken pipe errors."

So it's still possible to get broken pipe errors if you need them.

Do you know applications or libraries which rely on broken pipe errors and do something different than just ignoring them?

I prefer to leave Python 3.4 unchanged to avoid subtle behaviour changes in minor Python releases.

See also:

- issue #21619 which modified Popen.__exit__() to call wait() even if stdin.close() raised an exception
- issue #19612 which modified communicate() to handle EINVAL on stdin.write() on Windows

----------
files: popen_exit.patch
keywords: patch
messages: 237115
nosy: haypo, serhiy.storchaka, vadmium
priority: normal
severity: normal
status: open
title: Change "with subprocess.Popen():" (context manager) to ignore broken pipe error
versions: Python 3.5
Added file: http://bugs.python.org/file38311/popen_exit.patch

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

From report at bugs.python.org  Tue Mar  3 10:53:50 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 09:53:50 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425376430.84.0.904661412858.issue21619@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I opened the issue #23570: Change "with subprocess.Popen():" (context manager) to ignore broken pipe error.

> FAIL: test_broken_pipe_cleanup (test.test_subprocess.ContextManagerTests)

Serhiy: see existing test_communicate_epipe() and test_communicate_epipe_only_stdin() tests which are now reliable and portable.

You should write more data (2**20 bytes) and set the buffer size to a value larger than the input data, to buffer all data, so the write occurs at stdin.close() in Popen.__exit__().

By the way, instead of an hardcoded value (2**20), support.PIPE_MAX_SIZE may be more appropriate.

----------

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

From report at bugs.python.org  Tue Mar  3 11:40:34 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 03 Mar 2015 10:40:34 +0000
Subject: [issue23570] Change "with subprocess.Popen():" (context manager) to
 ignore broken pipe error
In-Reply-To: <1425376156.84.0.317071254674.issue23570@psf.upfronthosting.co.za>
Message-ID: <1425379234.04.0.417073102779.issue23570@psf.upfronthosting.co.za>


Martin Panter added the comment:

I left some minor comments on the documentation.

As a side effect of your rearranging of _stdin_write(), I think it would fix the bug with communicate() leaking a BrokenPipeError and leaving a zombie when there is less than a buffer?s worth of data to send.

----------

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

From report at bugs.python.org  Tue Mar  3 11:45:45 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Tue, 03 Mar 2015 10:45:45 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425379545.18.0.83397595176.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

Ryan,
Sounds good. I think I've got all of the bug tracker patches committed/pushed...now I need to do all of the other edits.  Aiming to be finished by Friday/Saturday.

----------

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

From report at bugs.python.org  Tue Mar  3 12:08:57 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 03 Mar 2015 11:08:57 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425380937.08.0.858908411803.issue21619@psf.upfronthosting.co.za>


Martin Panter added the comment:

Aha! So perhaps Windows can accept a small amount of data into its pipe buffer even if we know the pipe has been broken. That kind of makes sense. Test case could be modified to:

proc = subprocess.Popen([...], bufsize=support.PIPE_MAX_SIZE, stdin=subprocess.PIPE, stdout=subprocess.PIPE)
proc.stdout.read()  # Make sure subprocess has closed its input
proc.stdin.write(bytes(support.PIPE_MAX_SIZE))
self.assertIsNone(proc.returncode)
# Expect EPIPE under POSIX and EINVAL under Windows
self.assertRaises(OSError, proc.__exit__, None, None, None)

----------

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

From report at bugs.python.org  Tue Mar  3 12:26:57 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Mar 2015 11:26:57 +0000
Subject: [issue23570] Change "with subprocess.Popen():" (context manager) to
 ignore broken pipe error
In-Reply-To: <1425376156.84.0.317071254674.issue23570@psf.upfronthosting.co.za>
Message-ID: <1425382017.17.0.99902920248.issue23570@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Do you want to modify IOBase.__exit__ to ignore I/O errors in close()? I think such changes should be discussed in Python-Dev.

----------

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

From report at bugs.python.org  Tue Mar  3 12:27:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Mar 2015 11:27:27 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425382047.27.0.804062911978.issue21619@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you provide a patch Martin?

----------

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

From report at bugs.python.org  Tue Mar  3 12:41:44 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 11:41:44 +0000
Subject: [issue23570] Change "with subprocess.Popen():" (context manager) to
 ignore broken pipe error
In-Reply-To: <1425376156.84.0.317071254674.issue23570@psf.upfronthosting.co.za>
Message-ID: <1425382904.46.0.335166118733.issue23570@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Do you want to modify IOBase.__exit__ to ignore I/O errors in close()?

Nope. On files, you want to want to know if your data has been fully written. For a subprocess, it's different. You only expect best effort.

The BrokenPipeError exception is raised by Python when an OS function fails with EPIPE. This exception has the same purpose than the SIGPIPE signal: warn the application that it's now useless to send more data, the consumer will ignore it. By the way, since Python checks the result of *all* OS functions, SIGPIPE is simply ignored. SIGPIPE and EPIPE have the same purpose.

In the subprocess module, if we get BrokenPipeError, it means that the child process stopped reading from stdin (closed it or the process already exited).

Popen.communicate() must close stdin, so why would we pass BrokenPipeError to the caller? It's useless, we just stop writing and close the pipe.

Since Popen.__exit__() also closes stdin, I use the same rationale: it useless to pass BrokenPipeError to the caller. The caller expects that the process exited.

Anyway, we closed all pipes, it's not more possible to communicate with the child process. The following example displays "is proc stdin closed? True":
---
import subprocess, sys

args = [sys.executable, '-c', 'pass']
proc = subprocess.Popen(args, stdin=subprocess.PIPE)
try:
    with proc:
        proc.stdin.write(b'x' * (2**20))
except BrokenPipeError:
    pass
print("is proc stdin closed?", proc.stdin.closed)
---

See also: "Why does SIGPIPE exist?"
https://stackoverflow.com/questions/8369506/why-does-sigpipe-exist

----------
nosy: +neologix

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

From report at bugs.python.org  Tue Mar  3 12:58:41 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 11:58:41 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
Message-ID: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch changes PyObject_Call() and PyCFunction_Call() to raise a SystemError and destroy the result (Py_DECREF) if a function returns a result with an exception set.

I also refactored PyCFunction_Call() and added "assert(!PyErr_Occurred());" at the beginning of PyCFunction_Call().

I removed duplicate checks in ceval.c.

--

I didn't check the impact on performances.

If the patch has a significant overhead: _Py_CheckFunctionResult() may be marked to be inlined, and PyCFunction_Call() and PyObject_Call() checks may be marked as unlikely using GCC __builtin_expect(), something like:

#ifdef __GNUC__
#  define Py_likely(x)       __builtin_expect((x),1)
#  define Py_unlikely(x)     __builtin_expect((x),0)
#else
#  define Py_likely(x)       x
#  define Py_unlikely(x)     x
#endif

Be careful of __builtin_expect(), misused it can make the code slower! (benchmark, benchmark, benchmark!)

----------
components: Interpreter Core
messages: 237123
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Raise SystemError if a function returns a result with an exception set
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar  3 12:59:04 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 11:59:04 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1425383944.55.0.274149588872.issue23571@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file38312/check_result.patch

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

From report at bugs.python.org  Tue Mar  3 13:01:23 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 12:01:23 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1425382047.27.0.804062911978.issue21619@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa1vE1FizHnn6qN7PcrFTDjh26qfJb6zt991ZCb800U+w@mail.gmail.com>


STINNER Victor added the comment:

I would be safer to use a bufsize a little bit larger :-)

proc = subprocess.Popen([...], bufsize=support.PIPE_MAX_SIZE * 2,
stdin=subprocess.PIPE, stdout=subprocess.PIPE)
...
proc.stdin.write(b'x' * support.PIPE_MAX_SIZE)

----------

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

From report at bugs.python.org  Tue Mar  3 13:08:43 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 12:08:43 +0000
Subject: [issue23570] Change "with subprocess.Popen():" (context manager) to
 ignore broken pipe error
In-Reply-To: <1425376156.84.0.317071254674.issue23570@psf.upfronthosting.co.za>
Message-ID: <1425384523.38.0.411095115311.issue23570@psf.upfronthosting.co.za>


STINNER Victor added the comment:

New patch to fix the bug seen by Serhiy.

> Anyway, we closed all pipes

Oh, I forgot to explain that TextIOWrapper.close() closes the buffered file even if flush() raised an exception. BufferedWriter.close() does the same.

So stdin.close() always closes the text (binary or text, buffered or not). It's not more possible to use stdin after stdin.close(), even if stdin.close() raised an exception.

----------
Added file: http://bugs.python.org/file38313/popen_exit-2.patch

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

From report at bugs.python.org  Tue Mar  3 13:17:09 2015
From: report at bugs.python.org (Sergio Pascual)
Date: Tue, 03 Mar 2015 12:17:09 +0000
Subject: [issue23572] functools.singledispatch fails when "not BaseClass" is
 True
Message-ID: <1425385029.2.0.304023107943.issue23572@psf.upfronthosting.co.za>


New submission from Sergio Pascual:

I admit this case is rather convoluted, but I have been debugging a few hours so I think I should share my findings.

I have a metaclass MetaA that provides to the classes constructed with it have a dictionary interface. Of all the functions only __len__ is important. In some cases, the result of __len__ is 0 and that is what triggers the error

class MetaA(type):
    def __len__(self):
        return 0

class A(metaclass=MetaA):
    pass

class AA(A):
    pass

Now, I construct a function with single dispatch and register the case of class A but not the class AA

@singledispatch
def fun(a):
    print('base case')

@fun.register(A)
def _(a):
    print('fun A')

And then, call fun with an object of class AA

fun(AA())

This should call the function for the class up in the hierarchy, A
Instead it raises an exception 

RuntimeError: Inconsistent hierarchy

in function functools._c3_merge
because in the line

if not candidate:
    raise RuntimeError("Inconsistent hierarchy")

"not candidate" evaluates to True due to __len__ returning 0


This can be avoided by:

* adding __nonzero__ to MetaA

* not adding the map interface to a class in the first place

* changing the code in _c3_merge 

I'm not really sure, but instead of:

if not candidate:
    raise RuntimeError("Inconsistent hierarchy")

would this work?

if candidate is None:
    raise RuntimeError("Inconsistent hierarchy")


I attach a test case

----------
components: Library (Lib)
files: singledispatch-test.py
messages: 237126
nosy: Sergio Pascual
priority: normal
severity: normal
status: open
title: functools.singledispatch fails when "not BaseClass" is True
versions: Python 3.4
Added file: http://bugs.python.org/file38314/singledispatch-test.py

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

From report at bugs.python.org  Tue Mar  3 13:36:22 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 03 Mar 2015 12:36:22 +0000
Subject: [issue17352] Be clear that __prepare__ must be declared as a class
 method
In-Reply-To: <1362409892.83.0.717786566871.issue17352@psf.upfronthosting.co.za>
Message-ID: <1425386182.27.0.841463956219.issue17352@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

__new__ is a little weird - it's actually special cased as a staticmethod.

Your questions is still valid, though.

For existing versions, documenting the requirement is the only option. 

For future versions, we could conceivably implement a "decorate it if it isn't already decorated" fallback, but for backwards compatibility we'd have to avoid double-decorating explicitly decorated implementations.

----------

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

From report at bugs.python.org  Tue Mar  3 13:49:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Mar 2015 12:49:17 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <2020551.UHYr1Dyx1P@raxxla>


Serhiy Storchaka added the comment:

> If the patch has a significant overhead: _Py_CheckFunctionResult() may be
> marked to be inlined, and PyCFunction_Call() and PyObject_Call() checks may
> be marked as unlikely using GCC __builtin_expect(), something like:

Could you please open separate issue or even a topic on Python-Ideas for 
Py_likely/Py_unlikely? I prefer spelling _Py_LIKELY.

----------

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

From report at bugs.python.org  Tue Mar  3 13:56:48 2015
From: report at bugs.python.org (Nikita Kovaliov)
Date: Tue, 03 Mar 2015 12:56:48 +0000
Subject: [issue13697] python RLock implementation unsafe with signals
In-Reply-To: <1325538793.4.0.376965160112.issue13697@psf.upfronthosting.co.za>
Message-ID: <1425387408.16.0.14615239817.issue13697@psf.upfronthosting.co.za>


Changes by Nikita Kovaliov <nikita at maizy.ru>:


----------
nosy: +maizy

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

From report at bugs.python.org  Tue Mar  3 13:58:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Mar 2015 12:58:31 +0000
Subject: [issue23570] Change "with subprocess.Popen():" (context manager) to
 ignore broken pipe error
In-Reply-To: <1425382904.46.0.335166118733.issue23570@psf.upfronthosting.co.za>
Message-ID: <1850341.7k6B5vMMDV@raxxla>


Serhiy Storchaka added the comment:

I don't see a difference between buffered file and Popen object. Both are useless 
after closing, both can raise an exception when flush a buffer on closing. Why 
suppress an exception in one case but not in other? I think this question 
needs wider discussion in Python-Dev.

----------

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

From report at bugs.python.org  Tue Mar  3 14:06:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Mar 2015 13:06:42 +0000
Subject: [issue23570] Change "with subprocess.Popen():" (context manager) to
 ignore broken pipe error
In-Reply-To: <1425376156.84.0.317071254674.issue23570@psf.upfronthosting.co.za>
Message-ID: <1425388002.84.0.986963139017.issue23570@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> New patch to fix the bug seen by Serhiy.

I thought about different solution:

    try:
        if input:
            self.stdin.write(input)
    finally:
        self.stdin.close()

But your approach looks working too,

----------

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

From report at bugs.python.org  Tue Mar  3 14:13:56 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 13:13:56 +0000
Subject: [issue23570] Change "with subprocess.Popen():" (context manager) to
 ignore broken pipe error
In-Reply-To: <1425376156.84.0.317071254674.issue23570@psf.upfronthosting.co.za>
Message-ID: <1425388436.52.0.68429347904.issue23570@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I thought about different solution:

Your solution is different: I would prefer to also ignore broken pipe errors on close(). I'm not sure that close() can raise a BrokenPipeError in practice.

----------

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

From report at bugs.python.org  Tue Mar  3 14:16:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 13:16:08 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <2020551.UHYr1Dyx1P@raxxla>
Message-ID: <CAMpsgwb6XZ7SqVeKhJ0PH-XPie-OXz7CiNNeABRD=1G7_QZvbA@mail.gmail.com>


STINNER Victor added the comment:

2015-03-03 13:49 GMT+01:00 Serhiy Storchaka <report at bugs.python.org>:
>> If the patch has a significant overhead: _Py_CheckFunctionResult() may be
>> marked to be inlined, and PyCFunction_Call() and PyObject_Call() checks may
>> be marked as unlikely using GCC __builtin_expect(), something like:
>
> Could you please open separate issue or even a topic on Python-Ideas for
> Py_likely/Py_unlikely? I prefer spelling _Py_LIKELY.

I'm not really interested by micro-benchmark here :-) I also propose
solutions *if* my patch makes the code slower.

Since __builtin_expect() may have a negative effect on performances, I
would prefer to avoid it if we can :-)

----------

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

From report at bugs.python.org  Tue Mar  3 14:17:49 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Mar 2015 13:17:49 +0000
Subject: [issue23570] Change "with subprocess.Popen():" (context manager) to
 ignore broken pipe error
In-Reply-To: <1425388436.52.0.68429347904.issue23570@psf.upfronthosting.co.za>
Message-ID: <8854935.NWfjJ1WFWH@raxxla>


Serhiy Storchaka added the comment:

> Your solution is different: I would prefer to also ignore broken pipe errors
> on close(). I'm not sure that close() can raise a BrokenPipeError in
> practice.

Of course all this code should be inside try/except block that ignores a 
BrokenPipeError.

----------

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

From report at bugs.python.org  Tue Mar  3 14:25:46 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 13:25:46 +0000
Subject: [issue13697] python RLock implementation unsafe with signals
In-Reply-To: <1325538793.4.0.376965160112.issue13697@psf.upfronthosting.co.za>
Message-ID: <1425389146.08.0.652423699016.issue13697@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The attached test script demonstrates the issue on Python 2.6 and 3.2, and code inspection suggests this is still valid for 2.7 and 3.4.

I disagree that Python 3.4 is affected: RLock has been reimplemented in C in Python 3.2. Only the Python implementation of RLock has the bug, but it's not used by fault, you have to explicitly use a private attribute of the threading module to get it.

Python 2.6 only accept security fixes, so in fact only Python 2.7 may get a fix.

The question is if it worth to backport 300 lines of C code from Python 3 to Python 2 in the _thread module.

@Benjamin, release manager of Pythn 2.7: What do you think? I may help to backport the C implementation of RLock.

----------
nosy: +benjamin.peterson
versions:  -Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Mar  3 14:30:55 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Mar 2015 13:30:55 +0000
Subject: [issue13697] python RLock implementation unsafe with signals
In-Reply-To: <1325538793.4.0.376965160112.issue13697@psf.upfronthosting.co.za>
Message-ID: <1425389455.7.0.393833498584.issue13697@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This bug has existed for ages. People who want sane behaviour should just switch to Python 3. Closing.

----------
resolution:  -> rejected
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Mar  3 14:35:18 2015
From: report at bugs.python.org (Jan Kratochvil)
Date: Tue, 03 Mar 2015 13:35:18 +0000
Subject: [issue10112] Use -Wl, --dynamic-list=x.list,
 not -Xlinker -export-dynamic
In-Reply-To: <1287137785.61.0.962664170792.issue10112@psf.upfronthosting.co.za>
Message-ID: <1425389718.49.0.420999357102.issue10112@psf.upfronthosting.co.za>


Jan Kratochvil added the comment:

It even crashes applications due to pollution of dynamic symbols namespace by application symbols as seen in:
  https://bugzilla.redhat.com/show_bug.cgi?id=1198158

----------

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

From report at bugs.python.org  Tue Mar  3 14:39:17 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 03 Mar 2015 13:39:17 +0000
Subject: [issue23512] The list of built-in functions is not alphabetical on
 https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425389957.03.0.831623421373.issue23512@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> ezio.melotti

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

From report at bugs.python.org  Tue Mar  3 14:53:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Mar 2015 13:53:30 +0000
Subject: [issue23573] Avoid redundant allocations in str.find and like
Message-ID: <1425390810.95.0.0960267231917.issue23573@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently str.find() and similar methods can make a copy of self or searched string if they have different kinds. In some cases this is redundant because the result can be known before trying to search. Longer string can't be found in shorter string and wider string can't be found in narrower string. Proposed patch avoid creating temporary widened copies in such corner cases. It also adds special cases for searching 1-character strings.

Some sample microbenchmark results:

$ ./python -m timeit -s "a = 'x'; b = 'x\U00012345'" -- "b.find(a)"
Unpatched: 1000000 loops, best of 3: 1.92 usec per loop
Patched:   1000000 loops, best of 3: 1.03 usec per loop

$ ./python -m timeit -s "a = 'x'; b = 'x\U00012345'" -- "a in b"
Unpatched: 1000000 loops, best of 3: 0.543 usec per loop
Patched:   1000000 loops, best of 3: 0.25 usec per loop

$ ./python -m timeit -s "a = '\U00012345'; b = 'x'*1000" -- "b.find(a)"
Unpatched: 100000 loops, best of 3: 4.58 usec per loop
Patched:   1000000 loops, best of 3: 0.969 usec per loop

$ ./python -m timeit -s "a = 'x'*1000; b = '\U00012345'" -- "b.find(a)"
Unpatched: 100000 loops, best of 3: 3.77 usec per loop
Patched:   1000000 loops, best of 3: 0.97 usec per loop

$ ./python -m timeit -s "a = 'x'*1000; b = '\U00012345'" -- "a in b"
Unpatched: 100000 loops, best of 3: 2.4 usec per loop
Patched:   1000000 loops, best of 3: 0.225 usec per loop

----------
components: Interpreter Core
files: str_find_faster.patch
keywords: patch
messages: 237137
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Avoid redundant allocations in str.find and like
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file38315/str_find_faster.patch

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

From report at bugs.python.org  Tue Mar  3 14:56:04 2015
From: report at bugs.python.org (Carlo Beccarini)
Date: Tue, 03 Mar 2015 13:56:04 +0000
Subject: [issue23512] The list of built-in functions is not alphabetical on
 https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425390964.09.0.614447688613.issue23512@psf.upfronthosting.co.za>


Changes by Carlo Beccarini <hackdiablo.cb at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file38316/issue23512.diff

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

From report at bugs.python.org  Tue Mar  3 15:18:53 2015
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 03 Mar 2015 14:18:53 +0000
Subject: [issue13697] python RLock implementation unsafe with signals
In-Reply-To: <1325538793.4.0.376965160112.issue13697@psf.upfronthosting.co.za>
Message-ID: <1425392333.33.0.838512331939.issue13697@psf.upfronthosting.co.za>


Roumen Petrov added the comment:

hmm issue still exist in master branch. 
Lets wait python 4 for sane behaviour.

----------
nosy: +rpetrov

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

From report at bugs.python.org  Tue Mar  3 15:21:51 2015
From: report at bugs.python.org (Alexey Boriskin)
Date: Tue, 03 Mar 2015 14:21:51 +0000
Subject: [issue15795] Zipfile.extractall does not preserve file permissions
In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za>
Message-ID: <1425392511.68.0.944796546735.issue15795@psf.upfronthosting.co.za>


Alexey Boriskin added the comment:

I'm working on updating the patch to unify tarfile and zipfile interfaces and to restore owner/timestamp for zipfile

----------

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

From report at bugs.python.org  Tue Mar  3 15:28:22 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 14:28:22 +0000
Subject: [issue13697] python RLock implementation unsafe with signals
In-Reply-To: <1325538793.4.0.376965160112.issue13697@psf.upfronthosting.co.za>
Message-ID: <1425392902.64.0.576284809956.issue13697@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> hmm issue still exist in master branch. 

For the third time, only the Python implementation has the bug, and it's not used by default. So the bug was fixed in Python 3 since 3.2. It's time to upgrade guys ;-)

----------

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

From report at bugs.python.org  Tue Mar  3 15:31:21 2015
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 03 Mar 2015 14:31:21 +0000
Subject: [issue13697] python RLock implementation unsafe with signals
In-Reply-To: <1425392902.64.0.576284809956.issue13697@psf.upfronthosting.co.za>
Message-ID: <54F5C5B7.1080603@roumenpetrov.info>


Roumen Petrov added the comment:

STINNER Victor wrote:
> For the third time, only the Python implementation has the bug, and 
> it's not used by default. So the bug was fixed in Python 3 since 3.2. 
> It's time to upgrade guys ;-)
Did you mean to downgrade? Tested with Python 3.5.0a1+ (default, Feb 28 
2015, 09:49:09)

----------

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

From report at bugs.python.org  Tue Mar  3 15:42:23 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 14:42:23 +0000
Subject: [issue23574] datetime: support leap seconds
Message-ID: <1425393743.39.0.519990063132.issue23574@psf.upfronthosting.co.za>


New submission from STINNER Victor:

A leap second will be added in June 2015:
http://www.usatoday.com/story/tech/2015/01/08/computer-chaos-feares/21433363/

The datetime module explicitly doesn't support leap seconds:
https://docs.python.org/dev/library/datetime.html#datetime.date.fromtimestamp
"Note that on non-POSIX systems that include leap seconds in their notion of a timestamp, leap seconds are ignored by fromtimestamp()."

The following bug in oslo.utils was reported because datetime is indirectly used to unserialize a date, but it fails with ValueError("second must be in 0..59") if the second is 60:
https://bugs.launchpad.net/oslo.utils/+bug/1427212

Would it be possible to silently drop ignore leap seconds in datetime.datetime constructor, as already done in datetime.datetime.fromtimestamp?

Attached patch modified datetime constructor to drop leap seconds: replace second=60 with second=59. I also changed the error message for second (valid range is now 0..60).

----------
components: Library (Lib)
messages: 237142
nosy: belopolsky, haypo
priority: normal
severity: normal
status: open
title: datetime: support leap seconds
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar  3 15:43:29 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 14:43:29 +0000
Subject: [issue23574] datetime: support leap seconds
In-Reply-To: <1425393743.39.0.519990063132.issue23574@psf.upfronthosting.co.za>
Message-ID: <1425393809.16.0.68429941405.issue23574@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file38317/datetime_leapsecond.patch

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

From report at bugs.python.org  Tue Mar  3 15:51:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 14:51:08 +0000
Subject: [issue13697] python RLock implementation unsafe with signals
In-Reply-To: <1325538793.4.0.376965160112.issue13697@psf.upfronthosting.co.za>
Message-ID: <1425394268.45.0.256375593734.issue13697@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Did you mean to downgrade? Tested with Python 3.5.0a1+ (default, Feb 28 
2015, 09:49:09)

Please make some effort to try to understand the issue.

I attach hang2.py which doesn't force the Python implementation of RLock. You might try hang2.py on Python 2 and Python 3 if you are not convinced yet that Python 3 has not the bug...

----------
Added file: http://bugs.python.org/file38318/hang2.py

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

From report at bugs.python.org  Tue Mar  3 15:52:00 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 14:52:00 +0000
Subject: [issue23574] datetime: support leap seconds
In-Reply-To: <1425393743.39.0.519990063132.issue23574@psf.upfronthosting.co.za>
Message-ID: <1425394320.59.0.238705013185.issue23574@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Leap seconds are ignored, so a difference of <datetime before the leap second> and <datetime with the leap second> is zero:

>>> import datetime
>>> t1=datetime.datetime(2012, 6, 30, 23, 59, 59)
>>> t2=datetime.datetime(2012, 6, 30, 23, 59, 59)
>>> t2-t1
datetime.timedelta(0)

Supporting leap seconds might be possible, but it requires much more work.

----------

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

From report at bugs.python.org  Tue Mar  3 16:02:18 2015
From: report at bugs.python.org (Doug Hellmann)
Date: Tue, 03 Mar 2015 15:02:18 +0000
Subject: [issue23574] datetime: support leap seconds
In-Reply-To: <1425393743.39.0.519990063132.issue23574@psf.upfronthosting.co.za>
Message-ID: <1425394938.93.0.874515205247.issue23574@psf.upfronthosting.co.za>


Changes by Doug Hellmann <doug.hellmann at gmail.com>:


----------
nosy: +doughellmann

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

From report at bugs.python.org  Tue Mar  3 16:33:06 2015
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 03 Mar 2015 15:33:06 +0000
Subject: [issue13697] python RLock implementation unsafe with signals
In-Reply-To: <1425394268.45.0.256375593734.issue13697@psf.upfronthosting.co.za>
Message-ID: <54F5D430.4070905@roumenpetrov.info>


Roumen Petrov added the comment:

STINNER Victor wrote:
> [SNIP]I attach hang2.py which doesn't force the Python implementation 
> of RLock.[SNIP]
Ok. Fine with me.

----------

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

From report at bugs.python.org  Tue Mar  3 16:37:21 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 15:37:21 +0000
Subject: [issue23574] datetime: support leap seconds
In-Reply-To: <1425393743.39.0.519990063132.issue23574@psf.upfronthosting.co.za>
Message-ID: <1425397041.08.0.0773357166123.issue23574@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ignoring leap seconds introduces unexpected result.

datetime.timestamp -> datetime.fromtimestamp drops one second:

$ ./python
Python 3.5.0a1+ (default:760f222103c7+, Mar  3 2015, 15:36:36) 
>>> t=datetime.datetime(2012, 6, 30, 23, 59, 60).timestamp()
>>> datetime.datetime.fromtimestamp(t)
datetime.datetime(2012, 6, 30, 23, 59, 59)

time and datetime modules behave differently:

$ ./python
Python 3.5.0a1+ (default:760f222103c7+, Mar  3 2015, 15:36:36) 
>>> import datetime, time
>>> t1=datetime.datetime(2012, 6, 30, 23, 59, 59).timestamp()
>>> t2=datetime.datetime(2012, 6, 30, 23, 59, 60).timestamp()
>>> t2-t1
0.0

>>> t3=time.mktime((2012, 6, 30, 23, 59, 59, -1, -1, -1))
>>> t4=time.mktime((2012, 6, 30, 23, 59, 60, -1, -1, -1))
>>> t4-t3
1.0

>>> t1 == t2 == t3
True
>>> t3, t4
(1341093599.0, 1341093600.0)

----------

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

From report at bugs.python.org  Tue Mar  3 16:38:32 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 03 Mar 2015 15:38:32 +0000
Subject: [issue11097] MSI: Remove win32com dependency from installer generator
In-Reply-To: <1296634472.0.0.346787074034.issue11097@psf.upfronthosting.co.za>
Message-ID: <1425397112.56.0.130962779321.issue11097@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at microsoft.com>:


----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Tue Mar  3 16:45:19 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 15:45:19 +0000
Subject: [issue23574] datetime: support leap seconds
In-Reply-To: <1425393743.39.0.519990063132.issue23574@psf.upfronthosting.co.za>
Message-ID: <1425397519.12.0.495744554121.issue23574@psf.upfronthosting.co.za>


STINNER Victor added the comment:

support_leap_seconds.patch: different approach, accept second=60. Problem: fromtimestamp() returns the wrong day.

haypo at smithers$ ./python
Python 3.5.0a1+ (default:760f222103c7+, Mar  3 2015, 15:36:36) 
>>> import datetime
>>> datetime.datetime(2012, 6, 30, 23, 59, 60)
datetime.datetime(2012, 6, 30, 23, 59, 60)
>>> dt1=datetime.datetime(2012, 6, 30, 23, 59, 60)
>>> t1=datetime.datetime(2012, 6, 30, 23, 59, 60).timestamp()
>>> dt2=datetime.datetime.fromtimestamp(t1)
>>> dt2
datetime.datetime(2012, 7, 1, 0, 0)
>>> dt2 == dt1
False
>>> dt1
datetime.datetime(2012, 6, 30, 23, 59, 60)
>>> print(dt1)
2012-06-30 23:59:60
>>> print(dt2)
2012-07-01 00:00:00

>>> import time
>>> time.mktime((2012, 6, 30, 23, 59, 60, -1, -1, -1))
1341093600.0
>>> t1
1341093600.0
>>> t2=time.mktime((2012, 6, 30, 23, 59, 60, -1, -1, -1))
>>> t2 == t1
True
>>> time.localtime(time.mktime((2012, 6, 30, 23, 59, 60, -1, -1, -1)))
time.struct_time(tm_year=2012, tm_mon=7, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=183, tm_isdst=1)


http://cr.yp.to/proto/utctai.html

"""
For many years, the UNIX localtime() time-display routine didn't support leap seconds.
(...)
Why not fix it?
(...)
The main obstacle is POSIX. POSIX is a ``standard'' designed by a vendor consortium several years ago to eliminate progress and protect the installed base. The behavior of the broken localtime() libraries was documented and turned into a POSIX requirement.
"""

----------
Added file: http://bugs.python.org/file38319/support_leap_seconds.patch

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

From report at bugs.python.org  Tue Mar  3 16:48:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Mar 2015 15:48:15 +0000
Subject: [issue23574] datetime: support leap seconds
In-Reply-To: <1425393743.39.0.519990063132.issue23574@psf.upfronthosting.co.za>
Message-ID: <1425397695.27.0.405286684078.issue23574@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, mktime() returns the same timestamp with and without the leap second:

>>> time.mktime((2012, 6, 30, 23, 59, 59, -1, -1, -1))
1341093599.0
>>> time.mktime((2012, 6, 30, 23, 59, 60, -1, -1, -1))
1341093600.0
>>> time.mktime((2012, 7, 1, 0, 0, 0, -1, -1, -1))
1341093600.0

----------

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

From report at bugs.python.org  Tue Mar  3 17:08:33 2015
From: report at bugs.python.org (Yassine ABOUKIR)
Date: Tue, 03 Mar 2015 16:08:33 +0000
Subject: [issue23505] Urlparse insufficient validation leads to open redirect
In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za>
Message-ID: <1425398913.65.0.486662913711.issue23505@psf.upfronthosting.co.za>


Yassine ABOUKIR added the comment:

I am not quiet sure about the first proposal but I strongly believe the appropriate method to fix this is by checking if the path starts with double slashes and then URL encoding the two leading slashes.

----------

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

From report at bugs.python.org  Tue Mar  3 17:27:17 2015
From: report at bugs.python.org (Simon Hoinkis)
Date: Tue, 03 Mar 2015 16:27:17 +0000
Subject: [issue23575] MIPS64 needs ffi's n32.S
Message-ID: <1425400037.86.0.872792301422.issue23575@psf.upfronthosting.co.za>


New submission from Simon Hoinkis:

MIPS64 needs ffi's n32.S linking in for _ctypes to work otherwise build errors will occur (e.g. python-setuptools).

----------
components: ctypes
files: mips64.patch
keywords: patch
messages: 237150
nosy: Simon Hoinkis
priority: normal
severity: normal
status: open
title: MIPS64 needs ffi's n32.S
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file38320/mips64.patch

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

From report at bugs.python.org  Tue Mar  3 17:56:13 2015
From: report at bugs.python.org (Cory Benfield)
Date: Tue, 03 Mar 2015 16:56:13 +0000
Subject: [issue23576] HTTPS reads can block when content length not available
 and timeout set.
Message-ID: <1425401773.41.0.539386605796.issue23576@psf.upfronthosting.co.za>


New submission from Cory Benfield:

Initially reported on the requests bug list at https://github.com/kennethreitz/requests/issues/2467

In cases when a remote web server sends a non-chunked response that does not have a content length, it is possible to get http.client to hang on a read. To hit it requires a specific set of circumstances:

- Python 3 (this bug is not seen on Python 2 in my testing)
- HTTPS (using plaintext HTTP resolves the problem)
- A socket timeout must be set (leaving it unset, i.e. leaving the socket in blocking mode, resolves this problem)
- The server must not send a content-length or set Transfer-Coding: chunked.
- The reads must not be an even divisor of the content's length.
- The timeout must be longer than the time the server is willing to keep the connection open (otherwise an exception is thrown).

The following code can be used as a sample to demonstrate the bug:

import http.client
import time

def test(connection_class=http.client.HTTPSConnection, timeout=10, read_size=7):
    start = time.time()
    c = connection_class('sleepy-reaches-6892.herokuapp.com')
    c.connect()
    if timeout is not None:
        c.sock.settimeout(timeout)
    c.request('GET', '/test')
    r = c.getresponse()
    while True:
        data = r.read(read_size)
        if not data:
            break
    print('Finished in {}'.format(time.time() - start))


Below are the results from several different runs:

test(): Finished in 4.8294830322265625
test(connection_class=http.client.HTTPConnection): Finished in 0.3060309886932373
test(timeout=None): Finished in 0.6070599555969238
test(read_size=2): Finished in 0.6600658893585205

As you can see, only this particular set of features causes the bug. Note that if you change the URL to one that does return a Content-Length (e.g. http2bin.org/get), this bug also goes away.

This is a really weird edge case bug. There's some extensive investigation over at the requests bug report, but I've not been able to convincingly point at the problem yet.

----------
components: Library (Lib)
messages: 237151
nosy: Lukasa
priority: normal
severity: normal
status: open
title: HTTPS reads can block when content length not available and timeout set.
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar  3 17:58:55 2015
From: report at bugs.python.org (Alex Shkop)
Date: Tue, 03 Mar 2015 16:58:55 +0000
Subject: [issue23577] Add tests for wsgiref.validate
Message-ID: <1425401935.54.0.320750128573.issue23577@psf.upfronthosting.co.za>


New submission from Alex Shkop:

These tests increase coverage of wsgiref.validate module. They test InputWrapper and ErrorWrapper used to validate env['wsgi.input'] and env['wsgi.errors'].

----------
components: Tests
files: wsgiref_test_wrappers.patch
keywords: patch
messages: 237152
nosy: ashkop
priority: normal
severity: normal
status: open
title: Add tests for wsgiref.validate
versions: Python 3.5
Added file: http://bugs.python.org/file38321/wsgiref_test_wrappers.patch

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

From report at bugs.python.org  Tue Mar  3 18:03:05 2015
From: report at bugs.python.org (Alistair Lynn)
Date: Tue, 03 Mar 2015 17:03:05 +0000
Subject: [issue23578] struct.pack error messages do not indicate which
 argument was invalid
Message-ID: <1425402185.63.0.203193056814.issue23578@psf.upfronthosting.co.za>


New submission from Alistair Lynn:

In this example:

  struct.pack('!hhhh', 0x5FFF, 0x6FFF, 0x7FFF, 0x8FFF)

Python errors that the 'h' format requires -32768 <= number <= 32767, but it does not indicate which of the arguments is at fault. In this contrived example it's clearly the fourth one, but in dealing with large amounts of data it would be useful to indicate which argument was invalid.

This would hopefully not be a functional change, just a slightly more helpful error message.

----------
components: Library (Lib)
messages: 237153
nosy: alynn
priority: normal
severity: normal
status: open
title: struct.pack error messages do not indicate which argument was invalid
type: enhancement
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Tue Mar  3 18:15:30 2015
From: report at bugs.python.org (Isaac Schwabacher)
Date: Tue, 03 Mar 2015 17:15:30 +0000
Subject: [issue19884] Importing readline produces erroneous output
In-Reply-To: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za>
Message-ID: <1425402930.41.0.302955028202.issue19884@psf.upfronthosting.co.za>


Isaac Schwabacher added the comment:

>From the OP:

> This was reported at [1] and originally at [2]. The readline maintainer suggests [3] using:
> 
>     rl_variable_bind ("enable-meta-key", "off");
> 
> which was introduced in readline 6.1. Do you think it'd be safe to add the above line?

>From 3.4.3 final:

>     @unittest.skipIf(readline._READLINE_VERSION < 0x0600
>                      and "libedit" not in readline.__doc__,
>                      "not supported in this library version")


The test currently fails on readline version 6.0.  The version to test on needs a bump to 0x0610.

----------
nosy: +ischwabacher

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

From report at bugs.python.org  Tue Mar  3 18:25:30 2015
From: report at bugs.python.org (Isaac Schwabacher)
Date: Tue, 03 Mar 2015 17:25:30 +0000
Subject: [issue19884] Importing readline produces erroneous output
In-Reply-To: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za>
Message-ID: <1425403530.16.0.474111067566.issue19884@psf.upfronthosting.co.za>


Isaac Schwabacher added the comment:

Whoops, that's 0x0601.  Though Maxime gives evidence that the version should in fact be 0x0603.  (Note that while OS X ships with libedit over libreadline, anyone who wants to can install the real thing instead of that pale imitation; the test would have been skipped if Maxime were using libedit.)

----------

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

From report at bugs.python.org  Tue Mar  3 19:17:09 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 03 Mar 2015 18:17:09 +0000
Subject: [issue23576] HTTPS reads can block when content length not available
 and timeout set.
In-Reply-To: <1425401773.41.0.539386605796.issue23576@psf.upfronthosting.co.za>
Message-ID: <1425406629.51.0.816998181021.issue23576@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +demian.brecht

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

From report at bugs.python.org  Tue Mar  3 19:22:33 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Mar 2015 18:22:33 +0000
Subject: [issue23563] Faster urllib.urlparse utility functions
In-Reply-To: <1425308703.33.0.595640490502.issue23563@psf.upfronthosting.co.za>
Message-ID: <20150303182228.26042.46754@psf.io>


Roundup Robot added the comment:

New changeset 461afc24fabc by Serhiy Storchaka in branch 'default':
Issue #23563: Optimized utility functions in urllib.parse.
https://hg.python.org/cpython/rev/461afc24fabc

----------
nosy: +python-dev

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

From report at bugs.python.org  Tue Mar  3 19:29:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Mar 2015 18:29:17 +0000
Subject: [issue23563] Faster urllib.urlparse utility functions
In-Reply-To: <1425308703.33.0.595640490502.issue23563@psf.upfronthosting.co.za>
Message-ID: <1425407357.24.0.656452416066.issue23563@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Mar  3 19:40:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Mar 2015 18:40:15 +0000
Subject: [issue20271] urllib.parse.urlparse() accepts wrong URLs
In-Reply-To: <1389789129.93.0.775761654638.issue20271@psf.upfronthosting.co.za>
Message-ID: <1425408015.77.0.329642112315.issue20271@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

With optimizations in issue23563 and weaken IPv6 check the implementation of urlsplit() can be faster.

$ ./python -m timeit -s "from urllib.parse import urlparse, clear_cache" -- "urlparse('http://python.org:80'); clear_cache()"
10000 loops, best of 3: 86.3 usec per loop
$ ./python -m timeit -s "from urllib.parse import urlparse, clear_cache" -- "urlparse('http://[2001:4802:7901:0:e60a:1375:0:5]:80'); clear_cache()"
10000 loops, best of 3: 88.6 usec per loop

----------
Added file: http://bugs.python.org/file38322/urlparse_2.patch

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

From report at bugs.python.org  Tue Mar  3 19:49:51 2015
From: report at bugs.python.org (Zachary Salzbank)
Date: Tue, 03 Mar 2015 18:49:51 +0000
Subject: [issue23576] HTTPS reads can block when content length not available
 and timeout set.
In-Reply-To: <1425401773.41.0.539386605796.issue23576@psf.upfronthosting.co.za>
Message-ID: <1425408591.62.0.504243896168.issue23576@psf.upfronthosting.co.za>


Changes by Zachary Salzbank <zach at key.me>:


----------
nosy: +Zachary Salzbank

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

From report at bugs.python.org  Tue Mar  3 20:45:10 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 Mar 2015 19:45:10 +0000
Subject: [issue23367] integer overflow in unicodedata.normalize
In-Reply-To: <1422799035.27.0.978256662941.issue23367@psf.upfronthosting.co.za>
Message-ID: <1425411910.83.0.898006577563.issue23367@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The test doesn't hurt.

----------

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

From report at bugs.python.org  Tue Mar  3 21:26:10 2015
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 03 Mar 2015 20:26:10 +0000
Subject: [issue23285] PEP 475 - EINTR handling
In-Reply-To: <1425347355.3.0.570071996512.issue23285@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2XnWffmdetW9+7QNP367xAw49UGxVjyxUS3mRR9hzdnA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

@Victor: please commit.
Would be nice to have a test for it;

----------

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

From report at bugs.python.org  Tue Mar  3 22:03:18 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Mar 2015 21:03:18 +0000
Subject: [issue23575] MIPS64 needs ffi's n32.S
In-Reply-To: <1425400037.86.0.872792301422.issue23575@psf.upfronthosting.co.za>
Message-ID: <1425416598.33.0.135853486516.issue23575@psf.upfronthosting.co.za>


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


----------
nosy: +amaury.forgeotdarc, belopolsky, doko, meador.inge
stage:  -> patch review
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar  3 22:43:51 2015
From: report at bugs.python.org (Edrie Ddrie)
Date: Tue, 03 Mar 2015 21:43:51 +0000
Subject: [issue23579] Amazon.com links
Message-ID: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>


New submission from Edrie Ddrie:

Keywords:easy
Priority: normal

----------
assignee: docs at python
components: Documentation
messages: 237160
nosy: Edrie Ddrie, docs at python
priority: normal
severity: normal
status: open
title: Amazon.com links
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar  3 22:44:50 2015
From: report at bugs.python.org (Edrie Ddrie)
Date: Tue, 03 Mar 2015 21:44:50 +0000
Subject: [issue23580] Amazon.com links
Message-ID: <1425419090.93.0.681413466025.issue23580@psf.upfronthosting.co.za>


New submission from Edrie Ddrie:

Keywords: easy
Priority: normal

----------
assignee: docs at python
components: Documentation
messages: 237161
nosy: Edrie Ddrie, docs at python
priority: normal
severity: normal
status: open
title: Amazon.com links
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar  3 22:45:33 2015
From: report at bugs.python.org (Edrie Ddrie)
Date: Tue, 03 Mar 2015 21:45:33 +0000
Subject: [issue23579] Amazon.com links
In-Reply-To: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>
Message-ID: <1425419133.84.0.82383418505.issue23579@psf.upfronthosting.co.za>


Edrie Ddrie added the comment:

There a links to Amazon in the official documentation.
(In Python 3.4 in the tkinter.html and othergui.html)

It's not right to advertise for a certain business.
When will the official documentation guide people to eat at MacDonalds ?
I is a sign of a low moral.

A more honest alternative is just to call the book title and author
and let people decide where they buy books.

----------

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

From report at bugs.python.org  Tue Mar  3 22:50:52 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Mar 2015 21:50:52 +0000
Subject: [issue23579] Amazon.com links
In-Reply-To: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>
Message-ID: <1425419452.39.0.415819925872.issue23579@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

If the mentioned books have official Web sites we could use a link to them.
Feel free to submit a patch.

----------
nosy: +pitrou
versions: +Python 2.7, Python 3.5

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

From report at bugs.python.org  Tue Mar  3 22:51:30 2015
From: report at bugs.python.org (Paul McMillan)
Date: Tue, 03 Mar 2015 21:51:30 +0000
Subject: [issue23505] Urlparse insufficient validation leads to open redirect
In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za>
Message-ID: <1425419490.33.0.687499208034.issue23505@psf.upfronthosting.co.za>


Paul McMillan added the comment:

While some websites may use urlunparse(urlparse(url)) to validate a url, this is far from standard practice. Django, for instance, does not use this method. While I agree we should clean this behavior up, this is not a vulnerability in core python, and we need to invalidate the assigned CVE.

----------
nosy: +PaulMcMillan

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

From report at bugs.python.org  Tue Mar  3 22:54:27 2015
From: report at bugs.python.org (Piotr Dobrogost)
Date: Tue, 03 Mar 2015 21:54:27 +0000
Subject: [issue23576] HTTPS reads can block when content length not available
 and timeout set.
In-Reply-To: <1425401773.41.0.539386605796.issue23576@psf.upfronthosting.co.za>
Message-ID: <1425419667.75.0.76711985345.issue23576@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at bugs.python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

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

From report at bugs.python.org  Tue Mar  3 23:08:15 2015
From: report at bugs.python.org (Hammerite)
Date: Tue, 03 Mar 2015 22:08:15 +0000
Subject: [issue23550] Add to unicodedata a function to query the "Quick_Check"
 property for a character
In-Reply-To: <1425147670.05.0.762030398058.issue23550@psf.upfronthosting.co.za>
Message-ID: <1425420495.11.0.8693258256.issue23550@psf.upfronthosting.co.za>


Hammerite added the comment:

Here is a better patch that includes the changes to unicodedata.h

The problem before was that the diff tool can't cope with line ending differences. I just fixed the line endings manually.

----------
Added file: http://bugs.python.org/file38323/quick_check_2.patch

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

From report at bugs.python.org  Tue Mar  3 23:24:15 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 03 Mar 2015 22:24:15 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1425421455.89.0.740883594131.issue17911@psf.upfronthosting.co.za>


Robert Collins added the comment:

Ok, all changes applied, lets see how this looks to folk.

----------
Added file: http://bugs.python.org/file38324/issue17911-5.patch

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

From report at bugs.python.org  Tue Mar  3 23:31:08 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 03 Mar 2015 22:31:08 +0000
Subject: [issue23579] Amazon.com links
In-Reply-To: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>
Message-ID: <1425421868.88.0.682429007418.issue23579@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

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

From report at bugs.python.org  Tue Mar  3 23:32:00 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 03 Mar 2015 22:32:00 +0000
Subject: [issue23580] Amazon.com links
In-Reply-To: <1425419090.93.0.681413466025.issue23580@psf.upfronthosting.co.za>
Message-ID: <1425421920.21.0.80069980491.issue23580@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman
resolution:  -> duplicate
status: open -> closed
superseder:  -> Amazon.com links

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

From report at bugs.python.org  Tue Mar  3 23:42:18 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Mar 2015 22:42:18 +0000
Subject: [issue23568] unittest.mock.MagicMock doesn't support __rdivmod__
In-Reply-To: <1425371785.99.0.969035398065.issue23568@psf.upfronthosting.co.za>
Message-ID: <1425422538.77.0.00806538358466.issue23568@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +michael.foord, rbcollins

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

From report at bugs.python.org  Tue Mar  3 23:43:01 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Mar 2015 22:43:01 +0000
Subject: [issue23310] MagicMock constructor configuration fails for magic
 methods
In-Reply-To: <1422120039.57.0.541541438715.issue23310@psf.upfronthosting.co.za>
Message-ID: <1425422581.43.0.355626476386.issue23310@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +michael.foord, rbcollins

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

From report at bugs.python.org  Tue Mar  3 23:48:45 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Mar 2015 22:48:45 +0000
Subject: [issue23569] unittest.mock.MagicMock.__div__ works but __truediv__
 doesn't (3.3 only)
In-Reply-To: <1425372081.7.0.586383148765.issue23569@psf.upfronthosting.co.za>
Message-ID: <1425422925.95.0.34864543609.issue23569@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report, however, per our support policy, Python 3.3 is now open only for security fixes for the remainder of its support window.

----------
nosy: +ned.deily
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Mar  3 23:56:40 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 03 Mar 2015 22:56:40 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1425423400.16.0.0982646183126.issue17911@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


Added file: http://bugs.python.org/file38325/issue17911-6.patch

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

From report at bugs.python.org  Wed Mar  4 00:04:35 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 03 Mar 2015 23:04:35 +0000
Subject: [issue23578] struct.pack error messages do not indicate which
 argument was invalid
In-Reply-To: <1425402185.63.0.203193056814.issue23578@psf.upfronthosting.co.za>
Message-ID: <1425423875.39.0.586770136452.issue23578@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +mark.dickinson, meador.inge

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

From report at bugs.python.org  Wed Mar  4 00:53:45 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Mar 2015 23:53:45 +0000
Subject: [issue23576] HTTPS reads can block when content length not available
 and timeout set.
In-Reply-To: <1425401773.41.0.539386605796.issue23576@psf.upfronthosting.co.za>
Message-ID: <1425426825.53.0.494117022916.issue23576@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Reproducing seems a bit irregular. Note that the last bytestring (the empty bytestring) is what takes time to read.

Also note that HTTPResponse is a buffered I/O object, so normally you don't need to read up to the empty string. You can stop when you got less bytes than what you asked for.

----------
nosy: +pitrou
versions: +Python 3.5

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

From report at bugs.python.org  Wed Mar  4 01:13:21 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Mar 2015 00:13:21 +0000
Subject: [issue23576] HTTPS reads can block when content length not available
 and timeout set.
In-Reply-To: <1425401773.41.0.539386605796.issue23576@psf.upfronthosting.co.za>
Message-ID: <1425428001.28.0.989102049697.issue23576@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Varying reproduceability may have to do with sleepy-reaches-6892.herokuapp.com resolving to different endpoints (that domain name has a stupidly small TTL, by the way).

Anyway, for an unknown reason the following patch seems to fix the issue.

----------
keywords: +patch
Added file: http://bugs.python.org/file38326/ssl_read_fixup.patch

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

From report at bugs.python.org  Wed Mar  4 03:04:41 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 04 Mar 2015 02:04:41 +0000
Subject: [issue15795] Zipfile.extractall does not preserve file permissions
In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za>
Message-ID: <1425434681.27.0.118536770575.issue15795@psf.upfronthosting.co.za>


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


----------
stage: commit review -> needs patch

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

From report at bugs.python.org  Wed Mar  4 03:38:09 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 04 Mar 2015 02:38:09 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <1425436689.54.0.40202162922.issue23539@psf.upfronthosting.co.za>


R. David Murray added the comment:

Single patch, yes, but FYI we actually prefer a python3 patch against default as the single patch.  (Unless there are major differences, which there aren't in this case.)

I've made some minor review comments.  You can either ack my changes (or disagree :) and I'll make them when I commit, or update the patch yourself if you are so moved.

----------

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

From report at bugs.python.org  Wed Mar  4 03:40:42 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 Mar 2015 02:40:42 +0000
Subject: [issue23504] Add __all__ into types
In-Reply-To: <1424729645.56.0.912988413489.issue23504@psf.upfronthosting.co.za>
Message-ID: <1425436842.04.0.684368152186.issue23504@psf.upfronthosting.co.za>


Berker Peksag added the comment:

LGTM.

----------
nosy: +berker.peksag
stage: patch review -> commit review

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

From report at bugs.python.org  Wed Mar  4 03:41:43 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 Mar 2015 02:41:43 +0000
Subject: [issue22933] Misleading sentence in doc for shutil.move
In-Reply-To: <1416849036.72.0.766895523282.issue22933@psf.upfronthosting.co.za>
Message-ID: <1425436903.92.0.956349743622.issue22933@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

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

From report at bugs.python.org  Wed Mar  4 03:57:01 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 Mar 2015 02:57:01 +0000
Subject: [issue23568] unittest.mock.MagicMock doesn't support __rdivmod__
In-Reply-To: <1425371785.99.0.969035398065.issue23568@psf.upfronthosting.co.za>
Message-ID: <1425437821.49.0.879154616577.issue23568@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

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

From report at bugs.python.org  Wed Mar  4 03:58:42 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 Mar 2015 02:58:42 +0000
Subject: [issue23572] functools.singledispatch fails when "not BaseClass" is
 True
In-Reply-To: <1425385029.2.0.304023107943.issue23572@psf.upfronthosting.co.za>
Message-ID: <1425437922.06.0.346329147825.issue23572@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +lukasz.langa

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

From report at bugs.python.org  Wed Mar  4 04:03:34 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 Mar 2015 03:03:34 +0000
Subject: [issue23577] Add tests for wsgiref.validate
In-Reply-To: <1425401935.54.0.320750128573.issue23577@psf.upfronthosting.co.za>
Message-ID: <1425438214.81.0.406688527552.issue23577@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag, pje
stage:  -> patch review
type:  -> enhancement
versions: +Python 3.4

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

From report at bugs.python.org  Wed Mar  4 05:30:41 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 Mar 2015 04:30:41 +0000
Subject: [issue20059] Inconsistent urlparse/urllib.parse handling of invalid
 port values?
In-Reply-To: <1387842710.57.0.78188368243.issue20059@psf.upfronthosting.co.za>
Message-ID: <1425443441.31.0.996010243529.issue20059@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> I think it is worth to be applied to maintained releases.

I'd commit this only to the default branch. Changing the return value from None to an exception after three 3.4 bugfix releases(3.4.1, 3.4.2 and 3.4.3 -- also since 3.4.3 was released in Feb 2015, 3.4.4 will probably be the last bugfix release of 3.4) would not be the best action. I understand that the current situation is inconsistent, but I'm not sure it's worth it to commit to the 2.7 and 3.4 branches.

----------

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

From report at bugs.python.org  Wed Mar  4 06:35:17 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 Mar 2015 05:35:17 +0000
Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if
 sem_open is not implemented
In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za>
Message-ID: <1425447317.05.0.437678630407.issue23400@psf.upfronthosting.co.za>


Berker Peksag added the comment:

LGTM

----------
stage: patch review -> commit review

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

From report at bugs.python.org  Wed Mar  4 08:45:22 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Mar 2015 07:45:22 +0000
Subject: [issue23504] Add __all__ into types
In-Reply-To: <1424729645.56.0.912988413489.issue23504@psf.upfronthosting.co.za>
Message-ID: <20150304074508.1787.5588@psf.io>


Roundup Robot added the comment:

New changeset cb5fe8cc60eb by Serhiy Storchaka in branch '2.7':
Issue #23504: Added an __all__ to the types module.
https://hg.python.org/cpython/rev/cb5fe8cc60eb

New changeset 4888f9498db6 by Serhiy Storchaka in branch '3.4':
Issue #23504: Added an __all__ to the types module.
https://hg.python.org/cpython/rev/4888f9498db6

New changeset 5c73b01d58ac by Serhiy Storchaka in branch 'default':
Issue #23504: Added an __all__ to the types module.
https://hg.python.org/cpython/rev/5c73b01d58ac

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Mar  4 08:47:57 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Mar 2015 07:47:57 +0000
Subject: [issue23504] Add __all__ into types
In-Reply-To: <1424729645.56.0.912988413489.issue23504@psf.upfronthosting.co.za>
Message-ID: <1425455277.53.0.707870145733.issue23504@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Mar  4 09:01:37 2015
From: report at bugs.python.org (Christoph Sieghart)
Date: Wed, 04 Mar 2015 08:01:37 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>
Message-ID: <1425456097.86.0.83690671481.issue23566@psf.upfronthosting.co.za>


Changes by Christoph Sieghart <sigi at 0x2a.at>:


----------
nosy: +sigi

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

From report at bugs.python.org  Wed Mar  4 10:27:01 2015
From: report at bugs.python.org (Zygmunt Krynicki)
Date: Wed, 04 Mar 2015 09:27:01 +0000
Subject: [issue23581] unittest.mock.MagicMock doesn't support matmul (@)
 operator
Message-ID: <1425461221.82.0.715365961896.issue23581@psf.upfronthosting.co.za>


New submission from Zygmunt Krynicki:

Hi. I'm the upstream of Padme, a mostly transparent proxy library for Python. I was adding support for the new matmul/@ operator when I noticed that MagicMock doens't support it yet.

>>> form unittest.mock import MagicMock
>>> MagicMock() @ 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for @: 'MagicMock' and 'int'

To add support simply add 'matmul' to unittest.mock.numerics.

----------
components: Library (Lib)
messages: 237176
nosy: zkrynicki
priority: normal
severity: normal
status: open
title: unittest.mock.MagicMock doesn't support matmul (@) operator
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Mar  4 10:29:12 2015
From: report at bugs.python.org (James Rutherford)
Date: Wed, 04 Mar 2015 09:29:12 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <1425461352.57.0.147078050781.issue23539@psf.upfronthosting.co.za>


James Rutherford added the comment:

Single patch against default makes sense and I'll do that in future.

As for the review comments, I'm happy to go with all of your suggestions but have offered a tweak to the docstring that you can take or leave at your discretion :)

----------

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

From report at bugs.python.org  Wed Mar  4 11:15:48 2015
From: report at bugs.python.org (=?utf-8?q?Roberto_Mart=C3=ADnez?=)
Date: Wed, 04 Mar 2015 10:15:48 +0000
Subject: [issue23582] multiprocessing.Queue.get is not getting all the items
 in the queue
Message-ID: <1425464148.59.0.542661724106.issue23582@psf.upfronthosting.co.za>


New submission from Roberto Mart?nez:

We face yesterday a bug in a project, and after a few hours of investigation we found a bad/not documented behavior in multiprocessing.Queue.

If you put one or more items in a queue and if the items are large, there is a delay between the put is executed and the item is finally available in the queue. This is reasonable because the underlying thread and the pipe, but the problem is not this.

The problem is that Queue.qsize() is reporting the number of items put, Queue.empty() is returning True, and Queue.get() is raising Empty.

So, the only safe method to get all the items is as follows:

while q.qsize():                                                         
    try:                                                                 
        item = q.get_nowait()                                                   
    except Empty:                                                        
        pass

Which is not very nice.

I attach a sample file reproducing the behavior, a single process put 100 elements in a Queue and after that it tries to get all of them, I tested in python 2.7.9 and 3.4 with the same result (seems python3 is a little bit faster and you need to enlarge the items). Also if you wait between get's, the process is able to retrieve all the items.

----------
files: mpqueuegetwrong.py
messages: 237178
nosy: Roberto Mart?nez
priority: normal
severity: normal
status: open
title: multiprocessing.Queue.get is not getting all the items in the queue
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file38327/mpqueuegetwrong.py

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

From report at bugs.python.org  Wed Mar  4 11:30:49 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Mar 2015 10:30:49 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425465049.95.0.44800355174.issue21619@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


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

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

From report at bugs.python.org  Wed Mar  4 11:32:13 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Mar 2015 10:32:13 +0000
Subject: [issue22351] NNTP constructor exception leaves socket for garbage
 collector
In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za>
Message-ID: <1425465133.6.0.718398119074.issue22351@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage: patch review -> test needed

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

From report at bugs.python.org  Wed Mar  4 11:33:00 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 Mar 2015 10:33:00 +0000
Subject: [issue23581] unittest.mock.MagicMock doesn't support matmul (@)
 operator
In-Reply-To: <1425461221.82.0.715365961896.issue23581@psf.upfronthosting.co.za>
Message-ID: <1425465180.82.0.117201293436.issue23581@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

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

From report at bugs.python.org  Wed Mar  4 11:38:23 2015
From: report at bugs.python.org (Alexei Romanov)
Date: Wed, 04 Mar 2015 10:38:23 +0000
Subject: [issue23582] multiprocessing.Queue.get is not getting all the items
 in the queue
In-Reply-To: <1425464148.59.0.542661724106.issue23582@psf.upfronthosting.co.za>
Message-ID: <1425465503.67.0.95241056309.issue23582@psf.upfronthosting.co.za>


Changes by Alexei Romanov <drednout.by at gmail.com>:


----------
nosy: +alexei.romanov

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

From report at bugs.python.org  Wed Mar  4 11:57:21 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 Mar 2015 10:57:21 +0000
Subject: [issue23582] multiprocessing.Queue.get is not getting all the items
 in the queue
In-Reply-To: <1425464148.59.0.542661724106.issue23582@psf.upfronthosting.co.za>
Message-ID: <1425466641.72.0.0109857122083.issue23582@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +davin, sbt

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

From report at bugs.python.org  Wed Mar  4 15:35:07 2015
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 04 Mar 2015 14:35:07 +0000
Subject: [issue23549] heapq docs should be more precise about how to access
 the smallest element
In-Reply-To: <1425141461.42.0.47354110207.issue23549@psf.upfronthosting.co.za>
Message-ID: <1425479707.54.0.0650257266424.issue23549@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Raymond - gentle ping.

Do you see a reason not to check this in?

----------

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

From report at bugs.python.org  Wed Mar  4 15:54:38 2015
From: report at bugs.python.org (Martijn Pieters)
Date: Wed, 04 Mar 2015 14:54:38 +0000
Subject: [issue19481] IDLE hangs while printing instance of Unicode subclass
In-Reply-To: <1383452956.07.0.644121763839.issue19481@psf.upfronthosting.co.za>
Message-ID: <1425480878.75.0.491044285485.issue19481@psf.upfronthosting.co.za>


Martijn Pieters added the comment:

This changes causes printing BeautifulSoup NavigableString objects to fail; the code actually could never work as `unicode.__getslice__` insists on getting passed in integers, not None.

To reproduce, create a new file in IDLE and paste in:

from bs4 import BeautifulSoup
html_doc = """<title>The Dormouse's story</title>""" 
soup = BeautifulSoup(html_doc)
print soup.title.string

Then pick *Run Module* to see:

Traceback (most recent call last):
  File "/private/tmp/test.py", line 4, in <module>
    print soup.title.string
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/PyShell.py", line 1353, in write
    s = unicode.__getslice__(s, None, None)
TypeError: an integer is required

The same error can be induced with:

    unicode.__getslice__(u'', None, None)

while specifying a start and end index (0 and len(s)) should fix this.

----------
nosy: +mjpieters

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

From report at bugs.python.org  Wed Mar  4 15:59:48 2015
From: report at bugs.python.org (Martijn Pieters)
Date: Wed, 04 Mar 2015 14:59:48 +0000
Subject: [issue23583] IDLE: printing unicode subclasses broken (again)
Message-ID: <1425481188.05.0.778183770327.issue23583@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

This is a regression or recurrence of issue #19481. 

To reproduce, create a subclass of unicode and try and print an instance of that class:

class Foo(unicode): pass

print Foo()

results in a traceback:

Traceback (most recent call last):
  File "<pyshell#4>", line 1, in <module>
    print Foo()
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/idlelib/PyShell.py", line 1353, in write
    s = unicode.__getslice__(s, None, None)
TypeError: an integer is required

because unicode.__getslice__ does not accept None for the start and end indices.

----------
messages: 237181
nosy: mjpieters
priority: normal
severity: normal
status: open
title: IDLE: printing unicode subclasses broken (again)
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar  4 15:59:58 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 04 Mar 2015 14:59:58 +0000
Subject: [issue19481] IDLE hangs while printing instance of Unicode subclass
In-Reply-To: <1383452956.07.0.644121763839.issue19481@psf.upfronthosting.co.za>
Message-ID: <1425481198.95.0.855313939856.issue19481@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Mar  4 16:00:12 2015
From: report at bugs.python.org (Martijn Pieters)
Date: Wed, 04 Mar 2015 15:00:12 +0000
Subject: [issue19481] IDLE hangs while printing instance of Unicode subclass
In-Reply-To: <1383452956.07.0.644121763839.issue19481@psf.upfronthosting.co.za>
Message-ID: <1425481212.53.0.558776922736.issue19481@psf.upfronthosting.co.za>


Martijn Pieters added the comment:

Created a new issue: http://bugs.python.org/issue23583

----------

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

From report at bugs.python.org  Wed Mar  4 16:00:49 2015
From: report at bugs.python.org (Martijn Pieters)
Date: Wed, 04 Mar 2015 15:00:49 +0000
Subject: [issue23583] IDLE: printing unicode subclasses broken (again)
In-Reply-To: <1425481188.05.0.778183770327.issue23583@psf.upfronthosting.co.za>
Message-ID: <1425481249.6.0.181086371877.issue23583@psf.upfronthosting.co.za>


Changes by Martijn Pieters <mj at python.org>:


----------
components: +IDLE

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

From report at bugs.python.org  Wed Mar  4 16:01:25 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 04 Mar 2015 15:01:25 +0000
Subject: [issue23583] IDLE: printing unicode subclasses broken (again)
In-Reply-To: <1425481188.05.0.778183770327.issue23583@psf.upfronthosting.co.za>
Message-ID: <1425481285.62.0.876266206305.issue23583@psf.upfronthosting.co.za>


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


----------
components: +Unicode
nosy: +ezio.melotti, haypo, ned.deily, serhiy.storchaka, terry.reedy
type:  -> behavior

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

From report at bugs.python.org  Wed Mar  4 16:10:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Mar 2015 15:10:30 +0000
Subject: [issue23500] Argument Clinic: multiple macro definition
In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za>
Message-ID: <1425481830.7.0.183621477535.issue23500@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which moves all methoddef_ifndef to the end of the buffer or file, so they are not conflicts with other definitions.

----------
keywords: +needs review, patch
stage:  -> patch review
Added file: http://bugs.python.org/file38328/clinic_append.patch

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

From report at bugs.python.org  Wed Mar  4 16:12:11 2015
From: report at bugs.python.org (Martijn Pieters)
Date: Wed, 04 Mar 2015 15:12:11 +0000
Subject: [issue23583] IDLE: printing unicode subclasses broken (again)
In-Reply-To: <1425481188.05.0.778183770327.issue23583@psf.upfronthosting.co.za>
Message-ID: <1425481931.47.0.928459740803.issue23583@psf.upfronthosting.co.za>


Martijn Pieters added the comment:

Proposed fix, replace line 1352-1353 in PseudoOutputFile.write():

if isinstance(s, unicode):
    s = unicode.__getslice__(s, None, None)

with

if isinstance(s, unicode):
    s = unicode.__getslice__(s, 0, len(s))

----------

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

From report at bugs.python.org  Wed Mar  4 16:12:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Mar 2015 15:12:42 +0000
Subject: [issue23500] Argument Clinic: multiple macro definition
In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za>
Message-ID: <1425481962.55.0.443037433219.issue23500@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a sample file generated by fixed clinic.py.

----------
Added file: http://bugs.python.org/file38329/sample.c

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

From report at bugs.python.org  Wed Mar  4 16:29:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Mar 2015 15:29:04 +0000
Subject: [issue23583] IDLE: printing unicode subclasses broken (again)
In-Reply-To: <1425481188.05.0.778183770327.issue23583@psf.upfronthosting.co.za>
Message-ID: <1425482944.6.0.872418849634.issue23583@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I can propose two ways to fix this:

    s = unicode.__getslice__(s, 0, unicode.__len__(s))

and

    s = unicode.__getitem__(s, slice(None))

----------

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

From report at bugs.python.org  Wed Mar  4 16:31:24 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Mar 2015 15:31:24 +0000
Subject: [issue23583] IDLE: printing unicode subclasses broken (again)
In-Reply-To: <1425481188.05.0.778183770327.issue23583@psf.upfronthosting.co.za>
Message-ID: <1425483084.35.0.285316541338.issue23583@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Just len() doesn't work when the subclass overrides __len__.

----------

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

From report at bugs.python.org  Wed Mar  4 17:04:33 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 04 Mar 2015 16:04:33 +0000
Subject: [issue23582] multiprocessing.Queue.get is not getting all the items
 in the queue
In-Reply-To: <1425464148.59.0.542661724106.issue23582@psf.upfronthosting.co.za>
Message-ID: <1425485073.44.0.0209949517391.issue23582@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is the documented behavior.  "qsize: Return the approximate size of the queue. Note, qsize() > 0 doesn't guarantee that a subsequent get() will not block, nor will qsize() < maxsize guarantee that put() will not block."

It looks like what you want here is get with a timeout, not get_nowait.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Mar  4 17:38:32 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Mar 2015 16:38:32 +0000
Subject: [issue22181] os.urandom() should use Linux 3.17 getrandom() syscall
In-Reply-To: <1407713563.4.0.264701036097.issue22181@psf.upfronthosting.co.za>
Message-ID: <1425487112.49.0.248718212369.issue22181@psf.upfronthosting.co.za>


STINNER Victor added the comment:

random-2.patch: updated patch (I don't understand why random.patch doesn't apply cleanly).

----------
Added file: http://bugs.python.org/file38330/random-2.patch

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

From report at bugs.python.org  Wed Mar  4 17:40:31 2015
From: report at bugs.python.org (John Beck)
Date: Wed, 04 Mar 2015 16:40:31 +0000
Subject: [issue23584] test_doctest lineendings fails in verbose mode
Message-ID: <1425487231.91.0.280595585638.issue23584@psf.upfronthosting.co.za>


New submission from John Beck:

Issue 8473 fixed a problem with lineendings in test_doctest, but it
appears not to work in verbose mode.  Adding verbose=False to the
doctest.testfile() invocations in test_lineendings() fixes this.
Attaching a patch to fix this for both 2.7 and 3.4.

----------
components: Tests
files: new.patch
keywords: patch
messages: 237191
nosy: jbeck
priority: normal
severity: normal
status: open
title: test_doctest lineendings fails in verbose mode
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file38331/new.patch

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

From report at bugs.python.org  Wed Mar  4 17:59:43 2015
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 04 Mar 2015 16:59:43 +0000
Subject: [issue23500] Argument Clinic: multiple macro definition
In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za>
Message-ID: <1425488383.73.0.959855491811.issue23500@psf.upfronthosting.co.za>


Larry Hastings added the comment:

In your sample output we still get two #ifndef SPAM_METHODDEF stanzas.  Wouldn't it be better to only have one?

Maybe Clinic needs to be smarter about generating those anyway.  Let me think about it.

----------

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

From report at bugs.python.org  Wed Mar  4 18:43:18 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 Mar 2015 17:43:18 +0000
Subject: [issue23285] PEP 475 - EINTR handling
In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za>
Message-ID: <1425490998.13.0.129005099373.issue23285@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Would be nice to have a test for it;

There are already some tests on EINTR in test_file_eintr and test_subprocess (test_communicate_eintr()).

----------

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

From report at bugs.python.org  Wed Mar  4 18:47:03 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Mar 2015 17:47:03 +0000
Subject: [issue23285] PEP 475 - EINTR handling
In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za>
Message-ID: <20150304174554.19095.4581@psf.io>


Roundup Robot added the comment:

New changeset cad6eac598ec by Victor Stinner in branch 'default':
Issue #23285: Fix handling of EINTR in fileio.c
https://hg.python.org/cpython/rev/cad6eac598ec

----------

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

From report at bugs.python.org  Wed Mar  4 19:41:29 2015
From: report at bugs.python.org (Yassine ABOUKIR)
Date: Wed, 04 Mar 2015 18:41:29 +0000
Subject: [issue23505] Urlparse insufficient validation leads to open redirect
In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za>
Message-ID: <1425494489.7.0.699781300971.issue23505@psf.upfronthosting.co.za>


Yassine ABOUKIR added the comment:

"Following the syntax specifications in RFC 1808, urlparse recognizes a netloc 

only if it is properly introduced by ?//?. Otherwise the input is presumed to be 

a relative URL and thus to start with a path component." 

https://docs.python.org/2/library/urlparse.html

2015-03-03 22:16 GMT+00:00 Paul McMillan <>:

    Yeah. I agree the lack of round trip is surprising, and I agree we
    should fix it.

    I think the underlying issue here is that urlparse has a pretty
    different view of the world when compared with the browsers. I know
    that bit me when I first started using python, and it periodically
    surfaces in cases like this, where the browser thinks that
    "//evil.com" is a url, but we've parsed it as part of a path.
    Backwards compatibility makes it hard to update urlparse to precisely
    match browser behavior, but there's probably room for a new library
    designed with browser compatibility as a primary feature.

    -Paul

    On Tue, Mar 3, 2015 at 10:07 PM, Antoine Pitrou <> wrote:
    >
    > Hi Paul,
    >
    > Le 03/03/2015 23:01, Paul McMillan a ?crit :
    >> I understand how this works. You don't need to paste the example again.
    >>
    >> The documentation makes no guarantee that parse/unparse will do what
    >> you want them to do, and does explicitly lay out the specific rules
    >> used for separating the parts.
    >
    > Well, I don't know if it's a security issue, but failure to roundtrip
    > *is* surprising (and IMHO dangerous for that reason) behaviour to say
    > the least.
    >
    > Moreover, the urlunparse() documentation (in 3.x) says:
    > """
    > Construct a URL from a tuple as returned by urlparse(). [...] This may
    > result in a slightly different, but equivalent URL, if the URL that was
    > parsed originally had unnecessary delimiters
    > """
    > 

(https://docs.python.org/3/library/urllib.parse.html#urllib.parse.urlunparse)
    >
    > which implies that any divergence when roundtripping should only consist
    > in cosmetic, not essential, differences ("equivalent URL").
    >
    > Regards
    >
    > Antoine.
    > -----------------------------
    > Python Security Response Team
    > Unsubscribe: https://mail.python.org/mailman/options/psrt/paul

%40mcmillan.ws

----------

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

From report at bugs.python.org  Wed Mar  4 20:04:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Mar 2015 19:04:23 +0000
Subject: [issue23500] Argument Clinic: multiple macro definition
In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za>
Message-ID: <1425495863.68.0.658740076492.issue23500@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Actually in this sample output no one #ifndef SPAM_METHODDEF stanza is needed, because SPAM_METHODDEF is defined in any case.

----------

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

From report at bugs.python.org  Wed Mar  4 20:07:18 2015
From: report at bugs.python.org (Carlo Beccarini)
Date: Wed, 04 Mar 2015 19:07:18 +0000
Subject: [issue23512] The list of built-in functions is not alphabetical on
 https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425496038.85.0.872246613217.issue23512@psf.upfronthosting.co.za>


Changes by Carlo Beccarini <hackdiablo.cb at gmail.com>:


Removed file: http://bugs.python.org/file38307/functions.rst

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

From report at bugs.python.org  Wed Mar  4 20:23:54 2015
From: report at bugs.python.org (Matt Mackall)
Date: Wed, 04 Mar 2015 19:23:54 +0000
Subject: [issue21672] Python for Windows 2.7.7: Path Configuration File No
 Longer Works With UNC Paths
In-Reply-To: <1401994479.3.0.49246899079.issue21672@psf.upfronthosting.co.za>
Message-ID: <1425497034.4.0.0494568899875.issue21672@psf.upfronthosting.co.za>


Matt Mackall added the comment:

Changeset 26ec62 regressed Mercurial.

http://bz.selenic.com/show_bug.cgi?id=4557

Before:

>>> ntpath.join(r'\\foo\bar\baz', '')
'\\\\foo\\bar\\baz\\'
>>> ntpath.join(r'\\foo\bar', '')
'\\\\foo\\bar\\'

After:

>>> ntpath.join(r'\\foo\bar\baz', '')
'\\\\foo\\bar\\baz\\'
>>> ntpath.join(r'\\foo\bar', '')
'\\\\foo\\bar'

----------
nosy: +Matt.Mackall

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

From report at bugs.python.org  Wed Mar  4 20:32:15 2015
From: report at bugs.python.org (Martijn Pieters)
Date: Wed, 04 Mar 2015 19:32:15 +0000
Subject: [issue23583] IDLE: printing unicode subclasses broken (again)
In-Reply-To: <1425481188.05.0.778183770327.issue23583@psf.upfronthosting.co.za>
Message-ID: <1425497535.81.0.403722158441.issue23583@psf.upfronthosting.co.za>


Martijn Pieters added the comment:

I like the unicode.__getitem__(s, slice(None)) approach, it has the advantage of not having to rely on len(s).

----------

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

From report at bugs.python.org  Wed Mar  4 20:47:49 2015
From: report at bugs.python.org (=?utf-8?q?Roberto_Mart=C3=ADnez?=)
Date: Wed, 04 Mar 2015 19:47:49 +0000
Subject: [issue23582] multiprocessing.Queue.get is not getting all the items
 in the queue
In-Reply-To: <1425464148.59.0.542661724106.issue23582@psf.upfronthosting.co.za>
Message-ID: <1425498469.63.0.157870503326.issue23582@psf.upfronthosting.co.za>


Roberto Mart?nez added the comment:

I think you misunderstood my explanation. My english is not very good, sorry.

I think that my previously attached file (mpqueuegetwrong.py) shows it better than my words. In this file you can see that I am not calling qsize nor get_nowait, only put and get. And the behavior I am reporting is only related to those methods (and I think it is not documented).

----------

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

From report at bugs.python.org  Wed Mar  4 21:00:18 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 Mar 2015 20:00:18 +0000
Subject: [issue23576] HTTPS reads can block when content length not available
 and timeout set.
In-Reply-To: <1425401773.41.0.539386605796.issue23576@psf.upfronthosting.co.za>
Message-ID: <1425499218.34.0.735312292513.issue23576@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This is now fixed in all branches. Thanks for the report!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 2.7

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

From report at bugs.python.org  Wed Mar  4 21:02:49 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Mar 2015 20:02:49 +0000
Subject: [issue23576] HTTPS reads can block when content length not available
 and timeout set.
In-Reply-To: <1425401773.41.0.539386605796.issue23576@psf.upfronthosting.co.za>
Message-ID: <20150304195809.1771.93538@psf.io>


Roundup Robot added the comment:

New changeset 371cf371a6a1 by Antoine Pitrou in branch '2.7':
Issue #23576: Avoid stalling in SSL reads when EOF has been reached in the SSL layer but the underlying connection hasn't been closed.
https://hg.python.org/cpython/rev/371cf371a6a1

----------
nosy: +python-dev

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

From report at bugs.python.org  Wed Mar  4 21:12:27 2015
From: report at bugs.python.org (Piotr Dobrogost)
Date: Wed, 04 Mar 2015 20:12:27 +0000
Subject: [issue22003] BytesIO copy-on-write
In-Reply-To: <1405635937.15.0.406925083031.issue22003@psf.upfronthosting.co.za>
Message-ID: <1425499947.6.0.485381847711.issue22003@psf.upfronthosting.co.za>


Piotr Dobrogost added the comment:

> This new patch abandons the buffer interface and specializes for Bytes per the comments on this issue.

Why does it abandon buffer interface? Because of the following?

> Thanks for digging here. As much as I'd love to follow this interpretation, it simply doesn't match existing buffer implementations, including within the standard library.

Shouldn't existing buffer implementations be fixed then and this feature made to use buffer interface instead of specialize for Bytes? If so is there at least any information on this in the comments so that one wouldn't wonder why there is specialization instead of relaying on buffer interface?

----------
nosy: +piotr.dobrogost

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

From report at bugs.python.org  Wed Mar  4 21:19:03 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Mar 2015 20:19:03 +0000
Subject: [issue23576] HTTPS reads can block when content length not available
 and timeout set.
In-Reply-To: <1425401773.41.0.539386605796.issue23576@psf.upfronthosting.co.za>
Message-ID: <20150304195628.1777.54348@psf.io>


Roundup Robot added the comment:

New changeset 01cf9ce75eda by Antoine Pitrou in branch '3.4':
Issue #23576: Avoid stalling in SSL reads when EOF has been reached in the SSL layer but the underlying connection hasn't been closed.
https://hg.python.org/cpython/rev/01cf9ce75eda

New changeset fc0201ccbcd4 by Antoine Pitrou in branch 'default':
Issue #23576: Avoid stalling in SSL reads when EOF has been reached in the SSL layer but the underlying connection hasn't been closed.
https://hg.python.org/cpython/rev/fc0201ccbcd4

----------

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

From report at bugs.python.org  Wed Mar  4 21:43:13 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 04 Mar 2015 20:43:13 +0000
Subject: [issue23583] IDLE: printing unicode subclasses broken (again)
In-Reply-To: <1425481188.05.0.778183770327.issue23583@psf.upfronthosting.co.za>
Message-ID: <1425501793.5.0.113266432131.issue23583@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

What about just 's = unicode(s)'?  The doc says

"object.__unicode__(self)

    Called to implement unicode() built-in; should return a Unicode object. When this method is not defined, string conversion is attempted, and the result of string conversion is converted to Unicode using the system default encoding."

but the latter part seems not to be true for unicode subclasses.

>>> class F(unicode):
	def __str__(self): raise TypeError()

>>> f = F()
>>> u = unicode(f)
>>> type(u)
<type 'unicode'>

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

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

From report at bugs.python.org  Wed Mar  4 21:50:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Mar 2015 20:50:41 +0000
Subject: [issue23583] IDLE: printing unicode subclasses broken (again)
In-Reply-To: <1425481188.05.0.778183770327.issue23583@psf.upfronthosting.co.za>
Message-ID: <1425502241.7.0.978150092014.issue23583@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See example in msg205740. The same works with overridden __unicode__.

I'm writing tests now.

----------

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

From report at bugs.python.org  Wed Mar  4 21:57:38 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 04 Mar 2015 20:57:38 +0000
Subject: [issue23582] multiprocessing.Queue.get is not getting all the items
 in the queue
In-Reply-To: <1425464148.59.0.542661724106.issue23582@psf.upfronthosting.co.za>
Message-ID: <1425502658.79.0.656699649901.issue23582@psf.upfronthosting.co.za>


R. David Murray added the comment:

You are calling q.empty when draining the queue.  That has the same documented caution.  Since you are using get in that loop, in that case you *want* to be calling qsize, just like you do when you drain it at the end.

----------

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

From report at bugs.python.org  Wed Mar  4 22:04:29 2015
From: report at bugs.python.org (David Wilson)
Date: Wed, 04 Mar 2015 21:04:29 +0000
Subject: [issue22003] BytesIO copy-on-write
In-Reply-To: <1405635937.15.0.406925083031.issue22003@psf.upfronthosting.co.za>
Message-ID: <1425503069.48.0.602815825879.issue22003@psf.upfronthosting.co.za>


David Wilson added the comment:

Hi Piotr,

There wasn't an obvious fix that didn't involve changing the buffer interface itself. There is presently ambiguity in the interface regarding the difference between a "read only" buffer and an "immutable" buffer, which is crucial for its use in this case.

Fixing the interface, followed by every buffer interface user, is a significantly more complicated task than simply optimizing for the most common case, as done here. FWIW I still think this work is worth doing, though I personally don't have time to approach it just now.

We could have (and possibly should) approach fixing e.g. mmap.mmap() hashability, possibly causing user code regressions, but even if such cases were fixed it still wouldn't be a enough to rely on for the optimization implemented here.

----------

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

From report at bugs.python.org  Wed Mar  4 22:04:39 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 04 Mar 2015 21:04:39 +0000
Subject: [issue23583] IDLE: printing unicode subclasses broken (again)
In-Reply-To: <1425481188.05.0.778183770327.issue23583@psf.upfronthosting.co.za>
Message-ID: <1425503079.0.0.182784797095.issue23583@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I don't see what you have in mind.  Translating my example

class S(str):
    def __str__(self):
        return 'S: ' + str.__str__(self)

to

class U(unicode):
    def __unicode__(self):
        return u'U: ' + unicode.__unicode__(self)

does not work because there is no unicode.__unicode__.

----------

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

From report at bugs.python.org  Wed Mar  4 22:33:34 2015
From: report at bugs.python.org (=?utf-8?q?Roberto_Mart=C3=ADnez?=)
Date: Wed, 04 Mar 2015 21:33:34 +0000
Subject: [issue23582] multiprocessing.Queue.get is not getting all the items
 in the queue
In-Reply-To: <1425464148.59.0.542661724106.issue23582@psf.upfronthosting.co.za>
Message-ID: <1425504814.87.0.647041158157.issue23582@psf.upfronthosting.co.za>


Roberto Mart?nez added the comment:

That's not my point.

To my understanding, when you put a item in the queue the item *must* be available to get in the next call. So I think put should block until the item is really in the queue so when you call get it return *always* and not some times (depending on the item size).

If this is not the expected behavior I think it should be warned in the put/get method.

----------

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

From report at bugs.python.org  Wed Mar  4 23:37:28 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Wed, 04 Mar 2015 22:37:28 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425508648.71.0.354430947561.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

Ryan,
I believe I've gotten all non-configure dependent commits in. 
How do you want me to handle post-configure edits I;ve made to get Python working (i.e. changes to pyconfig.h, Modules/Setup...)

----------

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

From report at bugs.python.org  Wed Mar  4 23:42:10 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Wed, 04 Mar 2015 22:42:10 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425508930.85.0.377981741777.issue23496@psf.upfronthosting.co.za>


Ryan Gonzalez added the comment:

Cyd:

What exactly do you mean by post-configure edits?

----------

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

From report at bugs.python.org  Thu Mar  5 00:08:28 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Mar 2015 23:08:28 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <20150304230825.1781.86471@psf.io>


Roundup Robot added the comment:

New changeset 73afda5a4e4c by Robert Collins in branch 'default':
Issue #17911: traceback module overhaul
https://hg.python.org/cpython/rev/73afda5a4e4c

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Mar  5 00:14:22 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 04 Mar 2015 23:14:22 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1425510862.24.0.177903067532.issue22936@psf.upfronthosting.co.za>


Robert Collins added the comment:

And now updated to HEAD as 17911 has been committed.

----------
Added file: http://bugs.python.org/file38332/issue-22936-3.patch

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

From report at bugs.python.org  Thu Mar  5 00:23:05 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 04 Mar 2015 23:23:05 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1425511385.3.0.661744953718.issue22936@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


Removed file: http://bugs.python.org/file38332/issue-22936-3.patch

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

From report at bugs.python.org  Thu Mar  5 00:23:06 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Wed, 04 Mar 2015 23:23:06 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425511386.22.0.0304191139789.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

Ryan,
Edits made to files generated or modified by running ./configure.  Example: pyconfig.h.

----------

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

From report at bugs.python.org  Thu Mar  5 00:23:14 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 04 Mar 2015 23:23:14 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1425511394.75.0.0577020020199.issue22936@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


Added file: http://bugs.python.org/file38333/issue-22936-3.patch

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

From report at bugs.python.org  Thu Mar  5 00:26:26 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 Mar 2015 23:26:26 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <20150304232611.9680.35570@psf.io>


Roundup Robot added the comment:

New changeset 7cea10917f40 by Robert Collins in branch 'default':
Fix brownbag in issue 17911 commit
https://hg.python.org/cpython/rev/7cea10917f40

----------

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

From report at bugs.python.org  Thu Mar  5 00:35:49 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 04 Mar 2015 23:35:49 +0000
Subject: [issue23585] patchcheck doesn't depend on all
Message-ID: <1425512149.56.0.0578590803035.issue23585@psf.upfronthosting.co.za>


New submission from Robert Collins:

make patchcheck depends on the interpreter and modules being built to work correctly but the make target doesn't have this expressed. This simple patch will fix it and adds well under a second of latency for me.

cpython.hg$ make patchcheck
./python ./Tools/scripts/patchcheck.py
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Failed to import the site module
Traceback (most recent call last):
  File "/home/robertc/work/cpython.hg/Lib/site.py", line 555, in <module>
    main()
  File "/home/robertc/work/cpython.hg/Lib/site.py", line 541, in main
    known_paths = addusersitepackages(known_paths)
  File "/home/robertc/work/cpython.hg/Lib/site.py", line 281, in addusersitepackages
    user_site = getusersitepackages()
  File "/home/robertc/work/cpython.hg/Lib/site.py", line 257, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/home/robertc/work/cpython.hg/Lib/site.py", line 247, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/home/robertc/work/cpython.hg/Lib/sysconfig.py", line 582, in get_config_var
    return get_config_vars().get(name)
  File "/home/robertc/work/cpython.hg/Lib/sysconfig.py", line 531, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/home/robertc/work/cpython.hg/Lib/sysconfig.py", line 403, in _init_posix
    from _sysconfigdata import build_time_vars
ImportError: No module named '_sysconfigdata'
Makefile:1640: recipe for target 'patchcheck' failed
make: *** [patchcheck] Error 1

----------
components: Interpreter Core
files: patchcheck.patch
keywords: patch
messages: 237221
nosy: rbcollins
priority: normal
severity: normal
status: open
title: patchcheck doesn't depend on all
type: compile error
versions: Python 3.6
Added file: http://bugs.python.org/file38334/patchcheck.patch

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

From report at bugs.python.org  Thu Mar  5 01:05:11 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Thu, 05 Mar 2015 00:05:11 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425513911.1.0.139894382111.issue23496@psf.upfronthosting.co.za>


Ryan Gonzalez added the comment:

Cyd:

Don't upload them. Git won't even let you add pyconfig.h; running `git add PC/pyconfig.h` won't say anything, but running `git status` will show that it did not do anything.

----------

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

From report at bugs.python.org  Thu Mar  5 01:20:52 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 05 Mar 2015 00:20:52 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1425514852.63.0.976492684375.issue22906@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Looking for code reviewers!

----------
stage:  -> patch review
type:  -> enhancement

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

From report at bugs.python.org  Thu Mar  5 02:32:46 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 05 Mar 2015 01:32:46 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1425519166.48.0.991311808996.issue17911@psf.upfronthosting.co.za>


Ned Deily added the comment:

With 7cea10917f40 applied, multiple tests are now failing on most buildbots.  For example, on OS X 10.10, test_cgitb test_code_module test_decimal:

test_blanks (test.test_cgitb.TestCgitb) ... ok
test_fonts (test.test_cgitb.TestCgitb) ... ok
test_html (test.test_cgitb.TestCgitb) ... ERROR
test_syshook_no_logdir_default_format (test.test_cgitb.TestCgitb) ... ok
test_syshook_no_logdir_text_format (test.test_cgitb.TestCgitb) ... ok
test_text (test.test_cgitb.TestCgitb) ... ERROR

test_banner (test.test_code_module.TestInteractiveConsole) ... ok
test_cause_tb (test.test_code_module.TestInteractiveConsole) ... ERROR
test_console_stderr (test.test_code_module.TestInteractiveConsole) ... ok
test_context_tb (test.test_code_module.TestInteractiveConsole) ... ERROR
test_ps1 (test.test_code_module.TestInteractiveConsole) ... ok
test_ps2 (test.test_code_module.TestInteractiveConsole) ... ok
test_syntax_error (test.test_code_module.TestInteractiveConsole) ... ERROR
test_sysexcepthook (test.test_code_module.TestInteractiveConsole) ... ERROR

**********************************************************************
1 items had failures:
   1 of   4 in decimal.Context.create_decimal_from_float

See also, for example, the Debian buildbot where, in addition, test_fractions failed:

http://buildbot.python.org/all/builders/AMD64%20Debian%20PGO%203.x/builds/140/steps/test/logs/stdio

----------
nosy: +ned.deily
priority: normal -> critical

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

From report at bugs.python.org  Thu Mar  5 02:36:48 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 05 Mar 2015 01:36:48 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1425519408.17.0.103876868547.issue17911@psf.upfronthosting.co.za>


Robert Collins added the comment:

Thats really strange, I did a ./python -m test run before committing - the brown bag was due to me running with the patch for 22936 also applied. Looking into the failures reported now.

----------

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

From report at bugs.python.org  Thu Mar  5 02:42:13 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Mar 2015 01:42:13 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <20150305014209.16647.94741@psf.io>


Roundup Robot added the comment:

New changeset 77a978716517 by Victor Stinner in branch '3.4':
Issue #21619: Try to fix test_broken_pipe_cleanup()
https://hg.python.org/cpython/rev/77a978716517

----------

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

From report at bugs.python.org  Thu Mar  5 02:44:14 2015
From: report at bugs.python.org (Charles-Axel Dein)
Date: Thu, 05 Mar 2015 01:44:14 +0000
Subject: [issue23586] Add classproperty to the builtin functions
Message-ID: <1425519854.76.0.695976269256.issue23586@psf.upfronthosting.co.za>


New submission from Charles-Axel Dein:

Similar to http://bugs.python.org/issue20659

Having a behavior that is similar to a property on a class seems intuitive enough. Is there any specific reason why it does not exist?

----------
messages: 237227
nosy: charlax
priority: normal
severity: normal
status: open
title: Add classproperty to the builtin functions
type: enhancement

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

From report at bugs.python.org  Thu Mar  5 02:53:04 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 05 Mar 2015 01:53:04 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1425520384.42.0.489044922769.issue17911@psf.upfronthosting.co.za>


Robert Collins added the comment:

Ok, cgitb - its passing a string instead of an exception type into format_exception - something that was never supported - it only works by accident AFAICT, because the old format code was ignoring the etype - it was deriving the type from the value. Thats easy to accomodate in the compat code.

----------

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

From report at bugs.python.org  Thu Mar  5 02:54:30 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 05 Mar 2015 01:54:30 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1425520470.41.0.878005578373.issue17911@psf.upfronthosting.co.za>


Robert Collins added the comment:

Also apologies - ned told me on IRC that python -m test -uall is needed, not just -m test. Doh.

----------

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

From report at bugs.python.org  Thu Mar  5 02:54:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Mar 2015 01:54:51 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1425520491.37.0.0778028126562.issue17911@psf.upfronthosting.co.za>


STINNER Victor added the comment:

There are failures on buildbot.
http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/5651/steps/test/logs/stdio
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/5783/steps/test/logs/stdio
http://buildbot.python.org/all/builders/PPC64%20PowerLinux%203.x/builds/3109/steps/test/logs/stdio

Examples:

======================================================================
ERROR: test_cause_tb (test.test_code_module.TestInteractiveConsole)
----------------------------------------------------------------------
Traceback (most recent call last):
AttributeError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/opt/python/3.x.langa-ubuntu/build/Lib/code.py", line 91, in runcode
    exec(code, self.locals)
  File "<console>", line 1, in <module>
ValueError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_code_module.py", line 85, in test_cause_tb
    self.console.interact()
  File "/opt/python/3.x.langa-ubuntu/build/Lib/code.py", line 245, in interact
    more = self.push(line)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/code.py", line 267, in push
    more = self.runsource(source, self.filename)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/code.py", line 75, in runsource
    self.runcode(code)
  File "/opt/python/3.x.langa-ubuntu/build/Lib/code.py", line 95, in runcode
    self.showtraceback()
  File "/opt/python/3.x.langa-ubuntu/build/Lib/code.py", line 144, in showtraceback
    for value, tb in traceback._iter_chain(*ei[1:]):
AttributeError: module 'traceback' has no attribute '_iter_chain'



======================================================================
ERROR: test_html (test.test_cgitb.TestCgitb)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/test_cgitb.py", line 23, in test_html
    raise ValueError("Hello World")
ValueError: Hello World

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/test/test_cgitb.py", line 27, in test_html
    html = cgitb.html(sys.exc_info())
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/cgitb.py", line 189, in html
    ''.join(traceback.format_exception(etype, evalue, etb)))
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/traceback.py", line 109, in format_exception
    etype, value, tb, limit=limit).format(chain=chain))
  File "/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/traceback.py", line 433, in __init__
    if exc_type and issubclass(exc_type, SyntaxError):
TypeError: issubclass() arg 1 must be a class

----------

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

From report at bugs.python.org  Thu Mar  5 03:01:11 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 05 Mar 2015 02:01:11 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1425520871.48.0.607907457092.issue17911@psf.upfronthosting.co.za>


Robert Collins added the comment:

code module is using a _function from within the traceback module to filter out a frame - we can do that with the new interface easily (it filters the first tem).

----------

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

From report at bugs.python.org  Thu Mar  5 03:04:39 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 05 Mar 2015 02:04:39 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1425521079.03.0.336258924488.issue17911@psf.upfronthosting.co.za>


Robert Collins added the comment:

The decimal failure is due to _format_final_exc_line now filtering out 'None' as well, because the string captured values of objects leads to None -> 'None' before we do rendering.

I think in this case its reasonable to change the behaviour (since None itself was already filtered out, its only the special case of a value of 'None' that worked previously).

----------

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

From report at bugs.python.org  Thu Mar  5 03:20:55 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 05 Mar 2015 02:20:55 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1425522055.62.0.199662483106.issue17911@psf.upfronthosting.co.za>


Robert Collins added the comment:

Fixes for buildbots.

----------
Added file: http://bugs.python.org/file38335/issue-19711-8.patch

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

From report at bugs.python.org  Thu Mar  5 03:33:28 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Mar 2015 02:33:28 +0000
Subject: [issue23587] asyncio: use the new traceback.TracebackException class
Message-ID: <1425522808.88.0.474702563408.issue23587@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In Python 3, an exception contains a traceback. A traceback contains frames which contain local variables. Sometimes, the newly raised exception is a local variable and so we get a reference cycle: exc -> traceback -> frame -> exc...

In asyncio, it's a real issue because exception objects are kept alive longer than an except block. They are stored in Future objects by Future.set_exception() (and so Task.set_exception()).

Python 3.5 has a new traceback.TracebackException (see issue #17911) which creates a light "view" which can be used to format a traceback and the view doesn't contain local variables.

It would be great if we can use it.

The problem is to that Future.result() raises the exception set in Future.set_exception(), and we except to get the traceback of the exception.

So it's unclear to me how long we must store the exception.

Maybe we can only store a traceback.TracebackException in release mode and store the full traceback object in debug mode? Such change means that enabling the debug mode may create reference cycles (compared to the new release mode), which can be very suprising and annoying.

----------
messages: 237234
nosy: haypo, rbcollins
priority: normal
severity: normal
status: open
title: asyncio: use the new traceback.TracebackException class
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar  5 03:34:31 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Mar 2015 02:34:31 +0000
Subject: [issue23587] asyncio: use the new traceback.TracebackException class
In-Reply-To: <1425522808.88.0.474702563408.issue23587@psf.upfronthosting.co.za>
Message-ID: <1425522871.42.0.616582432501.issue23587@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also:
https://code.google.com/p/tulip/issues/detail?id=155
https://code.google.com/p/tulip/issues/detail?id=42
http://bugs.python.org/issue17911

----------

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

From report at bugs.python.org  Thu Mar  5 03:37:00 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Mar 2015 02:37:00 +0000
Subject: [issue23587] asyncio: use the new traceback.TracebackException class
In-Reply-To: <1425522808.88.0.474702563408.issue23587@psf.upfronthosting.co.za>
Message-ID: <1425523020.94.0.976378861855.issue23587@psf.upfronthosting.co.za>


STINNER Victor added the comment:

By the way, Robert Collins proposed the following change in part of #17911, but it was removed in the final change because asyncio must support Python 3.4 (and 3.3):

diff --git a/Lib/asyncio/events.py b/Lib/asyncio/events.py
index 01320cd..08740aa 100644
--- a/Lib/asyncio/events.py
+++ b/Lib/asyncio/events.py
@@ -95,7 +95,7 @@ class Handle:
             info.append(_format_callback(self._callback, self._args))
         if self._source_traceback:
             frame = self._source_traceback[-1]
-            info.append('created at %s:%s' % (frame[0], frame[1]))
+            info.append('created at %s:%s' % (frame.filename, frame.lineno))
         return info
 
     def __repr__(self):

----------

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

From report at bugs.python.org  Thu Mar  5 03:52:53 2015
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 05 Mar 2015 02:52:53 +0000
Subject: [issue23476] SSL cert verify fail for "www.verisign.com"
In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za>
Message-ID: <1425523973.76.0.487120401478.issue23476@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald at stufft.io>:


----------
keywords: +needs review
resolution: not a bug -> 
stage: resolved -> patch review
status: closed -> open

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

From report at bugs.python.org  Thu Mar  5 04:02:16 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 05 Mar 2015 03:02:16 +0000
Subject: [issue19931] namedtuple docstrings are verbose for no added benefit
In-Reply-To: <1386521214.76.0.425352875537.issue19931@psf.upfronthosting.co.za>
Message-ID: <1425524536.06.0.0555294082555.issue19931@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
type:  -> enhancement
versions: +Python 3.4, Python 3.5 -Python 3.3

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

From report at bugs.python.org  Thu Mar  5 04:11:31 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 05 Mar 2015 03:11:31 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1425525091.45.0.247252888227.issue17911@psf.upfronthosting.co.za>


Ned Deily added the comment:

Much better, thanks!

----------
priority: critical -> normal

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

From report at bugs.python.org  Thu Mar  5 04:11:56 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Mar 2015 03:11:56 +0000
Subject: [issue23476] SSL cert verify fail for "www.verisign.com"
In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za>
Message-ID: <20150305031153.7583.17403@psf.io>


Roundup Robot added the comment:

New changeset 7f64437a707f by Benjamin Peterson in branch '3.4':
enable X509_V_FLAG_TRUSTED_FIRST when possible (closes #23476)
https://hg.python.org/cpython/rev/7f64437a707f

New changeset 37da00170836 by Benjamin Peterson in branch '2.7':
enable X509_V_FLAG_TRUSTED_FIRST when possible (closes #23476)
https://hg.python.org/cpython/rev/37da00170836

New changeset 442e2c357979 by Benjamin Peterson in branch 'default':
merge 3.4 (#23476)
https://hg.python.org/cpython/rev/442e2c357979

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Mar  5 04:40:53 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 05 Mar 2015 03:40:53 +0000
Subject: [issue19771] runpy should check ImportError.name before wrapping it
In-Reply-To: <1385383187.11.0.803942496087.issue19771@psf.upfronthosting.co.za>
Message-ID: <1425526853.38.0.0156435674118.issue19771@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage: needs patch -> patch review
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Thu Mar  5 05:10:08 2015
From: report at bugs.python.org (Ben Darnell)
Date: Thu, 05 Mar 2015 04:10:08 +0000
Subject: [issue23588] Errno conflicts in ssl.SSLError
Message-ID: <1425528608.86.0.380656858337.issue23588@psf.upfronthosting.co.za>


New submission from Ben Darnell:

ssl.SSLError is a subclass of OSError but uses error codes that come from a different scope than the standard errno constants and may have conflicts. For example, on my system (OSX), ssl.SSL_ERROR_WANT_X509_LOOKUP and errno.EINTR have the same value. This would cause problems for code like the following:

  def f():
    while True:
      try:
        return ssl_sock.read()
      except OSError as e:
        if e.errno == errno.EINTR:
          continue
        raise

This function would loop endlessly on ssl.SSL_ERROR_WANT_X509_LOOKUP. (Note that I have not run into any problem like this in practice so this is not a severe issue; I just stumbled across the possibility). The EINTR case is moot now that Python itself retries on EINTR, but other conflicts are possible (the problem is also mitigated by the fact that most of the interesting errnos now have dedicated exception subtypes)

To use OSError.errno correctly, it is currently necessary to check the exact type of the exception; it is not enough to do subclass matching as is usual for exceptions. To remedy this, I propose either changing the numeric constants in the SSL module (if these are not required to match constants defined in openssl), or adding an attribute to OSError like 'errno_scope' to be used when interpreting the errno field.

----------
messages: 237239
nosy: Ben.Darnell
priority: normal
severity: normal
status: open
title: Errno conflicts in ssl.SSLError
type: behavior

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

From report at bugs.python.org  Thu Mar  5 05:35:14 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 05 Mar 2015 04:35:14 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425530114.36.0.913599015409.issue23524@psf.upfronthosting.co.za>


Steve Dower added the comment:

Since we're doing alpha 2 this weekend, I'm keen to get this fix in. Any comments from anyone? Or are people just generally okay with me checking it in and relying on the buildbots?

----------

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

From report at bugs.python.org  Thu Mar  5 05:46:02 2015
From: report at bugs.python.org (Larry Hastings)
Date: Thu, 05 Mar 2015 04:46:02 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425530762.89.0.279925273543.issue23524@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I can live with that, if you're confident in it and you'll watch the buildbots.

----------

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

From report at bugs.python.org  Thu Mar  5 06:37:32 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 05 Mar 2015 05:37:32 +0000
Subject: [issue23588] Errno conflicts in ssl.SSLError
In-Reply-To: <1425528608.86.0.380656858337.issue23588@psf.upfronthosting.co.za>
Message-ID: <1425533852.87.0.577905839907.issue23588@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Mar  5 07:35:04 2015
From: report at bugs.python.org (Jack O'Connor)
Date: Thu, 05 Mar 2015 06:35:04 +0000
Subject: [issue23548] TypeError in event loop finalizer, new in Python 3.4.3
In-Reply-To: <1425139981.48.0.523334940185.issue23548@psf.upfronthosting.co.za>
Message-ID: <1425537304.18.0.03704774361.issue23548@psf.upfronthosting.co.za>


Jack O'Connor added the comment:

@gvanrossum, the last two lines you suggested don't give any error, as expected. Not sure why we're getting that error message in the toy example.

@haypo, closing the event loop explicitly works fine for me. But since you mentioned it, I don't see any warning when I leave out closing the event loop and turn on PYTHONASYNCIODEBUG=1. What should I be seeing?

----------

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

From report at bugs.python.org  Thu Mar  5 07:37:55 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 05 Mar 2015 06:37:55 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1425537475.24.0.247089217133.issue22936@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


Added file: http://bugs.python.org/file38336/issue-22936-4.patch

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

From report at bugs.python.org  Thu Mar  5 07:48:49 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Mar 2015 06:48:49 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1425538129.24.0.358953240743.issue22936@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Latest patch (issue-22936-4.patch) looks good to me!

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

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

From report at bugs.python.org  Thu Mar  5 08:29:31 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Mar 2015 07:29:31 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <20150305072903.7565.18596@psf.io>


Roundup Robot added the comment:

New changeset 50741316dd3a by Robert Collins in branch 'default':
Issue #22936: Make it possible to show local variables in tracebacks.
https://hg.python.org/cpython/rev/50741316dd3a

----------
nosy: +python-dev

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

From report at bugs.python.org  Thu Mar  5 08:29:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Mar 2015 07:29:54 +0000
Subject: [issue23583] IDLE: printing unicode subclasses broken (again)
In-Reply-To: <1425481188.05.0.778183770327.issue23583@psf.upfronthosting.co.za>
Message-ID: <1425540594.26.0.709076040112.issue23583@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> does not work because there is no unicode.__unicode__.

Yes, this is why unicode.__getslice__ or unicode.__getitem__ should be used.

Here is a patch for 2.7 that fixes this issue and adds tests for PseudoOutputFile and PseudoInputFile. Tests should be ported also to 3.x.

----------
assignee:  -> serhiy.storchaka
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file38337/idle_test_io-2.7.patch

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

From report at bugs.python.org  Thu Mar  5 08:38:39 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Mar 2015 07:38:39 +0000
Subject: [issue23583] IDLE: printing unicode subclasses broken (again)
In-Reply-To: <1425481188.05.0.778183770327.issue23583@psf.upfronthosting.co.za>
Message-ID: <1425541119.1.0.69674886861.issue23583@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file38338/idle_test_io-3.5.patch

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

From report at bugs.python.org  Thu Mar  5 09:07:47 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 05 Mar 2015 08:07:47 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1425542867.53.0.593115088171.issue22936@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

In the patch you made some args kw-only.
Isn't that backward incompatible in case someone was passing them by position?

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

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

From report at bugs.python.org  Thu Mar  5 09:24:59 2015
From: report at bugs.python.org (Neil Girdhar)
Date: Thu, 05 Mar 2015 08:24:59 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1425543899.59.0.303956458072.issue22906@psf.upfronthosting.co.za>


Neil Girdhar added the comment:

FWIW I looked at the changes.  Does it make sense to run tests before there are actual tests in lib/Test?  I'll happily run all tests when some new ones are added.

----------
nosy: +neil.g

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

From report at bugs.python.org  Thu Mar  5 09:32:38 2015
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 05 Mar 2015 08:32:38 +0000
Subject: [issue23589] Redundant sentence in FAQ
Message-ID: <1425544358.43.0.799956102379.issue23589@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

In https://docs.python.org/3/faq/programming.html#what-are-the-rules-for-local-and-global-variables-in-python, two sentences of essentially the same meaning exist. I try to remove this redundancy.

----------
assignee: docs at python
components: Documentation
files: faq_fix.diff
keywords: patch
messages: 237248
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: Redundant sentence in FAQ
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38339/faq_fix.diff

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

From report at bugs.python.org  Thu Mar  5 09:36:52 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Mar 2015 08:36:52 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425544612.28.0.702391703558.issue21619@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Looks as tests are fixed. Thank you Victor.

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Mar  5 09:51:06 2015
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 05 Mar 2015 08:51:06 +0000
Subject: [issue14544] Limit "global" keyword name conflicts in language spec
 to those enforced by CPython
In-Reply-To: <1334119591.44.0.0449104949206.issue14544@psf.upfronthosting.co.za>
Message-ID: <1425545466.48.0.952658878272.issue14544@psf.upfronthosting.co.za>


Changes by Yongzhi Pan <panyongzhi at gmail.com>:


----------
nosy: +fossilet

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

From report at bugs.python.org  Thu Mar  5 10:17:41 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Mar 2015 09:17:41 +0000
Subject: [issue19931] namedtuple docstrings are verbose for no added benefit
In-Reply-To: <1386521214.76.0.425352875537.issue19931@psf.upfronthosting.co.za>
Message-ID: <1425547061.06.0.146047567046.issue19931@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I don't think we should strip-out all the docstrings because you're unhappy with automatically (mindlessly) generated documentation.  What you really need is more control over the documentation tool (the ability to save how much detail you want, particularly with subclasses of builtins which have a ton of methods with simplistic docstrings and with abstract base classes).  

The docstring for __repr__ isn't especially useful but it is a key feature of a namedtuple.  

The docstring for __getnewargs__ is informative especially if you're subclassing a named tuple and need to know what it is used for.   

The docstring for the individual property attributes doesn't look helpful when you list them all but does add information for one-at-a-time help, such as help(Key.blockscope), or for tooltips.   FWIW, there is also a proposal to make it easier to custom the default docstrings for the properties (to turn it into more of a data dictionary).

----------
assignee: docs at python -> rhettinger
resolution:  -> rejected
status: open -> closed
versions:  -Python 2.7, Python 3.4

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

From report at bugs.python.org  Thu Mar  5 10:22:40 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Mar 2015 09:22:40 +0000
Subject: [issue23586] Add classproperty to the builtin functions
In-Reply-To: <1425519854.76.0.695976269256.issue23586@psf.upfronthosting.co.za>
Message-ID: <1425547360.47.0.652576957874.issue23586@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I think you should take this up on python-ideas and don't expect it to gain any traction here.  For best results, the proposal should be accompanied by valid use cases that can't easily be handled in some other way.  The bar for adding a new builtin function is somewhat high so there would need to be good reasons.

----------
nosy: +rhettinger
resolution:  -> rejected
status: open -> closed
versions: +Python 3.5

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

From report at bugs.python.org  Thu Mar  5 10:24:12 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 05 Mar 2015 09:24:12 +0000
Subject: [issue23589] Redundant sentence in FAQ
In-Reply-To: <1425544358.43.0.799956102379.issue23589@psf.upfronthosting.co.za>
Message-ID: <1425547452.59.0.906932597183.issue23589@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
stage:  -> commit review
versions: +Python 2.7 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Mar  5 10:29:58 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Mar 2015 09:29:58 +0000
Subject: [issue14544] Limit "global" keyword name conflicts in language spec
 to those enforced by CPython
In-Reply-To: <1334119591.44.0.0449104949206.issue14544@psf.upfronthosting.co.za>
Message-ID: <1425547798.95.0.844493752023.issue14544@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1 for the proposed change.   It should add there is also an enforced (and obvious) restriction that the variable not have been declared nonlocal.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Thu Mar  5 10:30:05 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Mar 2015 09:30:05 +0000
Subject: [issue23476] SSL cert verify fail for "www.verisign.com"
In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za>
Message-ID: <1425547805.93.0.561524854339.issue23476@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Benjamin, can you please add at least a comment describing why you added the flag? We have enough obscure-looking code in _ssl.c as it is.

----------

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

From report at bugs.python.org  Thu Mar  5 10:31:29 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Mar 2015 09:31:29 +0000
Subject: [issue23579] Amazon.com links
In-Reply-To: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>
Message-ID: <1425547889.08.0.0336212903468.issue23579@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> low

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

From report at bugs.python.org  Thu Mar  5 10:35:33 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Mar 2015 09:35:33 +0000
Subject: [issue23476] SSL cert verify fail for "www.verisign.com"
In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za>
Message-ID: <1425548133.06.0.521388575473.issue23476@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Uh, the comment is already there. I don't know how I missed that. Sorry.

----------

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

From report at bugs.python.org  Thu Mar  5 11:03:11 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 05 Mar 2015 10:03:11 +0000
Subject: [issue14544] Limit "global" keyword name conflicts in language spec
 to those enforced by CPython
In-Reply-To: <1334119591.44.0.0449104949206.issue14544@psf.upfronthosting.co.za>
Message-ID: <1425549791.44.0.42337736062.issue14544@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
stage:  -> needs patch
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Thu Mar  5 11:18:13 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Mar 2015 10:18:13 +0000
Subject: [issue23589] Redundant sentence in FAQ
In-Reply-To: <1425544358.43.0.799956102379.issue23589@psf.upfronthosting.co.za>
Message-ID: <1425550693.65.0.322782894319.issue23589@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

How about:

In Python, variables that are only referenced inside a function are implicitly
global.  If a variable is assigned a value anywhere within the function's
body, it's assumed to be a local unless explicitly declared as global.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Thu Mar  5 11:40:00 2015
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 05 Mar 2015 10:40:00 +0000
Subject: [issue23589] Redundant sentence in FAQ
In-Reply-To: <1425544358.43.0.799956102379.issue23589@psf.upfronthosting.co.za>
Message-ID: <1425552000.11.0.759119439332.issue23589@psf.upfronthosting.co.za>


Yongzhi Pan added the comment:

Updated diff as Raymond's wording.

----------
Added file: http://bugs.python.org/file38340/faq_fix_1.diff

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

From report at bugs.python.org  Thu Mar  5 12:00:54 2015
From: report at bugs.python.org (Neil Girdhar)
Date: Thu, 05 Mar 2015 11:00:54 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1425553254.5.0.190267592972.issue2292@psf.upfronthosting.co.za>


Neil Girdhar added the comment:

Removed dead code.  Awaiting code review! :)

----------
Added file: http://bugs.python.org/file38341/starunpack35.diff

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

From report at bugs.python.org  Thu Mar  5 12:03:48 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Mar 2015 11:03:48 +0000
Subject: [issue23548] TypeError in event loop finalizer, new in Python 3.4.3
In-Reply-To: <1425537304.18.0.03704774361.issue23548@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbz3Y47SDYpQGG-G8eunTv=DLXxBqvCVbFDNW_qcos+CA@mail.gmail.com>


STINNER Victor added the comment:

Did you read the latest doc? You should also use the -Wd command line
option to see resource warnings.

----------

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

From report at bugs.python.org  Thu Mar  5 12:06:38 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Mar 2015 11:06:38 +0000
Subject: [issue23548] TypeError in event loop finalizer, new in Python 3.4.3
In-Reply-To: <CAMpsgwbz3Y47SDYpQGG-G8eunTv=DLXxBqvCVbFDNW_qcos+CA@mail.gmail.com>
Message-ID: <CAMpsgwY8Ubgaq_ERSXSWsSFkD2SxXdyyT5NDSqPzv39-LCF5mw@mail.gmail.com>


STINNER Victor added the comment:

Debug mode:
https://docs.python.org/dev/library/asyncio-dev.html#asyncio-debug-mode

----------

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

From report at bugs.python.org  Thu Mar  5 12:11:43 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Thu, 05 Mar 2015 11:11:43 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425553903.66.0.380646042552.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

I understand; I haven't made the edits to these files but the edits are needed in order for the Android build to work properly.

How do you want me to handle them? I can post the expected values here as a diff, or just as plain text...?

----------

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

From report at bugs.python.org  Thu Mar  5 12:48:53 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 05 Mar 2015 11:48:53 +0000
Subject: [issue23589] Redundant sentence in FAQ
In-Reply-To: <1425544358.43.0.799956102379.issue23589@psf.upfronthosting.co.za>
Message-ID: <1425556133.46.0.053040714199.issue23589@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I think the first sentence could be improved, even though it's correct.
A superficial reading might give the impression that function variables are implicitly global, or that only the variables inside a function are global, especially if the reader is not familiar with the term "referenced".
Swapping the two sentences and talking first about assignment might be enough to make clear that the other sentence is talking about variables that are only read/accessed by the function but not defined/assigned.
The paragraph can also be rephrased to say that Python can freely access variables from outer scopes, but that "global" is required to assign a new value to a global variable, and that variables defined inside a function are local.

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

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

From report at bugs.python.org  Thu Mar  5 15:07:00 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Mar 2015 14:07:00 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1425564420.01.0.291367185187.issue22936@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

It's only the new APIs just introduced in issue #17911 that changed to kwonly arguments.

We missed that they should really be kwonly in the original review, but it become more obvious in this patch, as it added a second feature toggle to indicate whether or not to capture the locals.

----------

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

From report at bugs.python.org  Thu Mar  5 15:10:01 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Mar 2015 14:10:01 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425564601.61.0.00113939104021.issue23524@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I reviewed 23524_2.patch. I vote -1 on the patch.

----------

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

From report at bugs.python.org  Thu Mar  5 15:11:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Mar 2015 14:11:17 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425564677.75.0.800083516741.issue23524@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Since we're doing alpha 2 this weekend, I'm keen to get this fix in.

I would prefer a quick&dirty fix: disable "IFD" checks for all threads by default. We will find a better fix for the next release. IMO we should discuss this issue more to check if there is no nicer option.

----------

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

From report at bugs.python.org  Thu Mar  5 15:12:04 2015
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Thu, 05 Mar 2015 14:12:04 +0000
Subject: [issue23581] unittest.mock.MagicMock doesn't support matmul (@)
 operator
In-Reply-To: <1425461221.82.0.715365961896.issue23581@psf.upfronthosting.co.za>
Message-ID: <1425564724.53.0.822655214736.issue23581@psf.upfronthosting.co.za>


Changes by Saimadhav Heblikar <saimadhavheblikar at gmail.com>:


----------
nosy: +sahutd

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

From report at bugs.python.org  Thu Mar  5 15:51:08 2015
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Thu, 05 Mar 2015 14:51:08 +0000
Subject: [issue23551] IDLE to provide menu options for using PIP
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1425567068.42.0.134370779906.issue23551@psf.upfronthosting.co.za>


Saimadhav Heblikar added the comment:

Hi,
I would like to work on this. Give me a day or two to come up with my design plan, for feedback.
Let me know please if this feature addition is being considered.

----------
nosy: +sahutd

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

From report at bugs.python.org  Thu Mar  5 16:08:15 2015
From: report at bugs.python.org (Patrick Miller)
Date: Thu, 05 Mar 2015 15:08:15 +0000
Subject: [issue23590] Potential leak in PyFloat_AsDouble.  Refcount error.
Message-ID: <1425568095.39.0.812034754306.issue23590@psf.upfronthosting.co.za>


New submission from Patrick Miller:

There is a reference counting error in PyFloat_AsDouble.

When the function calls the nb_float conversion, if the method does not return an actual float object, an exception is set, but the object is not collected.

--- Objects/floatobject.c	2014-10-08 04:18:15.000000000 -0400
+++ Objects/floatobject.c.patched	2015-03-05 09:17:15.171455648 -0500
@@ -214,6 +214,7 @@
     if (fo == NULL)
         return -1;
     if (!PyFloat_Check(fo)) {
+        Py_DECREF(fo);
         PyErr_SetString(PyExc_TypeError,
                         "nb_float should return float object");
         return -1;

----------
components: Interpreter Core
files: floatobject.c-patch
messages: 237266
nosy: Patrick Miller
priority: normal
severity: normal
status: open
title: Potential leak in PyFloat_AsDouble.  Refcount error.
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file38342/floatobject.c-patch

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

From report at bugs.python.org  Thu Mar  5 16:08:35 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 05 Mar 2015 15:08:35 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1425568115.77.0.424082675093.issue22936@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

You are right -- I didn't notice the versionadded in the docs.
Sorry for the noise.

----------

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

From report at bugs.python.org  Thu Mar  5 16:16:07 2015
From: report at bugs.python.org (Patrick Miller)
Date: Thu, 05 Mar 2015 15:16:07 +0000
Subject: [issue23590] Potential leak in PyFloat_AsDouble.  Refcount error.
In-Reply-To: <1425568095.39.0.812034754306.issue23590@psf.upfronthosting.co.za>
Message-ID: <1425568567.2.0.609312535223.issue23590@psf.upfronthosting.co.za>


Patrick Miller added the comment:

Here's a simple recreator... It returns a 100-meg string instead of a float.  The memory is leaked each time through the loop

----------
Added file: http://bugs.python.org/file38343/recreate.tar

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

From report at bugs.python.org  Thu Mar  5 16:31:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Mar 2015 15:31:23 +0000
Subject: [issue23591] Add IntFlags
Message-ID: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is preliminary implementation of IntFlags (no docs). This is an int subclass purposed to represent a set of integer flags. It supports named constants (as IntEnum), supports bitwise operations (&, |, ~) and has funny str and repr. See discussion on Python-Ideas [1].

The patch includes tests and few examples of using IntFlags in the stdlib.

[1] http://comments.gmane.org/gmane.comp.python.ideas/32267

----------
components: Library (Lib)
files: intflags.patch
keywords: patch
messages: 237269
nosy: barry, eli.bendersky, ethan.furman, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add IntFlags
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38344/intflags.patch

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

From report at bugs.python.org  Thu Mar  5 16:32:05 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 05 Mar 2015 15:32:05 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425569525.13.0.754343380889.issue23524@psf.upfronthosting.co.za>


Steve Dower added the comment:

Happy to discuss further. I'll try and get a new patch done today that disables the handler for any threads Python creates a thread state for. The change to _Py_VERIFY_FD will still be there, but the begin/end suppress will go (using the verify function to protect CRT calls can go completely once we are prepared to force people to build with VC14, but I want to avoid that for as long as possible while we transition).

Also notice that Verify_fd is a race condition but was the best solution available at the time. I'm keen to see it go.

As far as a better solution goes, I've discussed this in depth with the main CRT developer at Microsoft and there won't be one. The best concession I could get was the thread local handler so we can disable it locally rather than process wide.

----------

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

From report at bugs.python.org  Thu Mar  5 16:38:22 2015
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 05 Mar 2015 15:38:22 +0000
Subject: [issue23590] Potential leak in PyFloat_AsDouble.  Refcount error.
In-Reply-To: <1425568095.39.0.812034754306.issue23590@psf.upfronthosting.co.za>
Message-ID: <1425569902.19.0.115939311181.issue23590@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Simple script to reproduce the issue:

import sys, time
class C(object):
  def __float__(self):
    return ""
for x in range(10000):
  try:
    time.sleep(C())
  except TypeError:
    pass
  if x % 1000 == 0:
    print(sys.getrefcount(""))

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Thu Mar  5 16:45:07 2015
From: report at bugs.python.org (Patrick Miller)
Date: Thu, 05 Mar 2015 15:45:07 +0000
Subject: [issue23590] Potential leak in PyFloat_AsDouble.  Refcount error.
In-Reply-To: <1425568095.39.0.812034754306.issue23590@psf.upfronthosting.co.za>
Message-ID: <1425570307.36.0.0656961606944.issue23590@psf.upfronthosting.co.za>


Patrick Miller added the comment:

Shout out to amaury for a much simpler recreator :-)

Checked to see if the int conversion suffered the same problem... it does not as it is structured somewhat differently.  Note that it DOES do the proper DECREF (missing in PyFloat_AsDouble).


    result = nb->nb_int(integral);
    if (!result || PyLong_CheckExact(result))
        return (PyLongObject *)result;
    if (!PyLong_Check(result)) {
        PyErr_Format(PyExc_TypeError,
                     "__int__ returned non-int (type %.200s)",
                     result->ob_type->tp_name);
        Py_DECREF(result);
        return NULL;
    }

----------

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

From report at bugs.python.org  Thu Mar  5 16:45:29 2015
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 05 Mar 2015 15:45:29 +0000
Subject: [issue23476] SSL cert verify fail for "www.verisign.com"
In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za>
Message-ID: <1425570329.83.0.45336981402.issue23476@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The Windows binaries of Python 2.7.9 are compiled with OpenSSL 1.0.1j. The feature is only available in OpenSSL > 1.0.2. The next version of Python must be compiled with 1.0.2 or better. Otherwise the bug pops up again.

----------

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

From report at bugs.python.org  Thu Mar  5 16:57:49 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 05 Mar 2015 15:57:49 +0000
Subject: [issue23591] Add IntFlags
In-Reply-To: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za>
Message-ID: <1425571069.76.0.799301260927.issue23591@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Mar  5 17:41:44 2015
From: report at bugs.python.org (Jack O'Connor)
Date: Thu, 05 Mar 2015 16:41:44 +0000
Subject: [issue23548] TypeError in event loop finalizer, new in Python 3.4.3
In-Reply-To: <1425139981.48.0.523334940185.issue23548@psf.upfronthosting.co.za>
Message-ID: <1425573704.43.0.761695928388.issue23548@psf.upfronthosting.co.za>


Jack O'Connor added the comment:

Got it, thanks for the heads up.

----------

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

From report at bugs.python.org  Thu Mar  5 17:52:29 2015
From: report at bugs.python.org (Patrick Miller)
Date: Thu, 05 Mar 2015 16:52:29 +0000
Subject: [issue23590] Potential leak in PyFloat_AsDouble.  Refcount error.
In-Reply-To: <1425568095.39.0.812034754306.issue23590@psf.upfronthosting.co.za>
Message-ID: <1425574349.22.0.68874602747.issue23590@psf.upfronthosting.co.za>


Patrick Miller added the comment:

This is also in the 2.7.x branch.  Same patch.

----------

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

From report at bugs.python.org  Thu Mar  5 18:01:45 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 05 Mar 2015 17:01:45 +0000
Subject: [issue22255] Multiprocessing freeze_support raises RuntimeError
In-Reply-To: <1408754338.93.0.431000117242.issue22255@psf.upfronthosting.co.za>
Message-ID: <1425574905.83.0.524205067258.issue22255@psf.upfronthosting.co.za>


Davin Potts added the comment:

Updates to both cx-freeze and multiprocessing in the meantime may likely have addressed this since this issue was first reported.  Granted, diagnosing issues with cx-freeze are best directed to the cx-freeze project -- that is perhaps where this issue should be opened instead.

Can this issue still be reproduced?  If so, a short example would be much appreciated.

----------
nosy: +davin
status: open -> pending
type: crash -> behavior

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

From report at bugs.python.org  Thu Mar  5 18:25:19 2015
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 05 Mar 2015 17:25:19 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1425576319.79.0.529412940249.issue22906@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Thanks, Neil, for catching that.

I did run the entire test suite with the patch, and nothing new broke, so it would seem the patch is at least benign.  :)

----------
nosy: +ethan.furman

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

From report at bugs.python.org  Thu Mar  5 18:25:40 2015
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 05 Mar 2015 17:25:40 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1425576340.97.0.148569681449.issue22906@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Oh, and my tests ran on Ubuntu 13.04 (GNU/Linux 3.8.0-22-generic x86_64).

----------

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

From report at bugs.python.org  Thu Mar  5 18:49:23 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 05 Mar 2015 17:49:23 +0000
Subject: [issue20147] multiprocessing.Queue.get() raises queue.Empty exception
 if even if an item is available
In-Reply-To: <1389022210.55.0.898891193549.issue20147@psf.upfronthosting.co.za>
Message-ID: <1425577763.53.0.674919111972.issue20147@psf.upfronthosting.co.za>


Davin Potts added the comment:

This same issue came up recently in issue23582.  Really, it should have been addressed in this issue here first and issue23582 marked as a duplicate of this one but these things don't always happen in a synchronous or apparently-linear fashion.

Adding to what is captured in issue23582, specifically referring to the points raised here in this issue:
1. A call to put does not mean that the data put on the queue is instantly/atomically available for retrieval via get.  Situations where a call to put is immediately followed by a non-blocking call to get are asking for a race-condition -- this is a principal reason for having blocking calls with timeouts.
2. A call to get resulting in an Empty exception of course does not mean that the queue is forevermore empty, only that the queue is empty at the moment the call to get was made -- the facility for trapping the Empty and trying again to get more data off the queue provides welcome flexibility on top of the use of blocking/non-blocking calls with/without timeouts.
3. A call to empty is, as indicated in the documentation, not to be considered reliable because of the semantics in coordinating the queue's state and data between processes/threads.
4. Alexei's contributions to this issue are very nearly identical to what is discussed in issue23582 and are addressed well there.
5. As to using a timeout value too small to be effective (i.e. < 2e-6), really this is one example of the larger concern of choosing an appropriate timeout value.  In the proposed patch, ensuring that a call to self._poll is made no matter what might potentially buy additional time for the data to be synced and made available (admittedly a happy result, but a fragile, inadvertent win) but it does not address the rest of how get, put, and the others work nor will it necessarily solve the issue being raised here.

In Alexei's example, changing the call to get from a non-blocking call to a blocking call with a reasonably small timeout will reliably ensure that everything put on the queue can and will be gotten back by the rest of that code.

In multiprocessing, we have queues to help us make data available to and across processes and threads alike -- we must recognize that coordinating data across distinct processes (especially) takes a non-zero amount of time -- hence we have the tools of blocking as well as non-blocking calls both with or without timeouts to properly implement robust code in these situations.

----------
nosy: +davin
resolution:  -> not a bug
stage:  -> resolved
superseder:  -> multiprocessing.Queue.get is not getting all the items in the queue

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

From report at bugs.python.org  Thu Mar  5 18:53:27 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 05 Mar 2015 17:53:27 +0000
Subject: [issue20147] multiprocessing.Queue.get() raises queue.Empty exception
 if even if an item is available
In-Reply-To: <1389022210.55.0.898891193549.issue20147@psf.upfronthosting.co.za>
Message-ID: <1425578006.99.0.275484039902.issue20147@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


----------
status: open -> closed

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

From report at bugs.python.org  Thu Mar  5 18:57:37 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Thu, 05 Mar 2015 17:57:37 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425578257.07.0.879721309841.issue23496@psf.upfronthosting.co.za>


Ryan Gonzalez added the comment:

So...you didn't make the changes by hand? Could you just post whatever you passed to configure?

----------

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

From report at bugs.python.org  Thu Mar  5 19:03:43 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 05 Mar 2015 18:03:43 +0000
Subject: [issue6461] multiprocessing: freezing apps on Windows
In-Reply-To: <1247292508.31.0.803162103646.issue6461@psf.upfronthosting.co.za>
Message-ID: <1425578623.92.0.448755324964.issue6461@psf.upfronthosting.co.za>


Davin Potts added the comment:

The original issue now appears addressed in the docs (thanks goes to Stuart and Jesse) though it was not explicitly tracked here as a patch file.

The follow-on secondary issue from spongebob (if that is your real name) could not be reproduced by Richard.

This issue should have been marked closed->resolved some time ago.

----------
nosy: +davin
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Thu Mar  5 19:12:45 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 05 Mar 2015 18:12:45 +0000
Subject: [issue3111] multiprocessing ppc Debian/ ia64 Ubuntu compilation error
In-Reply-To: <1213472808.51.0.731079646072.issue3111@psf.upfronthosting.co.za>
Message-ID: <1425579165.43.0.552443033363.issue3111@psf.upfronthosting.co.za>


Davin Potts added the comment:

Doing cleanup:  This was marked as out of date in 2010 but somehow escaped being marked closed.  Closing now.

----------
nosy: +davin
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Mar  5 20:56:55 2015
From: report at bugs.python.org (A. Skrobov)
Date: Thu, 05 Mar 2015 19:56:55 +0000
Subject: [issue23592] SIGSEGV on interpreter shutdown,
 with daemon threads running wild
Message-ID: <1425585415.3.0.819286404467.issue23592@psf.upfronthosting.co.za>


New submission from A. Skrobov:

I'm observing that this line of code:

https://hg.python.org/cpython/file/ec9bffc35cad/Python/ceval.c#l3010

-- causes a SIGSEGV on interpreter shutdown, after running some really convoluted Python code with daemon threads running wild.

At the time of the crash, tstate->frame==NULL, and tstate->curexc_type points to an exceptions.UnboundLocalError

I can reliably reproduce the crash, but unfortunately I cannot provide a standalone reproducer.

I'm speculating that this case is due to some daemon threads carrying on running while their variables are being destroyed from underneath them.


The traceback is probably of little use, but adding it nevertheless:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x4dc15940 (LWP 10317)]
0x00000000004d5c00 in PyEval_EvalFrameEx (f=0xc0da70, throwflag=0) at Python/ceval.c:3010
3010	    if (tstate->frame->f_exc_type != NULL)
(gdb) bt                                       
#0  0x00000000004d5c00 in PyEval_EvalFrameEx (f=0xc0da70, throwflag=0) at Python/ceval.c:3010
#1  0x00000000004d6db2 in PyEval_EvalCodeEx (co=0x2aaaabe1d510, globals=0x2aaaab9c62f0, locals=0x0, args=0x2aaaaf6e9bf8, argcount=2, kws=0x2aaaaf6e9c08, kwcount=0, defs=0x2aaaabe2fb78, defcount=1, closure=0x0)
    at Python/ceval.c:3267
#2  0x00000000004d9ac9 in fast_function (func=0x2aaaabe37648, pp_stack=0x4dc13c90, n=2, na=2, nk=0) at Python/ceval.c:4131
#3  0x00000000004d96d8 in call_function (pp_stack=0x4dc13c90, oparg=1) at Python/ceval.c:4056
#4  0x00000000004d4258 in PyEval_EvalFrameEx (f=0x2aaaaf6e9a60, throwflag=0) at Python/ceval.c:2681
#5  0x00000000004d6db2 in PyEval_EvalCodeEx (co=0x2aaaabe26250, globals=0x2aaaab9c62f0, locals=0x0, args=0x2aaaaac81f48, argcount=2, kws=0x2aaaaac81f58, kwcount=0, defs=0x2aaaabe2fe88, defcount=1, closure=0x0)
    at Python/ceval.c:3267
#6  0x00000000004d9ac9 in fast_function (func=0x2aaaabe39108, pp_stack=0x4dc14230, n=2, na=2, nk=0) at Python/ceval.c:4131
#7  0x00000000004d96d8 in call_function (pp_stack=0x4dc14230, oparg=1) at Python/ceval.c:4056
#8  0x00000000004d4258 in PyEval_EvalFrameEx (f=0x2aaaaac81db8, throwflag=0) at Python/ceval.c:2681
#9  0x00000000004d99af in fast_function (func=0x2aaaaee97840, pp_stack=0x4dc14620, n=1, na=1, nk=0) at Python/ceval.c:4121
#10 0x00000000004d96d8 in call_function (pp_stack=0x4dc14620, oparg=0) at Python/ceval.c:4056
#11 0x00000000004d4258 in PyEval_EvalFrameEx (f=0xc47fe0, throwflag=0) at Python/ceval.c:2681
#12 0x00000000004d99af in fast_function (func=0x2aaaabe396f0, pp_stack=0x4dc14a10, n=1, na=1, nk=0) at Python/ceval.c:4121
#13 0x00000000004d96d8 in call_function (pp_stack=0x4dc14a10, oparg=0) at Python/ceval.c:4056
#14 0x00000000004d4258 in PyEval_EvalFrameEx (f=0x2aaaaf67bdf0, throwflag=0) at Python/ceval.c:2681
#15 0x00000000004d6db2 in PyEval_EvalCodeEx (co=0x2aaaabe26880, globals=0x2aaaab9c62f0, locals=0x0, args=0x2aaaaef75fd8, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3267
#16 0x000000000056346e in function_call (func=0x2aaaabe395a0, arg=0x2aaaaef75fb0, kw=0x0) at Objects/funcobject.c:526
#17 0x000000000042182c in PyObject_Call (func=0x2aaaabe395a0, arg=0x2aaaaef75fb0, kw=0x0) at Objects/abstract.c:2529
#18 0x000000000042c0d0 in instancemethod_call (func=0x2aaaabe395a0, arg=0x2aaaaef75fb0, kw=0x0) at Objects/classobject.c:2602
#19 0x000000000042182c in PyObject_Call (func=0x2aaaaeec5060, arg=0x2aaaaaacf060, kw=0x0) at Objects/abstract.c:2529
#20 0x00000000004d8ceb in PyEval_CallObjectWithKeywords (func=0x2aaaaeec5060, arg=0x2aaaaaacf060, kw=0x0) at Python/ceval.c:3904
#21 0x000000000052358b in t_bootstrap (boot_raw=0x2aaaafab9d78) at ./Modules/threadmodule.c:614
#22 0x000000342f00677d in start_thread () from /lib64/libpthread.so.0
#23 0x000000342e4d49ad in clone () from /lib64/libc.so.6

----------
components: Interpreter Core
messages: 237283
nosy: A. Skrobov
priority: normal
severity: normal
status: open
title: SIGSEGV on interpreter shutdown, with daemon threads running wild
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar  5 21:09:51 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Thu, 05 Mar 2015 20:09:51 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425586191.73.0.163405829789.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

I can...

./configure --prefix=/usr/python --enable-shared --without-ensurepip

...but configure didn't set up pyconfig.h correctly with those options. There are some changes I had to make post-configure to pyconfig.h and others when I initially built python...see this link: https://code.google.com/p/python-for-android/wiki/CrossCompilingPython
specifically the part about manually editing pyconfig.h

----------

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

From report at bugs.python.org  Thu Mar  5 21:33:40 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Thu, 05 Mar 2015 20:33:40 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425587620.51.0.506542823077.issue23496@psf.upfronthosting.co.za>


Ryan Gonzalez added the comment:

Ahh...ok, then please post the changes. I want to burn autotools enough right now; I doubt that redoing those changes would ease my anger. :)

----------

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

From report at bugs.python.org  Thu Mar  5 21:54:53 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Mar 2015 20:54:53 +0000
Subject: [issue23548] TypeError in event loop finalizer, new in Python 3.4.3
In-Reply-To: <1425139981.48.0.523334940185.issue23548@psf.upfronthosting.co.za>
Message-ID: <1425588893.69.0.44481951934.issue23548@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I close the issue as wont fix. I may workaround the bug during Python finalization if more users report this issue.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Thu Mar  5 22:02:38 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 05 Mar 2015 21:02:38 +0000
Subject: [issue23593] Update Windows and OS X installer OpenSSL to 1.0.2
Message-ID: <1425589358.2.0.224433593674.issue23593@psf.upfronthosting.co.za>


New submission from Ned Deily:

Per the discussion in Issue23476, the installers should be updated to use OpenSSL 1.0.2 to solve the shortest trust path issue documented there.

----------
components: Build
messages: 237287
nosy: ned.deily, steve.dower
priority: normal
severity: normal
stage: patch review
status: open
title: Update Windows and OS X installer OpenSSL to 1.0.2
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Mar  5 22:03:50 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 05 Mar 2015 21:03:50 +0000
Subject: [issue23476] SSL cert verify fail for "www.verisign.com"
In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za>
Message-ID: <1425589430.3.0.230628720973.issue23476@psf.upfronthosting.co.za>


Ned Deily added the comment:

Issue23593 opened to request Windows and OS X installer OpenSSL updates to 1.0.2

----------
nosy: +ned.deily

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

From report at bugs.python.org  Thu Mar  5 22:04:33 2015
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 05 Mar 2015 21:04:33 +0000
Subject: [issue23593] Update Windows and OS X installer OpenSSL to 1.0.2
In-Reply-To: <1425589358.2.0.224433593674.issue23593@psf.upfronthosting.co.za>
Message-ID: <1425589473.05.0.246232419098.issue23593@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald at stufft.io>:


----------
nosy: +dstufft

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

From report at bugs.python.org  Thu Mar  5 22:04:43 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 05 Mar 2015 21:04:43 +0000
Subject: [issue23551] IDLE to provide menu options for using PIP
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1425589483.35.0.392987236512.issue23551@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Yes, this would complement your checker patch from last summer.  It would solve the issue of how to tell or help people, especially beginners, install packages to run with the checker.

Idea for the package manager: include an option to duplicate a set of installed packages from one version to another. A recent SO question (paraphrased): "Started with 2.7, installed multiple packages, added 3.4, can't use packages.  HOW???"  Current answer, with easily missed details, something like: "Packages must be installed for each version.  Use PIP to make requirements.txt (sp?) package list from 2.7 and use that to install same to 3.4."  Nicer answer: use option that gets details right.  Perhaps list could be checked for availability in 3.4.  Or displayed in text widget to be edited.

I look forward to your proposal.

----------

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

From report at bugs.python.org  Thu Mar  5 22:05:01 2015
From: report at bugs.python.org (Alex Gaynor)
Date: Thu, 05 Mar 2015 21:05:01 +0000
Subject: [issue23593] Update Windows and OS X installer OpenSSL to 1.0.2
In-Reply-To: <1425589358.2.0.224433593674.issue23593@psf.upfronthosting.co.za>
Message-ID: <1425589501.24.0.639839566161.issue23593@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

+1 on this -- for pyca/cryptography we're also making this leap in our next release.

----------
nosy: +alex

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

From report at bugs.python.org  Thu Mar  5 22:06:47 2015
From: report at bugs.python.org (John Nagle)
Date: Thu, 05 Mar 2015 21:06:47 +0000
Subject: [issue23476] SSL cert verify fail for "www.verisign.com"
In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za>
Message-ID: <1425589607.18.0.930939832952.issue23476@psf.upfronthosting.co.za>


John Nagle added the comment:

Will this be applied to the Python 2.7.9 library as well?

----------

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

From report at bugs.python.org  Thu Mar  5 22:07:31 2015
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 05 Mar 2015 21:07:31 +0000
Subject: [issue23476] SSL cert verify fail for "www.verisign.com"
In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za>
Message-ID: <1425589651.97.0.0168443418095.issue23476@psf.upfronthosting.co.za>


Donald Stufft added the comment:

It was merged to the 2.7 branch, so it'll be released as part of 2.7.10.

----------

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

From report at bugs.python.org  Thu Mar  5 22:18:57 2015
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 05 Mar 2015 21:18:57 +0000
Subject: [issue23593] Update Windows and OS X installer OpenSSL to 1.0.2
In-Reply-To: <1425589358.2.0.224433593674.issue23593@psf.upfronthosting.co.za>
Message-ID: <1425590337.14.0.934431831385.issue23593@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +zach.ware

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

From report at bugs.python.org  Thu Mar  5 23:05:53 2015
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 05 Mar 2015 22:05:53 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1425593153.45.0.38692635807.issue22906@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
stage: patch review -> test needed

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

From report at bugs.python.org  Thu Mar  5 23:09:02 2015
From: report at bugs.python.org (Jeff Zemla)
Date: Thu, 05 Mar 2015 22:09:02 +0000
Subject: [issue23594] Wrong variable name in traceback
Message-ID: <1425593342.12.0.612342465209.issue23594@psf.upfronthosting.co.za>


New submission from Jeff Zemla:

I've found a rather simple bug in the default CPython implementation on Mac OS X 10.9.5

1) Create a new .py file containing:

def a():
    print q

x=5


2) Open Python and run using execfile() then a(). Receive error as expected:

  File "test.py", line 2, in a
    print q
NameError: global name 'q' is not defined

3) Edit file so that "print q" is not "print x", and save.

4) Run a() (Do not use execfile!)

5) Error:

  File "test.py", line 2, in a
    print x
NameError: global name 'q' is not defined

EXPECTED: Traceback should say "print q" NOT "print x". It is reading from the file. Actually, the error in the file has been corrected-- it is the copy of the program in memory that is faulty.


Python 2.7.5 (default, Mar  9 2014, 22:15:05)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin

----------
components: Macintosh
messages: 237293
nosy: Jeff Zemla, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Wrong variable name in traceback
type: compile error
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar  5 23:10:22 2015
From: report at bugs.python.org (Jeff Zemla)
Date: Thu, 05 Mar 2015 22:10:22 +0000
Subject: [issue23594] Wrong variable name in traceback
In-Reply-To: <1425593342.12.0.612342465209.issue23594@psf.upfronthosting.co.za>
Message-ID: <1425593422.29.0.27831385263.issue23594@psf.upfronthosting.co.za>


Jeff Zemla added the comment:

In 3), "not" should be "now"

----------

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

From report at bugs.python.org  Thu Mar  5 23:13:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 Mar 2015 22:13:48 +0000
Subject: [issue23594] Wrong variable name in traceback
In-Reply-To: <1425593342.12.0.612342465209.issue23594@psf.upfronthosting.co.za>
Message-ID: <1425593628.51.0.635653404886.issue23594@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is a duplicate of an existing issue but I don't have time to find the issue.  It's not a trivial problem to fix, though now that the import system is in python it may be possible.

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

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

From report at bugs.python.org  Thu Mar  5 23:15:27 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 05 Mar 2015 22:15:27 +0000
Subject: [issue23594] Wrong variable name in traceback
In-Reply-To: <1425593342.12.0.612342465209.issue23594@psf.upfronthosting.co.za>
Message-ID: <1425593727.06.0.02029867194.issue23594@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

#8087

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

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

From report at bugs.python.org  Thu Mar  5 23:20:12 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 05 Mar 2015 22:20:12 +0000
Subject: [issue8087] Unupdated source file in traceback
In-Reply-To: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>
Message-ID: <1425594012.72.0.470114324771.issue8087@psf.upfronthosting.co.za>


Robert Collins added the comment:

Storing a marker in module objects which can be used to validate the linecache is a good idea. timestamp isn't appropriate because of modules loaded from zips or dynamic generation. I'd suggest we make it something opaque - we get source code by asking the loader for it anyway - if we make all source code loading go through the loader, then file based loaders can use a timestamp, zip based ones can shortcircuit or use a reference to the containing zip's file metadata or whatever.

----------
nosy: +rbcollins

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

From report at bugs.python.org  Thu Mar  5 23:30:08 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 05 Mar 2015 22:30:08 +0000
Subject: [issue23594] Wrong variable name in traceback
In-Reply-To: <1425593342.12.0.612342465209.issue23594@psf.upfronthosting.co.za>
Message-ID: <1425594608.87.0.271355828284.issue23594@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Unupdated source file in traceback

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

From report at bugs.python.org  Thu Mar  5 23:39:29 2015
From: report at bugs.python.org (Robert Collins)
Date: Thu, 05 Mar 2015 22:39:29 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1425595169.42.0.998362168338.issue22936@psf.upfronthosting.co.za>


Robert Collins added the comment:

No worries. BTW there is one more patch needed to close this issue - adding the feature to unittest. I'm working that up now.

----------

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

From report at bugs.python.org  Thu Mar  5 23:44:23 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 05 Mar 2015 22:44:23 +0000
Subject: [issue4896] Faster why variable manipulation in ceval.c
In-Reply-To: <18791.24525.745699.580609@montanaro.dyndns.org>
Message-ID: <1425595463.58.0.19017171084.issue4896@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Where do we find "Antoine's suite of benchmarks"?

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Thu Mar  5 23:57:31 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Mar 2015 22:57:31 +0000
Subject: [issue23595] Split the math module into _math (C) + math (py)
Message-ID: <1425596251.36.0.618519082533.issue23595@psf.upfronthosting.co.za>


New submission from STINNER Victor:

To implement the PEP 485 (math.isclose), I proposed to split the math module into two parts: _math (C) and math (py). The current C module is renamed to _math and a new "math" module implementd in Python is added. The math module contains "from _math import *".

Attached patch implements this idea.

math.py contains the Python implementation of the following functions:

- degrees
- fsum
- factorial
- radians

I propose to add these functions to "document" the implementation of these functions, I don't want to use the Python implementation by default.

Maybe _math.degrees() and _math.radians() can be removed, the Python implementation is enough.

I'm not sure that the C implementation of factorial() is much faster, since most part of the C code calls Python functions (boxing/unboxing). But it's probably better to keep the C implementation :-)

I don't understand how _factorial_partial_product() decide to divide the computation using the number of bits. Does it make sense to compute the number of bits in Python, since the Python int type has no limit? (only memory)

The C and Python implementations are tested by test_math.

math.py cannot be used alone: it requires floor(), isfinite(), isinf() and isnan() functions of the _math module. The "try: import _math except ImportError: pass" is only useful for unit tests.

TODO: remove SIZEOF_LONG from math.py.

We may rename Module/mathmodule.c to Module/_mathmodule.c, but it's not convinient to generate a patch if a file is renamed.

----------
files: math.patch
keywords: patch
messages: 237300
nosy: haypo, mark.dickinson
priority: normal
severity: normal
status: open
title: Split the math module into _math (C) + math (py)
versions: Python 3.5
Added file: http://bugs.python.org/file38345/math.patch

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

From report at bugs.python.org  Thu Mar  5 23:59:07 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Mar 2015 22:59:07 +0000
Subject: [issue23595] Split the math module into _math (C) + math (py)
In-Reply-To: <1425596251.36.0.618519082533.issue23595@psf.upfronthosting.co.za>
Message-ID: <1425596347.33.0.989564348322.issue23595@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I didn't benchmark the overhead of the patch on "import math" (Python startup time)

----------

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

From report at bugs.python.org  Fri Mar  6 00:03:44 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Mar 2015 23:03:44 +0000
Subject: [issue23595] Split the math module into _math (C) + math (py)
In-Reply-To: <1425596251.36.0.618519082533.issue23595@psf.upfronthosting.co.za>
Message-ID: <1425596624.14.0.240469819987.issue23595@psf.upfronthosting.co.za>


STINNER Victor added the comment:

We may add tests on fsum() with nan:

assert fsum([nan, nan, nan]) == nan
assert fsum([nan, 1.0, inf]) == nan
assert fsum([nan, 1.0, -inf]) == nan

----------

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

From report at bugs.python.org  Fri Mar  6 00:05:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Mar 2015 23:05:15 +0000
Subject: [issue4896] Faster why variable manipulation in ceval.c
In-Reply-To: <1425595463.58.0.19017171084.issue4896@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa-rBh2-1WHoimNWUMi8-9v_-Um5YqmVXX2s3tKk8-RcA@mail.gmail.com>


STINNER Victor added the comment:

> Where do we find "Antoine's suite of benchmarks"?

https://hg.python.org/benchmarks

----------

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

From report at bugs.python.org  Fri Mar  6 00:05:54 2015
From: report at bugs.python.org (Paul Moore)
Date: Thu, 05 Mar 2015 23:05:54 +0000
Subject: [issue23491] PEP 441 - Improving Python Zip Application Support
In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za>
Message-ID: <1425596754.09.0.400510539676.issue23491@psf.upfronthosting.co.za>


Paul Moore added the comment:

There have been no further comments for a while now. Could this be committed by someone?

----------

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

From report at bugs.python.org  Fri Mar  6 00:06:08 2015
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 05 Mar 2015 23:06:08 +0000
Subject: [issue23595] Split the math module into _math (C) + math (py)
In-Reply-To: <1425596251.36.0.618519082533.issue23595@psf.upfronthosting.co.za>
Message-ID: <1425596768.89.0.860574689978.issue23595@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I have no problem with having Python versions, but we should not remove anything from the C implementation -- at a minimum they should be good for testing against.

----------
nosy: +ethan.furman

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

From report at bugs.python.org  Fri Mar  6 00:08:23 2015
From: report at bugs.python.org (Isaac Schwabacher)
Date: Thu, 05 Mar 2015 23:08:23 +0000
Subject: [issue21483] Skip os.utime() test on NFS?
In-Reply-To: <CANc-5Uwwdg6YrkjAf6CsUaSj35OjpEmyru3vtSAz4QMMo7E8Dw@mail.gmail.com>
Message-ID: <1425596903.45.0.217106490939.issue21483@psf.upfronthosting.co.za>


Isaac Schwabacher added the comment:

...and fixed a spot where git diff + copy/paste truncated a long line.  /sheepish

----------
Added file: http://bugs.python.org/file38346/test_import.patch

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

From report at bugs.python.org  Fri Mar  6 00:10:20 2015
From: report at bugs.python.org (Isaac Schwabacher)
Date: Thu, 05 Mar 2015 23:10:20 +0000
Subject: [issue20876] python -m test test_pathlib fails
In-Reply-To: <1394395116.03.0.645933571525.issue20876@psf.upfronthosting.co.za>
Message-ID: <1425597020.67.0.531884135335.issue20876@psf.upfronthosting.co.za>


Isaac Schwabacher added the comment:

Fixed a truncated line in the patch.

----------
Added file: http://bugs.python.org/file38347/test_support.patch

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

From report at bugs.python.org  Fri Mar  6 01:02:50 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 06 Mar 2015 00:02:50 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1425600170.42.0.674362668192.issue22936@psf.upfronthosting.co.za>


Robert Collins added the comment:

And the unittest patch.

----------
Added file: http://bugs.python.org/file38348/issue-22936-5.patch

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

From report at bugs.python.org  Fri Mar  6 01:18:28 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 06 Mar 2015 00:18:28 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1425601108.02.0.818017218522.issue22936@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


Removed file: http://bugs.python.org/file38348/issue-22936-5.patch

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

From report at bugs.python.org  Fri Mar  6 01:18:58 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 06 Mar 2015 00:18:58 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1425601138.57.0.133188015574.issue22936@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


Added file: http://bugs.python.org/file38349/issue-22936-5.patch

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

From report at bugs.python.org  Fri Mar  6 01:22:29 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 06 Mar 2015 00:22:29 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
 "chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1425601349.8.0.113508033805.issue12319@psf.upfronthosting.co.za>


Demian Brecht added the comment:

I've attached a patch that implements full Transfer-Encoding support for requests as specified in RFC 7230.

----------

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

From report at bugs.python.org  Fri Mar  6 01:23:41 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Mar 2015 00:23:41 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1425601421.21.0.334043678822.issue22936@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

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

From report at bugs.python.org  Fri Mar  6 01:26:43 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 06 Mar 2015 00:26:43 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425601603.84.0.604783781575.issue23524@psf.upfronthosting.co.za>


Steve Dower added the comment:

Added a patch that disables the invalid parameter handler in new_threadstate() so that all Python threads are protected from termination.

_PyVerify_fd is still moved into fileutils.c, but _Py_BEGIN/END_SUPPRESS_IPH and _Py_VERIFY_FD are gone. For VC14, _PyVerify_fd simply calls _get_osfhandle and checks the result.

As it's a hack, I haven't updated any documentation to draw attention to this, but I hope this is simpler enough that we can get Windows builds going again.

----------
Added file: http://bugs.python.org/file38350/23524_hack.patch

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

From report at bugs.python.org  Fri Mar  6 01:27:16 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Mar 2015 00:27:16 +0000
Subject: [issue23592] SIGSEGV on interpreter shutdown,
 with daemon threads running wild
In-Reply-To: <1425585415.3.0.819286404467.issue23592@psf.upfronthosting.co.za>
Message-ID: <1425601636.75.0.686572920866.issue23592@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Yes, daemon threads are really dangerous because they may keep running while the interpreter has started releasing critical resources. Things have improved in 3.x compared to 2.x, though.

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

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

From report at bugs.python.org  Fri Mar  6 01:34:08 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 06 Mar 2015 00:34:08 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
 "chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1425602048.3.0.685816069334.issue12319@psf.upfronthosting.co.za>


Demian Brecht added the comment:

I hit "submit" a little too soon.

The intention of the patch is to adhere to all aspects of Transfer-Encoding as specified in the RFC and to make best guesses as to encoding that should be used based on the data type of the given body.

This will break backwards compatibility for cases where users are manually chunking the request bodies prior to passing them in and explicitly setting the Transfer-Encoding header. Additionally, if Transfer-Encoding was previously specified, but not chunked, the patch will automatically chunk the body.

Otherwise, the patch should only be additive.

----------
keywords: +needs review, patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file38351/issue12319.patch

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

From report at bugs.python.org  Fri Mar  6 01:34:49 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 06 Mar 2015 00:34:49 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
 "chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1425602089.73.0.336503494537.issue12319@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Fri Mar  6 01:37:05 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Mar 2015 00:37:05 +0000
Subject: [issue23590] Potential leak in PyFloat_AsDouble.  Refcount error.
In-Reply-To: <1425568095.39.0.812034754306.issue23590@psf.upfronthosting.co.za>
Message-ID: <1425602225.0.0.405969094385.issue23590@psf.upfronthosting.co.za>


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


----------
stage:  -> patch review
type: behavior -> resource usage
versions: +Python 2.7, Python 3.5

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

From report at bugs.python.org  Fri Mar  6 01:37:14 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 06 Mar 2015 00:37:14 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
 "chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1425602234.24.0.679233526603.issue12319@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Also note that this patch includes the changes in #23350 as it's directly relevant.

----------

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

From report at bugs.python.org  Fri Mar  6 01:39:54 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 06 Mar 2015 00:39:54 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
 "chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1425602394.18.0.315098887161.issue12319@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


Added file: http://bugs.python.org/file38352/issue12319_1.patch

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

From report at bugs.python.org  Fri Mar  6 01:46:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Mar 2015 00:46:55 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <20150306004645.19083.75233@psf.io>


Roundup Robot added the comment:

New changeset b4a26b28f5b3 by Robert Collins in branch 'default':
Issue #22936: Allow showing local variables in unittest errors.
https://hg.python.org/cpython/rev/b4a26b28f5b3

----------

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

From report at bugs.python.org  Fri Mar  6 01:54:31 2015
From: report at bugs.python.org (Antony Lee)
Date: Fri, 06 Mar 2015 00:54:31 +0000
Subject: [issue23596] gzip argparse interface
Message-ID: <1425603271.14.0.91808493248.issue23596@psf.upfronthosting.co.za>


New submission from Antony Lee:

The attached patch reimplements gzip's already existing command-line interface using argparse, both to provide command-line help and to avoid manual argument parsing.

----------
components: Library (Lib)
files: gzip-argparse-cli.patch
keywords: patch
messages: 237315
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: gzip argparse interface
versions: Python 3.5
Added file: http://bugs.python.org/file38353/gzip-argparse-cli.patch

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

From report at bugs.python.org  Fri Mar  6 02:18:41 2015
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 06 Mar 2015 01:18:41 +0000
Subject: [issue23591] Add IntFlags
In-Reply-To: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za>
Message-ID: <1425604721.84.0.31815788078.issue23591@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee:  -> ethan.furman

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

From report at bugs.python.org  Fri Mar  6 02:37:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Mar 2015 01:37:42 +0000
Subject: [issue23594] Wrong variable name in traceback
In-Reply-To: <1425593342.12.0.612342465209.issue23594@psf.upfronthosting.co.za>
Message-ID: <20150306013732.19093.66578@psf.io>


Roundup Robot added the comment:

New changeset 62c3742eb25f by Ned Deily in branch '2.7':
Issue #23594: Update OS X 10.5 installer build to use OpenSSL 1.0.2.
https://hg.python.org/cpython/rev/62c3742eb25f

New changeset b2f3a44dbe1b by Ned Deily in branch '3.4':
Issue #23594: Update OS X 10.5 installer build to use OpenSSL 1.0.2.
https://hg.python.org/cpython/rev/b2f3a44dbe1b

New changeset 73aa2f168c5a by Ned Deily in branch 'default':
Issue #23594: merge 3.4
https://hg.python.org/cpython/rev/73aa2f168c5a

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Mar  6 02:38:22 2015
From: report at bugs.python.org (Ned Deily)
Date: Fri, 06 Mar 2015 01:38:22 +0000
Subject: [issue23594] Wrong variable name in traceback
In-Reply-To: <1425593342.12.0.612342465209.issue23594@psf.upfronthosting.co.za>
Message-ID: <1425605902.14.0.405405380068.issue23594@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
Removed message: http://bugs.python.org/msg237316

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

From report at bugs.python.org  Fri Mar  6 02:41:11 2015
From: report at bugs.python.org (Ned Deily)
Date: Fri, 06 Mar 2015 01:41:11 +0000
Subject: [issue23593] Update Windows and OS X installer OpenSSL to 1.0.2
In-Reply-To: <1425589358.2.0.224433593674.issue23593@psf.upfronthosting.co.za>
Message-ID: <1425606071.6.0.764087419222.issue23593@psf.upfronthosting.co.za>


Ned Deily added the comment:

[Sorry, incorrect issue number in the commit messages!]

New changeset 62c3742eb25f by Ned Deily in branch '2.7':
Issue #23594: Update OS X 10.5 installer build to use OpenSSL 1.0.2.
https://hg.python.org/cpython/rev/62c3742eb25f

New changeset b2f3a44dbe1b by Ned Deily in branch '3.4':
Issue #23594: Update OS X 10.5 installer build to use OpenSSL 1.0.2.
https://hg.python.org/cpython/rev/b2f3a44dbe1b

New changeset 73aa2f168c5a by Ned Deily in branch 'default':
Issue #23594: merge 3.4
https://hg.python.org/cpython/rev/73aa2f168c5a

----------

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

From report at bugs.python.org  Fri Mar  6 02:45:48 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Mar 2015 01:45:48 +0000
Subject: [issue23593] Update Windows and OS X installer OpenSSL to 1.0.2
In-Reply-To: <1425589358.2.0.224433593674.issue23593@psf.upfronthosting.co.za>
Message-ID: <20150306014542.1785.40219@psf.io>


Roundup Robot added the comment:

New changeset e74e2ce81a1c by Ned Deily in branch '2.7':
Issue #23593: fix Misc/NEWS entries
https://hg.python.org/cpython/rev/e74e2ce81a1c

New changeset da3fe5fda078 by Ned Deily in branch '3.4':
Issue #23593: fix Misc/NEWS entries
https://hg.python.org/cpython/rev/da3fe5fda078

New changeset 8ef4f75a8018 by Ned Deily in branch 'default':
Issue #23593: fix Misc/NEWS entries
https://hg.python.org/cpython/rev/8ef4f75a8018

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Mar  6 03:12:46 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 06 Mar 2015 02:12:46 +0000
Subject: [issue23597] Allow easy display of local variables in log messages?
Message-ID: <1425607966.26.0.932937253201.issue23597@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Issue #22936 added support for easily displaying local variables in tracebacks to the unittest and traceback modules.

Would it be worth also making this capability readily available in the logging APIs that display traceback messages?

The main argument against it is that automatically logging local variables in tracebacks is a *really* good way to introduce sensitive information leaks into your log messages. "Safe repr" type objects (which automatically mask sensitive details in __repr__()) can mitigate this, but we don't provide such an object in the standard library (not even for bytes, bytearray or str, which are the typical containers for potentially sensitive data like passwords).

----------
messages: 237319
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Allow easy display of local variables in log messages?
versions: Python 3.5

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

From report at bugs.python.org  Fri Mar  6 03:13:00 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 06 Mar 2015 02:13:00 +0000
Subject: [issue23597] Allow easy display of local variables in log messages?
In-Reply-To: <1425607966.26.0.932937253201.issue23597@psf.upfronthosting.co.za>
Message-ID: <1425607980.14.0.289073744569.issue23597@psf.upfronthosting.co.za>


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


----------
dependencies: +traceback module has no way to show locals

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

From report at bugs.python.org  Fri Mar  6 03:15:06 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 06 Mar 2015 02:15:06 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1425608106.14.0.457221728941.issue22936@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I just filed issue #23597 as a potential further follow-up to this, which would be to also add support for displaying local variables directly to the logging module.

However, that has some additional security implications, so I'm entirely convinced it's a good idea yet. See the new RFE for more details.

----------
dependencies: +traceback: add a new thin class storing a traceback without storing local variables

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

From report at bugs.python.org  Fri Mar  6 03:21:05 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 06 Mar 2015 02:21:05 +0000
Subject: [issue20548] Use specific asserts in warnings and exceptions tests
In-Reply-To: <1391804772.02.0.729156315156.issue20548@psf.upfronthosting.co.za>
Message-ID: <1425608465.07.0.499143584628.issue20548@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

LGTM.

----------
nosy: +BreamoreBoy

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

From report at bugs.python.org  Fri Mar  6 03:22:24 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 06 Mar 2015 02:22:24 +0000
Subject: [issue23596] gzip argparse interface
In-Reply-To: <1425603271.14.0.91808493248.issue23596@psf.upfronthosting.co.za>
Message-ID: <1425608544.15.0.869269570348.issue23596@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, but we need to add tests for the current CLI to make sure that we don't break anything when we apply gzip-argparse-cli.patch. See Lib/test/test_tarfile.py and Lib/test/test_calendar.py for example CLI tests.

----------
nosy: +berker.peksag
stage:  -> patch review
type:  -> enhancement

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

From report at bugs.python.org  Fri Mar  6 03:27:44 2015
From: report at bugs.python.org (Robert Collins)
Date: Fri, 06 Mar 2015 02:27:44 +0000
Subject: [issue23597] Allow easy display of local variables in log messages?
In-Reply-To: <1425607966.26.0.932937253201.issue23597@psf.upfronthosting.co.za>
Message-ID: <1425608864.64.0.741095005066.issue23597@psf.upfronthosting.co.za>


Robert Collins added the comment:

Yes, for debugging etc this can be very useful. I suggest further extending the new traceback interface to allow a filtering/transform hook of some sort, to allow folk more granular control than just repr overloading.

----------
nosy: +rbcollins

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

From report at bugs.python.org  Fri Mar  6 03:28:49 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 06 Mar 2015 02:28:49 +0000
Subject: [issue20556] Use specific asserts in threading tests
In-Reply-To: <1391808878.85.0.661174932104.issue20556@psf.upfronthosting.co.za>
Message-ID: <1425608929.69.0.794677326002.issue20556@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Cut and paste error?

         if verbose:
@@ -110,17 +110,17 @@
         for t in threads:
             t.join()
             self.assertTrue(not t.is_alive())
+            self.assertFalse(t.is_alive())

----------
nosy: +BreamoreBoy

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

From report at bugs.python.org  Fri Mar  6 03:33:25 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 06 Mar 2015 02:33:25 +0000
Subject: [issue20557] Use specific asserts in io tests
In-Reply-To: <1391808897.1.0.851007465151.issue20557@psf.upfronthosting.co.za>
Message-ID: <1425609205.57.0.755801024266.issue20557@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

LGTM.

----------
nosy: +BreamoreBoy

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

From report at bugs.python.org  Fri Mar  6 03:36:34 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 06 Mar 2015 02:36:34 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1425609393.99.0.947775036192.issue22936@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

msg237320 "...so I'm *NOT* entirely convinced..."? :)

----------
nosy: +BreamoreBoy

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

From report at bugs.python.org  Fri Mar  6 05:08:04 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 06 Mar 2015 04:08:04 +0000
Subject: [issue23595] Split the math module into _math (C) + math (py)
In-Reply-To: <1425596251.36.0.618519082533.issue23595@psf.upfronthosting.co.za>
Message-ID: <1425614884.19.0.9280356215.issue23595@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Didn't Guido veto the idea of math.py?

In my opinion, isclose() is way too simple to justify refactoring.

If math.py is ever deemed to be a good idea, it should be vetted and implemented on its own merits on not use PEP 485 as a backdoor.

----------
nosy: +belopolsky, gvanrossum

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

From report at bugs.python.org  Fri Mar  6 05:29:25 2015
From: report at bugs.python.org (Paul Bryan)
Date: Fri, 06 Mar 2015 04:29:25 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1425616165.8.0.876890962167.issue15873@psf.upfronthosting.co.za>


Changes by Paul Bryan <pbryan at anode.ca>:


----------
nosy: +pbryan

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

From report at bugs.python.org  Fri Mar  6 05:53:49 2015
From: report at bugs.python.org (Ben Hoyt)
Date: Fri, 06 Mar 2015 04:53:49 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <1425617629.66.0.0616508081822.issue22524@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

Updated version of the patch after Victor's code review of scandir-7 and a couple of his comments offline. Full commit log is available on my GitHub project in posixmodule_scandir_main.c if anyone's interested. Again, I haven't looked closely at the docs or tests yet, but hopefully the C code is getting pretty close now!

KNOWN ISSUE: There's a reference leak in the POSIX version (found with "python -m test -R 3:2 test_os"). I'm a Windows guy and this is my first serious Python C extension code, so I'm not sure the best way to track this down. Would someone like to either point out the bug :-) or help me with how to track this down?

----------

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

From report at bugs.python.org  Fri Mar  6 06:02:30 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 06 Mar 2015 05:02:30 +0000
Subject: [issue23595] Split the math module into _math (C) + math (py)
In-Reply-To: <1425596251.36.0.618519082533.issue23595@psf.upfronthosting.co.za>
Message-ID: <1425618150.89.0.164099774625.issue23595@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I am attaching a quick implementation of math.isclose in C.  It may not cover all corner cases correctly, but that should be easy to fix.

----------
Added file: http://bugs.python.org/file38354/math-isclose.patch

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

From report at bugs.python.org  Fri Mar  6 06:21:08 2015
From: report at bugs.python.org (Neil Girdhar)
Date: Fri, 06 Mar 2015 05:21:08 +0000
Subject: [issue23595] Split the math module into _math (C) + math (py)
In-Reply-To: <1425596251.36.0.618519082533.issue23595@psf.upfronthosting.co.za>
Message-ID: <1425619268.47.0.977927853184.issue23595@psf.upfronthosting.co.za>


Neil Girdhar added the comment:

Nice work Alexander.  I believe what's left is for it to work with complex numbers.

----------
nosy: +neil.g

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

From report at bugs.python.org  Fri Mar  6 07:19:33 2015
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 06 Mar 2015 06:19:33 +0000
Subject: [issue23595] Split the math module into _math (C) + math (py)
In-Reply-To: <1425596251.36.0.618519082533.issue23595@psf.upfronthosting.co.za>
Message-ID: <1425622773.51.0.00725141530761.issue23595@psf.upfronthosting.co.za>


Ethan Furman added the comment:

If there is a complex number version it will live in cmath, not math.

----------

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

From report at bugs.python.org  Fri Mar  6 07:44:36 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 06 Mar 2015 06:44:36 +0000
Subject: [issue23595] Split the math module into _math (C) + math (py)
In-Reply-To: <1425596251.36.0.618519082533.issue23595@psf.upfronthosting.co.za>
Message-ID: <1425624276.38.0.31624612953.issue23595@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
stage:  -> patch review
type:  -> enhancement

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

From report at bugs.python.org  Fri Mar  6 07:52:48 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Mar 2015 06:52:48 +0000
Subject: [issue23595] Split the math module into _math (C) + math (py)
In-Reply-To: <1425624276.42.0.658124206948.issue23595@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwY3kGqpfehXwBBr1_-+2tMjbem1-zhYqP6CeAZLuPqEmQ@mail.gmail.com>


STINNER Victor added the comment:

@Alex: you should open a new issue for isclose.

----------

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

From report at bugs.python.org  Fri Mar  6 09:22:24 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Mar 2015 08:22:24 +0000
Subject: [issue23595] Split the math module into _math (C) + math (py)
In-Reply-To: <1425596251.36.0.618519082533.issue23595@psf.upfronthosting.co.za>
Message-ID: <1425630144.16.0.015190620578.issue23595@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> I'm not sure that the C implementation of factorial() is much faster

The inner loop (see the for loop in factorial_partial_product) operates on C unsigned longs, so I'd be surprised if a Python implementation were competitive.  But it would be interesting to see timings.

----------

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

From report at bugs.python.org  Fri Mar  6 09:34:27 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Mar 2015 08:34:27 +0000
Subject: [issue23595] Split the math module into _math (C) + math (py)
In-Reply-To: <1425596251.36.0.618519082533.issue23595@psf.upfronthosting.co.za>
Message-ID: <1425630867.35.0.986031070304.issue23595@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Didn't Guido veto the idea of math.py?

It looks like it: https://mail.python.org/pipermail/python-dev/2015-March/138616.html

----------

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

From report at bugs.python.org  Fri Mar  6 09:40:58 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Mar 2015 08:40:58 +0000
Subject: [issue23590] Potential leak in PyFloat_AsDouble.  Refcount error.
In-Reply-To: <1425568095.39.0.812034754306.issue23590@psf.upfronthosting.co.za>
Message-ID: <1425631258.94.0.246413600843.issue23590@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Patch LGTM.  Marking as high priority.

----------
nosy: +mark.dickinson
priority: normal -> high

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

From report at bugs.python.org  Fri Mar  6 09:43:34 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 08:43:34 +0000
Subject: [issue23595] Split the math module into _math (C) + math (py)
In-Reply-To: <1425596251.36.0.618519082533.issue23595@psf.upfronthosting.co.za>
Message-ID: <1425631414.25.0.110776583412.issue23595@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I experimented with different Python implementations of factorial() in 2.5/2.6. But then came 2.7 with C implementation, and it beat them all. Python is not the best language to implement low-level computational algorithms.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Fri Mar  6 09:48:10 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Mar 2015 08:48:10 +0000
Subject: [issue23590] Potential leak in PyFloat_AsDouble.  Refcount error.
In-Reply-To: <1425568095.39.0.812034754306.issue23590@psf.upfronthosting.co.za>
Message-ID: <1425631690.82.0.602489814801.issue23590@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee:  -> mark.dickinson

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

From report at bugs.python.org  Fri Mar  6 09:55:29 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Mar 2015 08:55:29 +0000
Subject: [issue23590] Potential leak in PyFloat_AsDouble.  Refcount error.
In-Reply-To: <1425568095.39.0.812034754306.issue23590@psf.upfronthosting.co.za>
Message-ID: <1425632129.13.0.747435894791.issue23590@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

The patch should have a test before it goes in.  As an aside, it's a bit disturbing that we apparently don't have any code already in our test-suite that exercises this case.

----------

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

From report at bugs.python.org  Fri Mar  6 10:59:37 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 09:59:37 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <1425635977.91.0.156516214392.issue15443@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be instead of adding new method datetime.fromnanoseconds() make datetime.fromtimestamp() to support Decimal (and other high-precision numerical types)?

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Fri Mar  6 11:18:14 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Mar 2015 10:18:14 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <20150306101733.1801.4611@psf.io>


Roundup Robot added the comment:

New changeset 648b35f22b91 by Berker Peksag in branch 'default':
Issue #17911: Tweak traceback documentation.
https://hg.python.org/cpython/rev/648b35f22b91

----------

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

From report at bugs.python.org  Fri Mar  6 11:27:10 2015
From: report at bugs.python.org (Yongzhi Pan)
Date: Fri, 06 Mar 2015 10:27:10 +0000
Subject: [issue23589] Redundant sentence in FAQ
In-Reply-To: <1425544358.43.0.799956102379.issue23589@psf.upfronthosting.co.za>
Message-ID: <1425637630.93.0.673383326265.issue23589@psf.upfronthosting.co.za>


Yongzhi Pan added the comment:

What about changing the first sentence to:

In Python, variables that are only referenced but not assigned inside a function are implicitly global.?

----------

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

From report at bugs.python.org  Fri Mar  6 11:46:43 2015
From: report at bugs.python.org (Yongzhi Pan)
Date: Fri, 06 Mar 2015 10:46:43 +0000
Subject: [issue23589] Redundant sentence in FAQ
In-Reply-To: <1425544358.43.0.799956102379.issue23589@psf.upfronthosting.co.za>
Message-ID: <1425638803.29.0.978115933227.issue23589@psf.upfronthosting.co.za>


Yongzhi Pan added the comment:

Or:

In Python, variables inside a function that are only referenced but not assigned are implicitly global.?

----------

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

From report at bugs.python.org  Fri Mar  6 12:17:27 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Mar 2015 11:17:27 +0000
Subject: [issue23595] Split the math module into _math (C) + math (py)
In-Reply-To: <1425596251.36.0.618519082533.issue23595@psf.upfronthosting.co.za>
Message-ID: <1425640647.84.0.863013962717.issue23595@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> > Didn't Guido veto the idea of math.py?
> It looks like it: https://mail.python.org/pipermail/python-dev/2015-March/138616.html

Ah. I missed this email.

So what do you think of my patch? Does it make sense to provide math.py?

--

For math.py without _math: isnan(), isfinite(), etc. can be implemented in pure Python using the struct module. See for example the old fpconst module:
https://pypi.python.org/pypi/fpconst

Well, it would be specific to IEEE 754, but most platforms support IEEE 754, and other Python implementations can implement their own _math module to support more platforms (like platforms not supporting IEEE 754 floats).

----------

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

From report at bugs.python.org  Fri Mar  6 12:27:47 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Mar 2015 11:27:47 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425641267.95.0.161599384817.issue23524@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I reviewed 23524_hack.patch.

----------

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

From report at bugs.python.org  Fri Mar  6 12:47:18 2015
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 06 Mar 2015 11:47:18 +0000
Subject: [issue23593] Update Windows and OS X installer OpenSSL to 1.0.2
In-Reply-To: <1425589358.2.0.224433593674.issue23593@psf.upfronthosting.co.za>
Message-ID: <1425642438.4.0.658517035612.issue23593@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes

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

From report at bugs.python.org  Fri Mar  6 12:55:05 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 11:55:05 +0000
Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if
 sem_open is not implemented
In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za>
Message-ID: <1425642905.8.0.814870012679.issue23400@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm not sure that this issue is worth to fix. AttributeError is not worse than ImportError, and users of 3.x expect AttributeError (if expect).

----------
nosy: +brett.cannon, eric.snow, jnoller, ncoghlan, sbt, serhiy.storchaka

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

From report at bugs.python.org  Fri Mar  6 12:56:44 2015
From: report at bugs.python.org (Robert Greener)
Date: Fri, 06 Mar 2015 11:56:44 +0000
Subject: [issue23598] No backspace on curses on iTerm (mac)
Message-ID: <1425643004.82.0.795836967438.issue23598@psf.upfronthosting.co.za>


New submission from Robert Greener:

iTerm uses ^? for backspace which is curses.ascii.DEL, patch, makes curses.ascii.DEL use same behaviour as curses.ascii.BS

----------
files: cursesbackspace.patch
keywords: patch
messages: 237345
nosy: ragreener
priority: normal
severity: normal
status: open
title: No backspace on curses on iTerm (mac)
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file38355/cursesbackspace.patch

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

From report at bugs.python.org  Fri Mar  6 13:09:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 12:09:53 +0000
Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if
 sem_open is not implemented
In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za>
Message-ID: <1425643793.07.0.885817297646.issue23400@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

But if this change is worth, I would write it as

-            maxsize = _multiprocessing.SemLock.SEM_VALUE_MAX
+            # Can raise ImportError (see issues #3770 and #23400)
+            from .synchronize import SEM_VALUE_MAX as maxsize

This would avoid a duplication of the error message.

----------

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

From report at bugs.python.org  Fri Mar  6 13:10:45 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 12:10:45 +0000
Subject: [issue23598] No backspace on curses on iTerm (mac)
In-Reply-To: <1425643004.82.0.795836967438.issue23598@psf.upfronthosting.co.za>
Message-ID: <1425643845.51.0.0130787781027.issue23598@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Extension Modules, Macintosh
nosy: +ned.deily, ronaldoussoren

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

From report at bugs.python.org  Fri Mar  6 13:16:50 2015
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 06 Mar 2015 12:16:50 +0000
Subject: [issue23593] Update Windows and OS X installer OpenSSL to 1.0.2
In-Reply-To: <1425589358.2.0.224433593674.issue23593@psf.upfronthosting.co.za>
Message-ID: <1425644210.54.0.323127118764.issue23593@psf.upfronthosting.co.za>


Christian Heimes added the comment:

http://svn.python.org/projects/external/ and Tools/buildbot/external-common.bat must be updated for Windows, too.

----------

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

From report at bugs.python.org  Fri Mar  6 14:02:01 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Mar 2015 13:02:01 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1425646921.02.0.214495678615.issue23571@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I ran http://hg.python.org/benchmarks/

Result:
---
$ python3 perf.py -r -b default ~/prog/python/default/python.orig  ~/prog/python/default/python.patched 
INFO:root:Automatically selected timer: perf_counter
(...)
Report on Linux smithers 3.18.3-201.fc21.x86_64 #1 SMP Mon Jan 19 15:59:31 UTC 2015 x86_64 x86_64
Total CPU cores: 8

### etree_parse ###
Min: 0.273882 -> 0.297294: 1.09x slower
Avg: 0.277947 -> 0.312787: 1.13x slower
Significant (t=-11.54)
Stddev: 0.00446 -> 0.02987: 6.6906x larger

### fastunpickle ###
Min: 0.510721 -> 0.526520: 1.03x slower
Avg: 0.521282 -> 0.542610: 1.04x slower
Significant (t=-8.33)
Stddev: 0.01024 -> 0.02348: 2.2931x larger

The following not significant results are hidden, use -v to show them:
2to3, django_v2, etree_generate, etree_iterparse, etree_process, fastpickle, json_dump_v2, json_load, nbody, regex_v8, tornado_http.
---

I ran again etree_parse alone and the slowdown disappeared :-p
---
The following not significant results are hidden, use -v to show them:
etree_parse.
---

Output when I ran fastunpickle alone:
---
### fastunpickle ###
Min: 0.510994 -> 0.522419: 1.02x slower
Avg: 0.524633 -> 0.536876: 1.02x slower
Significant (t=-2.69)
Stddev: 0.02983 -> 0.03436: 1.1518x larger
---

2% slower on a single test doesn't look to be significant. Raising a SystemError is more important than the minor slowdown. What do you think?

----------

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

From report at bugs.python.org  Fri Mar  6 14:03:53 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Mar 2015 13:03:53 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1425647033.63.0.323150378495.issue23571@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I ran pybench, even if I know that it's not really revelant: overall 0.3% slowdown. But pybench doesn't look reliable: some tests are faster, which looks like noise in the benchmark.

-------------------------------------------------------------------------------
PYBENCH 2.1
-------------------------------------------------------------------------------
* using CPython 3.5.0a1+ (default:648b35f22b91+, Mar 6 2015, 13:18:57) [GCC 4.9.2 20141101 (Red Hat 4.9.2-1)]
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.perf_counter
* timer: resolution=1e-09, implementation=clock_gettime(CLOCK_MONOTONIC)

-------------------------------------------------------------------------------
Benchmark: orig.pybench
-------------------------------------------------------------------------------

    Rounds: 10
    Warp:   10
    Timer:  time.perf_counter

    Machine Details:
       Platform ID:    Linux-3.18.3-201.fc21.x86_64-x86_64-with-fedora-21-Twenty_One
       Processor:      x86_64
    
    Python:
       Implementation: CPython
       Executable:     /home/haypo/prog/python/default/python.orig
       Version:        3.5.0a1+
       Compiler:       GCC 4.9.2 20141101 (Red Hat 4.9.2-1)
       Bits:           64bit
       Build:          Mar  6 2015 13:19:47 (#default:648b35f22b91)
       Unicode:        UCS4


-------------------------------------------------------------------------------
Comparing with: patch.pybench
-------------------------------------------------------------------------------

    Rounds: 10
    Warp:   10
    Timer:  time.perf_counter

    Machine Details:
       Platform ID:    Linux-3.18.3-201.fc21.x86_64-x86_64-with-fedora-21-Twenty_One
       Processor:      x86_64
    
    Python:
       Implementation: CPython
       Executable:     /home/haypo/prog/python/default/python.patched
       Version:        3.5.0a1+
       Compiler:       GCC 4.9.2 20141101 (Red Hat 4.9.2-1)
       Bits:           64bit
       Build:          Mar  6 2015 13:18:57 (#default:648b35f22b91+)
       Unicode:        UCS4


Test                             minimum run-time        average  run-time
                                 this    other   diff    this    other   diff
-------------------------------------------------------------------------------
          BuiltinFunctionCalls:    41ms    41ms   -1.1%    41ms    41ms   -1.5%
           BuiltinMethodLookup:    24ms    24ms   +0.3%    24ms    25ms   -0.8%
                 CompareFloats:    26ms    26ms   +2.2%    27ms    26ms   +1.2%
         CompareFloatsIntegers:    59ms    60ms   -0.9%    60ms    61ms   -2.5%
               CompareIntegers:    38ms    36ms   +4.6%    38ms    37ms   +3.5%
        CompareInternedStrings:    26ms    25ms   +0.6%    26ms    26ms   -0.5%
                  CompareLongs:    22ms    21ms   +1.1%    22ms    22ms   +0.0%
                CompareStrings:    22ms    23ms   -1.3%    23ms    23ms   -1.3%
    ComplexPythonFunctionCalls:    40ms    40ms   -1.5%    40ms    41ms   -2.5%
                 ConcatStrings:    28ms    28ms   -0.3%    28ms    29ms   -1.2%
               CreateInstances:    41ms    42ms   -1.7%    42ms    43ms   -2.6%
            CreateNewInstances:    31ms    32ms   -2.2%    32ms    33ms   -3.2%
       CreateStringsWithConcat:    59ms    56ms   +5.6%    60ms    58ms   +2.7%
                  DictCreation:    43ms    48ms  -10.3%    44ms    50ms  -12.7%
             DictWithFloatKeys:    36ms    37ms   -4.8%    36ms    38ms   -6.0%
           DictWithIntegerKeys:    28ms    29ms   -4.1%    29ms    31ms   -6.4%
            DictWithStringKeys:    24ms    26ms   -8.9%    24ms    27ms  -10.3%
                      ForLoops:    22ms    22ms   -0.9%    22ms    23ms   -2.2%
                    IfThenElse:    31ms    33ms   -5.9%    31ms    34ms   -7.9%
                   ListSlicing:    35ms    35ms   -0.1%    36ms    36ms   -2.0%
                NestedForLoops:    34ms    35ms   -2.3%    34ms    36ms   -4.7%
      NestedListComprehensions:    37ms    37ms   -1.2%    37ms    40ms   -7.6%
          NormalClassAttribute:    77ms    71ms   +8.1%    77ms    74ms   +3.9%
       NormalInstanceAttribute:    37ms    36ms   +2.1%    38ms    38ms   -0.6%
           PythonFunctionCalls:    35ms    34ms   +1.7%    35ms    35ms   -0.5%
             PythonMethodCalls:    45ms    44ms   +3.3%    46ms    45ms   +0.7%
                     Recursion:    60ms    58ms   +3.7%    60ms    59ms   +1.0%
                  SecondImport:    33ms    33ms   -0.0%    33ms    33ms   -1.9%
           SecondPackageImport:    34ms    34ms   +0.1%    34ms    34ms   -2.0%
         SecondSubmoduleImport:    83ms    86ms   -3.5%    85ms    87ms   -2.4%
       SimpleComplexArithmetic:    23ms    23ms   +0.7%    23ms    24ms   -2.2%
        SimpleDictManipulation:    51ms    53ms   -3.8%    52ms    55ms   -5.7%
         SimpleFloatArithmetic:    24ms    24ms   +0.3%    24ms    25ms   -2.0%
      SimpleIntFloatArithmetic:    31ms    30ms   +1.1%    31ms    31ms   -0.1%
       SimpleIntegerArithmetic:    30ms    30ms   +0.0%    30ms    31ms   -2.0%
      SimpleListComprehensions:    30ms    32ms   -4.6%    31ms    33ms   -5.7%
        SimpleListManipulation:    27ms    26ms   +2.4%    27ms    27ms   +0.4%
          SimpleLongArithmetic:    21ms    21ms   +2.1%    22ms    22ms   +0.2%
                    SmallLists:    36ms    36ms   -1.3%    36ms    37ms   -3.0%
                   SmallTuples:    43ms    43ms   -0.5%    44ms    45ms   -2.5%
         SpecialClassAttribute:    75ms    72ms   +4.3%    75ms    73ms   +2.5%
      SpecialInstanceAttribute:    38ms    41ms   -7.7%    38ms    42ms   -9.0%
                StringMappings:    77ms    76ms   +1.4%    77ms    78ms   -0.3%
              StringPredicates:    43ms    44ms   -2.6%    44ms    45ms   -3.9%
                 StringSlicing:    39ms    38ms   +3.2%    39ms    39ms   +1.0%
                     TryExcept:    21ms    21ms   -2.8%    21ms    22ms   -4.8%
                    TryFinally:    29ms    29ms   +0.2%    29ms    29ms   -1.2%
                TryRaiseExcept:    11ms    11ms   -0.2%    11ms    11ms   -1.1%
                  TupleSlicing:    42ms    43ms   -0.8%    45ms    45ms   +0.5%
                   WithFinally:    45ms    45ms   -0.8%    45ms    45ms   -1.2%
               WithRaiseExcept:    36ms    36ms   -0.9%    36ms    36ms   -1.5%
-------------------------------------------------------------------------------
Totals:                          1920ms  1927ms   -0.3%  1941ms  1980ms   -2.0%

(this=orig.pybench, other=patch.pybench)

----------

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

From report at bugs.python.org  Fri Mar  6 14:08:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Mar 2015 13:08:08 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1425647288.22.0.482400911128.issue23571@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Even worse benchmark: timeit :-)

python -m timeit -s 'def f(): pass' 'f()'

* original: 67.5 nanoseconds
* patched: 64.1 nanoseconds (faster!?)

----------

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

From report at bugs.python.org  Fri Mar  6 14:28:22 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Mar 2015 13:28:22 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1425648502.79.0.0604200109982.issue23571@psf.upfronthosting.co.za>


STINNER Victor added the comment:

New patch which removes some assertions and move other assertions on result/PyErr_Occurred.

I removed useless duplicated assertions and move the final assertion at the end of PyEval_EvalFrameEx() to guarantee that the function behave correctly.

----------
Added file: http://bugs.python.org/file38356/check_result-2.patch

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

From report at bugs.python.org  Fri Mar  6 14:46:52 2015
From: report at bugs.python.org (Mac Ryan)
Date: Fri, 06 Mar 2015 13:46:52 +0000
Subject: [issue21750] mock_open data is visible only once for the life of the
 class
In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za>
Message-ID: <1425649612.96.0.397191831782.issue21750@psf.upfronthosting.co.za>


Mac Ryan added the comment:

I'm a bit lost in the interface of this bugtracker, so I apologise if I am writing in the wrong spot, anyhow...

I just wanted to signal that this bug breaks the inter-operability between mock (external library) and unittest.mock, breaking tests that have been originally written for Python2.

----------
nosy: +quasipedia

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

From report at bugs.python.org  Fri Mar  6 14:48:33 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 06 Mar 2015 13:48:33 +0000
Subject: [issue21750] mock_open data is visible only once for the life of the
 class
In-Reply-To: <1402683289.16.0.550319898466.issue21750@psf.upfronthosting.co.za>
Message-ID: <1425649713.79.0.769210501772.issue21750@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

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

From report at bugs.python.org  Fri Mar  6 14:51:12 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Mar 2015 13:51:12 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1425649872.98.0.938983178171.issue23571@psf.upfronthosting.co.za>


STINNER Victor added the comment:

New patch to take in account Serhiy's comments. I also fixed call_function(), I forgot to call _Py_CheckFunctionResult() in two cases.

----------
Added file: http://bugs.python.org/file38357/check_result-3.patch

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

From report at bugs.python.org  Fri Mar  6 14:53:59 2015
From: report at bugs.python.org (A. Skrobov)
Date: Fri, 06 Mar 2015 13:53:59 +0000
Subject: [issue23592] SIGSEGV on interpreter shutdown,
 with daemon threads running wild
In-Reply-To: <1425585415.3.0.819286404467.issue23592@psf.upfronthosting.co.za>
Message-ID: <1425650039.27.0.996537446997.issue23592@psf.upfronthosting.co.za>


A. Skrobov added the comment:

That's right; and working around this issue, by taming the daemon threads a bit, wasn't too difficult.

Still, if the daemon threads are part of the language, they shouldn't crash the interpreter process, I suppose?

----------

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

From report at bugs.python.org  Fri Mar  6 14:56:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 13:56:15 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1425650175.24.0.0981770821263.issue23571@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm not sure that all removed assertions are not needed. There are many ways to get raised exception, not only by calling a function.

----------

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

From report at bugs.python.org  Fri Mar  6 15:10:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Mar 2015 14:10:04 +0000
Subject: [issue23590] Potential leak in PyFloat_AsDouble.  Refcount error.
In-Reply-To: <1425568095.39.0.812034754306.issue23590@psf.upfronthosting.co.za>
Message-ID: <20150306140950.19097.31553@psf.io>


Roundup Robot added the comment:

New changeset 30925a3b2324 by Benjamin Peterson in branch '3.4':
fix potential refleak in PyFloat_AsDouble (closes #23590)
https://hg.python.org/cpython/rev/30925a3b2324

New changeset f31b91b6683a by Benjamin Peterson in branch '2.7':
fix potential refleak in PyFloat_AsDouble (closes #23590)
https://hg.python.org/cpython/rev/f31b91b6683a

New changeset 4d9594018edd by Benjamin Peterson in branch 'default':
merge 3.4 (#23590)
https://hg.python.org/cpython/rev/4d9594018edd

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Mar  6 15:16:06 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Mar 2015 14:16:06 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1425651366.69.0.580927588963.issue23571@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Updated patch to take in account more Serhiy's comments.

----------
Added file: http://bugs.python.org/file38358/check_result-4.patch

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

From report at bugs.python.org  Fri Mar  6 15:16:58 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 14:16:58 +0000
Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()]
 deadlock
In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za>
Message-ID: <1425651418.45.0.353104488165.issue23051@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld.

----------
nosy: +serhiy.storchaka
stage: commit review -> patch review

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

From report at bugs.python.org  Fri Mar  6 15:22:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 14:22:26 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1425651746.69.0.307380726.issue23571@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please run microbenchmarks from issue23507?

----------

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

From report at bugs.python.org  Fri Mar  6 15:53:11 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Mar 2015 14:53:11 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1425653591.26.0.656481418255.issue23571@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, test_io and test_sqlite are failing in release mode with check_result-4.patch. io and sqlite modules only call PyErr_Clear() in debug mode. It's my fault, I added them, but I made them conditionnal to not impact performances. It's now fixed in the new patch.

Patch 5:

- "./python -m test -j0 -rW" succeeded in debug mode
- "./python -m test -j0 -rW" succeeded in release mode
- pybench: overall 0.6% slower with the patch (on the minimum runtime column)

Micro-benchmarks of issue #23507:

$ ./python -m timeit -s "f = lambda x: x" -s "s = list(range(1000))" -- "list(filter(f, s))"
Unpatched: 10000 loops, best of 3: 96.3 usec per loop
Patched:   10000 loops, best of 3: 99.2 usec per loop (+3.0%)

$ ./python -m timeit -s "f = lambda x: x" -s "s = list(range(1000))" -- "list(map(f, s))"
Unpatched: 10000 loops, best of 3: 89 usec per loop
Patched:   10000 loops, best of 3: 92.3 usec per loop (+3.7%)

$ ./python -m timeit -s "f = lambda x: x" -s "s = list(range(1000))" -- "sorted(s, key=f)"
Unpatched: 10000 loops, best of 3: 104 usec per loop
Patched:   10000 loops, best of 3: 106 usec per loop (+1.9%)

----------
Added file: http://bugs.python.org/file38359/check_result-5.patch

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

From report at bugs.python.org  Fri Mar  6 16:48:47 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 06 Mar 2015 15:48:47 +0000
Subject: [issue23595] Split the math module into _math (C) + math (py)
In-Reply-To: <1425596251.36.0.618519082533.issue23595@psf.upfronthosting.co.za>
Message-ID: <1425656927.36.0.684684258522.issue23595@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I interpret Guido's email as vetoing the skipping of the C implementation of PEP 485, not on outright banning a PEP 399 math.py if someone like Victor wanted to put the work into implementing some things on top of the C code in Python. So as long as everything in the math module has a C equivalent I say implement whatever you want in Python code as long as maintenance won't be a burden.

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Fri Mar  6 16:52:20 2015
From: report at bugs.python.org (Tim Peters)
Date: Fri, 06 Mar 2015 15:52:20 +0000
Subject: [issue23592] SIGSEGV on interpreter shutdown,
 with daemon threads running wild
In-Reply-To: <1425585415.3.0.819286404467.issue23592@psf.upfronthosting.co.za>
Message-ID: <1425657140.23.0.754154007139.issue23592@psf.upfronthosting.co.za>


Tim Peters added the comment:

Nothing should ever crash the interpreter :-)  So this is a thoroughly legitimate bug report.

However, there's no way to guess whether _this_ crasher is easy to fix, or next to impossible.  Without a test program to provoke the error, there's little to go on.  If it were a common problem with daemon threads, I'd expect at least several reports of similar behavior over the decades.  So chances seem to favor that there's something unique about the specifics of what your daemon threads were doing to provoke it - and/or timing quirks specific to your platform.

----------
nosy: +tim.peters

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

From report at bugs.python.org  Fri Mar  6 16:52:20 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 Mar 2015 15:52:20 +0000
Subject: [issue23595] Split the math module into _math (C) + math (py)
In-Reply-To: <1425656927.36.0.684684258522.issue23595@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKBqOeophgfu2XcLvHkpyRJSS9pFU9i_h-sqeHoy_BScg@mail.gmail.com>


Guido van Rossum added the comment:

I think it's pretty silly to have math.py. And why would there be a
pure-Python implementation of factorial() (like anybody is ever going to
use that) instead of example implementations of sin() etc.? Please don't go
down this path for this particular module. Put your code in a recipe or
something.

On Fri, Mar 6, 2015 at 7:48 AM, Brett Cannon <report at bugs.python.org> wrote:

>
> Brett Cannon added the comment:
>
> I interpret Guido's email as vetoing the skipping of the C implementation
> of PEP 485, not on outright banning a PEP 399 math.py if someone like
> Victor wanted to put the work into implementing some things on top of the C
> code in Python. So as long as everything in the math module has a C
> equivalent I say implement whatever you want in Python code as long as
> maintenance won't be a burden.
>
> ----------
> nosy: +brett.cannon
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue23595>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri Mar  6 16:55:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 15:55:53 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1425657353.53.0.191129899035.issue23571@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

We can ignore such little slow down (if this is not just compiler artifact).

The patch LGTM. I afraid there will be issues with third-party code that will need an adaptation to 3.5, but on other hand, this patch could help with catching some hidden bugs.

----------

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

From report at bugs.python.org  Fri Mar  6 17:00:07 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 16:00:07 +0000
Subject: [issue22853] Multiprocessing.Queue._feed deadlocks on import
In-Reply-To: <1415795371.09.0.078459007626.issue22853@psf.upfronthosting.co.za>
Message-ID: <1425657607.64.0.343632033741.issue22853@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Fri Mar  6 17:00:33 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 06 Mar 2015 16:00:33 +0000
Subject: [issue23589] Redundant sentence in FAQ
In-Reply-To: <1425544358.43.0.799956102379.issue23589@psf.upfronthosting.co.za>
Message-ID: <1425657633.83.0.173442231833.issue23589@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Not to throw a wrench into this, but would it perhaps not be worthwhile to refactor this section in order to include nonlocals as well (obviously not for 2.7)? It seems a little odd to me to have this amount of detail without mentioning nonlocal.

----------
nosy: +demian.brecht

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

From report at bugs.python.org  Fri Mar  6 17:05:40 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 06 Mar 2015 16:05:40 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425657940.5.0.0293312348856.issue23524@psf.upfronthosting.co.za>


Steve Dower added the comment:

New patch based on review feedback - main change is to _Py_fstat to use errno on Windows instead of GetLastError().

Where to put the invalid parameter handler is still an open question. Victor is not keen on adding a new file, while I don't really want it to be outside of the PC/ folder. msvcrtmodule.c is next best IMHO, but since this won't be getting a Python API it still seems wrong.

Alternatively, I can rename invalid_parameter_handler.c to something like "PC/crtutils.c" so it stands out as a multi-purpose file?

----------
Added file: http://bugs.python.org/file38360/23524_hack_2.patch

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

From report at bugs.python.org  Fri Mar  6 17:27:00 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 06 Mar 2015 16:27:00 +0000
Subject: [issue23590] Potential leak in PyFloat_AsDouble.  Refcount error.
In-Reply-To: <1425568095.39.0.812034754306.issue23590@psf.upfronthosting.co.za>
Message-ID: <1425659220.76.0.688862366656.issue23590@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Thanks, Benjamin!

----------
assignee: mark.dickinson -> 

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

From report at bugs.python.org  Fri Mar  6 19:03:59 2015
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 06 Mar 2015 18:03:59 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425665039.4.0.963490387198.issue23524@psf.upfronthosting.co.za>


Larry Hastings added the comment:

FWIW I'm tagging alpha 2 somewhere around 24-36 hours from now.

----------

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

From report at bugs.python.org  Fri Mar  6 19:29:59 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 06 Mar 2015 18:29:59 +0000
Subject: [issue20271] urllib.parse.urlparse() accepts wrong URLs
In-Reply-To: <1389789129.93.0.775761654638.issue20271@psf.upfronthosting.co.za>
Message-ID: <1425666599.13.0.172069968322.issue20271@psf.upfronthosting.co.za>


Demian Brecht added the comment:

I think some further consideration around this change is worthwhile:

Currently, urllib.parse.split* methods seem to do inconsistent validation around the data they're splitting. For example:

(None for an invalid port)
>>> parse.splitnport('example.com:foo')
('example.com', None)

Whereas other split* methods do not:

(Auth part should be URL-encoded)
>>> parse.splituser('u at ser:p at ssword@example.com:80')
('u at ser:p at ssword', 'example.com:80')

And others are just plain incorrect:

(:bad should be the port as defined by the ABNF 'authority = [ userinfo "@" ] host [ ":" port ]')
>>> parse.splitport('example.com:bad')
('example.com:bad', None)

However, none of these cases (currently) raise exceptions.

Looking at urllib.parse, two large motivations behind it are splitting and parsing. In my mind, splitting should solely be responsible for splitting input based on RFC-defined delimiters. Parsing on the other hand, should be responsible for both splitting as necessary as well as input validation. It may also make sense to add simple validation functions to the module to comply with the "batteries included" philosophy, but that's a topic for another issue.

My concern with the proposed patch is that it adds further inconsistency to split* methods:

Before patch:

>>> parse.urlsplit('http://[::1]spam:80')
SplitResult(scheme='http', netloc='[::1]spam:80', path='', query='', fragment='')

After patch:

>>> parse.urlsplit('http://[::1]spam:80')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Volumes/src/p/cpython/Lib/urllib/parse.py", line 350, in urlsplit
    netloc, url = _splitnetloc(url, 2)
  File "/Volumes/src/p/cpython/Lib/urllib/parse.py", line 324, in _splitnetloc
    raise ValueError('Invalid IPv6 URL')

(While the above examples still yield the same results and don't raise exceptions)

I do think that the validation should be done and I agree that an exception should be raised, but it should be done at the urlparse level, not on split (in this case, due to the change to _splitnecloc).

----------
nosy: +demian.brecht

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

From report at bugs.python.org  Fri Mar  6 19:48:57 2015
From: report at bugs.python.org (Davin Potts)
Date: Fri, 06 Mar 2015 18:48:57 +0000
Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if
 sem_open is not implemented
In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za>
Message-ID: <1425667737.34.0.699803488294.issue23400@psf.upfronthosting.co.za>


Davin Potts added the comment:

Please keep in mind that this issue should only be encountered by people using Python 3.x on a platform like Hurd (an unsupported platform) that has no working sem_open implementation.  If we try to imagine what Python 3.x users should expect, it's that they should see consistent behavior when importing or trying to use various pieces of multiprocessing on such an incomplete system.  Or we should imagine Python 2.x users attempting to adopt Python 3.x and choosing to do so on such an incomplete system -- again, consistency is to be expected or at least desperately wished for.  It is reasonable to believe that it is the exception that people like Ole have even seen this behavior and their reaction is that of a request for consistency.  This is worth fixing.


Adding the "from .synchronize import SEM_VALUE_MAX as maxsize" as was suggested would indeed trigger the ImportError but it would also trigger this ImportError immediately upon simply doing an "import multiprocessing" which is not the current behavior on systems like Hurd.  This would effectively cut off those Python 3.x users from other functionality in multiprocessing which does not depend upon a working sem_open implementation.

It'd make for a nice, tidy solution, that "from .synchronize ..." -- but I wasn't prepared to alter other expected behaviors.  Hence the earlier comment about, "I believe a less-than-simple refactoring is required to get both execution paths to encounter the same exception".


If we don't do this for Hurd users (they need love too), we should do it for users like Ole who sometimes find themselves working on a cool package like astropy on a system like Hurd.

----------

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

From report at bugs.python.org  Fri Mar  6 19:59:25 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 06 Mar 2015 18:59:25 +0000
Subject: [issue20271] urllib.parse.urlparse() accepts wrong URLs
In-Reply-To: <1389789129.93.0.775761654638.issue20271@psf.upfronthosting.co.za>
Message-ID: <1425668365.87.0.692607381515.issue20271@psf.upfronthosting.co.za>


Demian Brecht added the comment:

> splitport() shouldn't handle auth, it should be called after auth is dropped with splituser().

Why shouldn't splitport() handle auth? Are you suggesting that in the eyes of splitport() that "user:password at host:port" should be invalid?

>>> parse.splitport('user:password at host:80')
('user:password at host', '80')

Seems to be reasonable behaviour to me. Why add the artificial constraint of calling splituser() first?

----------

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

From report at bugs.python.org  Fri Mar  6 19:59:51 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 06 Mar 2015 18:59:51 +0000
Subject: [issue20271] urllib.parse.urlparse() accepts wrong URLs
In-Reply-To: <1389789129.93.0.775761654638.issue20271@psf.upfronthosting.co.za>
Message-ID: <1425668391.76.0.650057482114.issue20271@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


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

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

From report at bugs.python.org  Fri Mar  6 20:31:06 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 06 Mar 2015 19:31:06 +0000
Subject: [issue20557] Use specific asserts in io tests
In-Reply-To: <1391808897.1.0.851007465151.issue20557@psf.upfronthosting.co.za>
Message-ID: <1425670266.31.0.244397957622.issue20557@psf.upfronthosting.co.za>


Demian Brecht added the comment:

LGTM

----------
nosy: +demian.brecht
stage: patch review -> commit review

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

From report at bugs.python.org  Fri Mar  6 20:44:07 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 06 Mar 2015 19:44:07 +0000
Subject: [issue20556] Use specific asserts in threading tests
In-Reply-To: <1391808878.85.0.661174932104.issue20556@psf.upfronthosting.co.za>
Message-ID: <1425671047.78.0.0946264869976.issue20556@psf.upfronthosting.co.za>


Demian Brecht added the comment:

LGTM

----------
nosy: +demian.brecht
stage: patch review -> commit review

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

From report at bugs.python.org  Fri Mar  6 20:52:35 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Fri, 06 Mar 2015 19:52:35 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425671555.81.0.715662276211.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

Ryan,
Here are the changes to pyconfig.h.  I left out this
#define ANDROID 1
because GCC 4.8.x and up have -mandroid -mbionic that define __ANDROID__ so I've been using that.

#define HAVE_BROKEN_MBSTOWCS 1
#undef HAVE_DEV_PTMX
#undef HAVE_GETHOSTBYNAME_R
#undef HAVE_MBRTOWC
#define HAVE_NCURSES_H 1  /* This only if you've cross compiled curses */
#undef HAVE_SETLOCALE
#undef HAVE_WCSCOLL
#undef HAVE_WCSFTIME
#undef HAVE_WCSXFRM

The following changes were made to Modules/Setup

*shared*

<snip>

array arraymodule.c     -L. -lpython3.4m # array objects
cmath cmathmodule.c _math.c -L. -lpython3.4m -lm # complex math library functions
math mathmodule.c _math.c -L. -lpython3.4m -lm # math library functions, e.g. sin()
_struct _struct.c       -L. -lpython3.4m # binary structure packing/unpacking
time timemodule.c  -L. -lpython3.4m -lm # time operations and variables
_testcapi _testcapimodule.c    -L. -lpython3.4m # Python C API test module
_random _randommodule.c -L. -lpython3.4m # Random number generator
_elementtree -I$(srcdir)/Modules/expat -DHAVE_EXPAT_CONFIG_H -DUSE_PYEXPAT_CAPI _ele
menttree.c      -L -lpython3.4m # elementtree accelerator
_pickle _pickle.c       -L. -lpython3.4m # pickle accelerator
_datetime _datetimemodule.c     -L. -lpython3.4m # datetime accelerator
_bisect _bisectmodule.c -L. -lpython3.4m # Bisection algorithms


unicodedata unicodedata.c    -L. -lpython3.4m # static Unicode character database

<snip>

#grp grpmodule.c                # grp(3)                                             select selectmodule.c   -lm -L. -lpython3.4m # select(2); not on ancient System      V                                                                                    

# CSV file helper
_csv _csv.c -L. -lpython3.4m

# Socket module helper for socket(2)
_socket socketmodule.c -L. -lpython3.4m

# Socket module helper for SSL support; you must comment out the other               # socket line above, and possibly edit the SSL variable:                             #SSL=/usr/local/ssl                                                                  _ssl _ssl.c \                                                                                -DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \                                -L. -lpython3.4m -L$(SSL)/lib -lssl -lcrypto

----------

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

From report at bugs.python.org  Fri Mar  6 20:59:32 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 19:59:32 +0000
Subject: [issue22853] Multiprocessing.Queue._feed deadlocks on import
In-Reply-To: <1415795371.09.0.078459007626.issue22853@psf.upfronthosting.co.za>
Message-ID: <1425671972.2.0.18549549213.issue22853@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm not sure there is a need to fix this issue. Using multiprocessing Queue at import time looks as yet one way to shoot yourself in the foot. But the patch looks harmful, I'll commit it.

----------
components: +Library (Lib)
stage: patch review -> commit review

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

From report at bugs.python.org  Fri Mar  6 21:06:35 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 06 Mar 2015 20:06:35 +0000
Subject: [issue22853] Multiprocessing.Queue._feed deadlocks on import
In-Reply-To: <1415795371.09.0.078459007626.issue22853@psf.upfronthosting.co.za>
Message-ID: <1425672395.82.0.626632424779.issue22853@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

That's all we need, harmful patches being committed :)  Harmless possibly?

----------

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

From report at bugs.python.org  Fri Mar  6 21:21:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 20:21:04 +0000
Subject: [issue22853] Multiprocessing.Queue._feed deadlocks on import
In-Reply-To: <1415795371.09.0.078459007626.issue22853@psf.upfronthosting.co.za>
Message-ID: <1425673264.54.0.211615793699.issue22853@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, right. Harmless. Thanks for all the fish Mark. I meant the bug.

----------

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

From report at bugs.python.org  Fri Mar  6 21:34:33 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Mar 2015 20:34:33 +0000
Subject: [issue22853] Multiprocessing.Queue._feed deadlocks on import
In-Reply-To: <1415795371.09.0.078459007626.issue22853@psf.upfronthosting.co.za>
Message-ID: <20150306203345.8063.19612@psf.io>


Roundup Robot added the comment:

New changeset 069c13ca7a70 by Serhiy Storchaka in branch '2.7':
Issue #22853: Fixed a deadlock when use multiprocessing.Queue at import time.
https://hg.python.org/cpython/rev/069c13ca7a70

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Mar  6 21:49:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 20:49:04 +0000
Subject: [issue22853] Multiprocessing.Queue._feed deadlocks on import
In-Reply-To: <1415795371.09.0.078459007626.issue22853@psf.upfronthosting.co.za>
Message-ID: <1425674944.62.0.213466739083.issue22853@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

As for 3.x, underscored test does not run, and when remove the underscore it runs, but produce a warning (you should run regrtests with -vv to see detailed warnings):

$ ./python -m test.regrtest -vv -m '*no_import_lock_contention*' test_multiprocessing_spawn
...
Warning -- threading._dangling was modified by test_multiprocessing_spawn
  Before: <_weakrefset.WeakSet object at 0xb6a960ac>
  After:  <_weakrefset.WeakSet object at 0xb6c4cc0c> 
1 test altered the execution environment:
    test_multiprocessing_spawn

----------

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

From report at bugs.python.org  Fri Mar  6 21:55:09 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 06 Mar 2015 20:55:09 +0000
Subject: [issue20211] setup.py: do not add invalid header locations
In-Reply-To: <1389308528.92.0.403642458985.issue20211@psf.upfronthosting.co.za>
Message-ID: <1425675309.11.0.619537508293.issue20211@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Can we have a patch review on this issue please.

----------
nosy: +BreamoreBoy

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

From report at bugs.python.org  Fri Mar  6 22:05:14 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 06 Mar 2015 21:05:14 +0000
Subject: [issue20911] urllib 'headers' is not a well defined data type
In-Reply-To: <1394724454.41.0.246031763328.issue20911@psf.upfronthosting.co.za>
Message-ID: <1425675914.92.0.476775487144.issue20911@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Demian I believe this maybe of interest to you.

----------
nosy: +BreamoreBoy, demian.brecht

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

From report at bugs.python.org  Fri Mar  6 22:25:49 2015
From: report at bugs.python.org (Davin Potts)
Date: Fri, 06 Mar 2015 21:25:49 +0000
Subject: [issue22853] Multiprocessing.Queue._feed deadlocks on import
In-Reply-To: <1415795371.09.0.078459007626.issue22853@psf.upfronthosting.co.za>
Message-ID: <1425677149.14.0.349028835005.issue22853@psf.upfronthosting.co.za>


Davin Potts added the comment:

Corrected patch for 3.4 and default/3.5 -- newly introduced test is now turned on this time and the dangling weak references are properly addressed as well as the reference to Empty.  Nastiness.

Good save, Serhiy.

----------
Added file: http://bugs.python.org/file38361/issue_22853_revised_only_test_import_lock_in_queue_py34_and_py35.patch

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

From report at bugs.python.org  Fri Mar  6 22:26:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 21:26:14 +0000
Subject: [issue2052] Allow changing difflib._file_template character encoding.
In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za>
Message-ID: <1425677174.72.0.352976048704.issue2052@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be updating the markup to HTML5 should be different issue. issue2052_html5_v2.diff not only adds charset in HTML5 format, it totally changes the template. This definitely a separate issue.

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Fri Mar  6 22:35:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Mar 2015 21:35:24 +0000
Subject: [issue22853] Multiprocessing.Queue._feed deadlocks on import
In-Reply-To: <1415795371.09.0.078459007626.issue22853@psf.upfronthosting.co.za>
Message-ID: <20150306213429.8069.91797@psf.io>


Roundup Robot added the comment:

New changeset cf12856bde17 by Serhiy Storchaka in branch '3.4':
Issue #22853: Added regression test for using multiprocessing.Queue at import
https://hg.python.org/cpython/rev/cf12856bde17

New changeset dcd6d41f2c9a by Serhiy Storchaka in branch 'default':
Issue #22853: Added regression test for using multiprocessing.Queue at import
https://hg.python.org/cpython/rev/dcd6d41f2c9a

----------

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

From report at bugs.python.org  Fri Mar  6 22:36:21 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 21:36:21 +0000
Subject: [issue22853] Multiprocessing.Queue._feed deadlocks on import
In-Reply-To: <1415795371.09.0.078459007626.issue22853@psf.upfronthosting.co.za>
Message-ID: <1425677781.63.0.436656461409.issue22853@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Florian and Davin for your contribution.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Fri Mar  6 23:18:25 2015
From: report at bugs.python.org (Davin Potts)
Date: Fri, 06 Mar 2015 22:18:25 +0000
Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()]
 deadlock
In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za>
Message-ID: <1425680305.65.0.567875400177.issue23051@psf.upfronthosting.co.za>


Davin Potts added the comment:

Updated (1) the patch for default/3.5 and 3.4 and (2) the patch for 2.7 to reflect recommendations from the review.

Thanks goes to Serhiy for the helpful review and especially the suggestion on better future-proofing in the tests.

----------
Added file: http://bugs.python.org/file38362/issue_23051_revised_fix_and_tests_v35_and_v34.patch

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

From report at bugs.python.org  Fri Mar  6 23:19:01 2015
From: report at bugs.python.org (Davin Potts)
Date: Fri, 06 Mar 2015 22:19:01 +0000
Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()]
 deadlock
In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za>
Message-ID: <1425680341.8.0.924279699688.issue23051@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


Added file: http://bugs.python.org/file38363/issue_23051_revised_fix_and_tests_v27.patch

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

From report at bugs.python.org  Fri Mar  6 23:22:22 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Mar 2015 22:22:22 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425657353.53.0.191129899035.issue23571@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ+QV4Z-KwQPKyeB6UQW1dkfdhu0rFK8=zsBz385TG6+Q@mail.gmail.com>


STINNER Victor added the comment:

2015-03-06 16:55 GMT+01:00 Serhiy Storchaka <report at bugs.python.org>:
> We can ignore such little slow down (if this is not just compiler artifact).

Maybe it's time to play with micro-optimizations like __builtin_expect
:-) But I would prefer to do that in a separated issue. The patch is
already long and complex.

> The patch LGTM. I afraid there will be issues with third-party code that will need an adaptation to 3.5, but on other hand, this patch could help with catching some hidden bugs.

My patch doesn't make more strict. Without my patch, if a function
returns a result and raise an exception, the exception will still be
noticed, but probably later. The purpose of my change is to notify
immediatly that the function raised an exception.

Without my patch, if a function returns a result and raise an
exception, it's possible that the exception is cleared and so never
seen.

In older Python versions, Python/ceval.c displayed the message "XXX
undetected error" when an exception was raised but also a result was
returned.

Anyway, you must fix your code :-)

----------

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

From report at bugs.python.org  Fri Mar  6 23:29:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 22:29:08 +0000
Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if
 sem_open is not implemented
In-Reply-To: <1425667737.34.0.699803488294.issue23400@psf.upfronthosting.co.za>
Message-ID: <1601680.2zdnaPhQso@raxxla>


Serhiy Storchaka added the comment:

> Please keep in mind that this issue should only be encountered by people
> using Python 3.x on a platform like Hurd (an unsupported platform) that has
> no working sem_open implementation.

Yes, and I compiled Python with disabled sem_open for testing.

Python not always specifies what exact type of exception is raised. When you 
pass wrong type of argument to a function, it can raise TypeError or 
AttributeError. If you request unsupported feature, it can raise ImportError, 
AttributeError, or even NameError. Python and C implementations can raise 
different errors (C implementation usually more strict). Not all such cases are 
considered as bugs.

> Adding the "from .synchronize import SEM_VALUE_MAX as maxsize" as was
> suggested would indeed trigger the ImportError but it would also trigger
> this ImportError immediately upon simply doing an "import multiprocessing"
> which is not the current behavior on systems like Hurd.

No, I suggested to replace only the line that produces AttributeError now.

----------

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

From report at bugs.python.org  Fri Mar  6 23:31:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 22:31:31 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1425681091.81.0.38915935593.issue23571@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> haypo
stage:  -> commit review

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

From report at bugs.python.org  Fri Mar  6 23:37:16 2015
From: report at bugs.python.org (Jeff Doak)
Date: Fri, 06 Mar 2015 22:37:16 +0000
Subject: [issue23599] single and double quotes stripped upon paste into
 interpreter
Message-ID: <1425681436.7.0.781270448465.issue23599@psf.upfronthosting.co.za>


New submission from Jeff Doak:

On MacBook. Copy/paste the following line into 3.4.2 interpreter session:
[?Test?][?Test?]
Results in:
[Test][Test]

Same paste into 2.7.6 is as expected:
[?Test?][?Test?]

----------
components: Macintosh
messages: 237389
nosy: Jeff Doak, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: single and double quotes stripped upon paste into interpreter
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar  6 23:44:19 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Mar 2015 22:44:19 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425681859.27.0.396690511681.issue23524@psf.upfronthosting.co.za>


STINNER Victor added the comment:

23524_hack_2.patch looks good to me.

23524_hack_2.patch is fine to workaround the issue, but I agree that it's only a hack and it should be enhanced later.

----------

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

From report at bugs.python.org  Fri Mar  6 23:47:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Mar 2015 22:47:42 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <20150306224733.11183.47475@psf.io>


Roundup Robot added the comment:

New changeset 75aadb4450fd by Steve Dower in branch 'default':
Issue #23524: Replace _PyVerify_fd function with calling _set_thread_local_invalid_parameter_handler on every thread.
https://hg.python.org/cpython/rev/75aadb4450fd

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Mar  6 23:49:26 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 06 Mar 2015 22:49:26 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425682166.12.0.700075164053.issue23524@psf.upfronthosting.co.za>


Steve Dower added the comment:

Thanks. I'll be watching the buildbots closely, but hopefully there's no need to push quick fixes with the reduced change.

23524_2.patch is still on the table as the last-known-good fix, but I'll update it as soon as I can to take into account what's just been checked in.

----------

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

From report at bugs.python.org  Fri Mar  6 23:49:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Mar 2015 22:49:48 +0000
Subject: [issue23599] single and double quotes stripped upon paste into
 interpreter
In-Reply-To: <1425681436.7.0.781270448465.issue23599@psf.upfronthosting.co.za>
Message-ID: <1425682188.97.0.964184775046.issue23599@psf.upfronthosting.co.za>


R. David Murray added the comment:

Those aren't actually quote marks, at least as you've cut and pasted them.  They are "smart quotes", which are not something Python recognizes outside of properly quoted strings.

That doesn't explain why they disappear, though, you should just get a syntax error.  Works fine on linux, by the way.

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

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

From report at bugs.python.org  Fri Mar  6 23:53:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 Mar 2015 22:53:42 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <20150306225339.9662.6323@psf.io>


Roundup Robot added the comment:

New changeset 97ef38236dc1 by Victor Stinner in branch 'default':
Issue #23571: PyObject_Call(), PyCFunction_Call() and call_function() now
https://hg.python.org/cpython/rev/97ef38236dc1

----------
nosy: +python-dev

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

From report at bugs.python.org  Fri Mar  6 23:54:25 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 Mar 2015 22:54:25 +0000
Subject: [issue19610] setup.py does not allow a tuple for classifiers
In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za>
Message-ID: <1425682465.54.0.382641648107.issue19610@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Does current code work with None or empty tuple?

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sat Mar  7 00:01:11 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Mar 2015 23:01:11 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1425682871.3.0.218961576272.issue23571@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks for the very useful reviews Serhiy!

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Mar  7 00:19:56 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 06 Mar 2015 23:19:56 +0000
Subject: [issue23599] single and double quotes stripped upon paste into
 interpreter
In-Reply-To: <1425681436.7.0.781270448465.issue23599@psf.upfronthosting.co.za>
Message-ID: <1425683996.64.0.561407132965.issue23599@psf.upfronthosting.co.za>


Demian Brecht added the comment:

I'm on OSX 10.10.2. Simply copy/pasting the line into both terminal and iterm yields

>>> [?Test?][?Test?]
  File "<stdin>", line 1
    [?Test?][?Test?]
          ^
SyntaxError: invalid character in identifier
>>> [?Test?][?Test?]
  File "<stdin>", line 1
    [?Test?][?Test?]
              ^
SyntaxError: invalid character in identifier

Are the smart quotes disappearing when the clipboard buffer is being copied into the terminal shell or when you hit enter? If it's on copy, what happens when you hit enter?

----------
nosy: +demian.brecht

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

From report at bugs.python.org  Sat Mar  7 00:27:53 2015
From: report at bugs.python.org (Gian-Carlo Pascutto)
Date: Fri, 06 Mar 2015 23:27:53 +0000
Subject: [issue23129] sqlite3 COMMIT nested in SELECT returns unexpected
 results
In-Reply-To: <1419873078.33.0.518262497665.issue23129@psf.upfronthosting.co.za>
Message-ID: <1425684473.79.0.920381048419.issue23129@psf.upfronthosting.co.za>


Gian-Carlo Pascutto added the comment:

I've ran into this as well, when a program that was running correctly with PostgreSQL turned out to produce garbage with SQLite. Code to reproduce roughly looks like this:

    sel_cursor = conn.cursor()
    sel_cursor.execute("SELECT prim_key_id FROM "
                       "somedb ORDER BY start_time ASC")
    add_cursor = conn.cursor()
    prim_keys = set()
    row = sel_cursor.fetchone()
    while row:
        seq = row[0]
        if seq in prim_keys:
            raise RuntimeError
        prim_keys.add(seq)
        add_cursor.execute("INSERT INTO someotherdb "
                           "VALUES (?)",
                           seq)
        conn.commit()
        row = sel_cursor.fetchone()
    conn.commit()

This will raise a RuntimeError because the SELECT will return the same primary key value twice - something that's obviously impossible.

This exact bug has been filed once more already, and it seems to be an actual regression in Python 2.7:
http://bugs.python.org/issue10513

Looking at the code there, I agree with the analysis in this message: http://bugs.python.org/issue10513#msg150162

Either the pysqlite_do_all_statements should set reset_cursors=1 to warn the user that the cursor has been reset, or it shouldn't reset them to begin with (as Python <2.7 used to do).

I don't think there's any argument this isn't a (bad) bug: Python <2.7 works correctly and later versions silently corrupt data.

----------
nosy: +Gian-Carlo Pascutto

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

From report at bugs.python.org  Sat Mar  7 00:35:28 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 06 Mar 2015 23:35:28 +0000
Subject: [issue20059] Inconsistent urlparse/urllib.parse handling of invalid
 port values?
In-Reply-To: <1387842710.57.0.78188368243.issue20059@psf.upfronthosting.co.za>
Message-ID: <1425684928.02.0.213426487052.issue20059@psf.upfronthosting.co.za>


Demian Brecht added the comment:

> It is surprising that urlsplit() does not raise any exception

I have a bit of a TL;DR in #20271, trying to capture what the responsibilities of split and parse methods in urllib are and what they should be if consistency is something that we're after.


Around the patch though:

It seems quite odd to me to be raising exceptions on accessors rather than on instantiation or when the parsing occurs (in the body of urlparse). Wouldn't it better to raise the exception there?

----------
nosy: +demian.brecht

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

From report at bugs.python.org  Sat Mar  7 00:36:53 2015
From: report at bugs.python.org (Davin Potts)
Date: Fri, 06 Mar 2015 23:36:53 +0000
Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if
 sem_open is not implemented
In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za>
Message-ID: <1425685013.58.0.290165880479.issue23400@psf.upfronthosting.co.za>


Davin Potts added the comment:

> No, I suggested to replace only the line that produces AttributeError now.

Ah!  Sorry, I misunderstood and incorrectly assumed you were imagining the import to happen at the top of the module.

I must confess I am hesitant about the idea of putting an import inside the Queue.__init__ (or any method) because I generally don't consider it a best practice -- that said, there are a number of places within (not only) the multiprocessing module where imports are performed dynamically as part of implementations for various methods, but it bothers me when I see those as well.  Yet your solution is simple and offers the benefit of not having the same (or nearly the same) text appear twice in the code.

Berker: Do you have any strong feeling on this idea?  If not, I am tempted to bend on my instinctive reaction here and go with Serhiy's style.

----------

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

From report at bugs.python.org  Sat Mar  7 00:39:37 2015
From: report at bugs.python.org (Jeff Doak)
Date: Fri, 06 Mar 2015 23:39:37 +0000
Subject: [issue23599] single and double quotes stripped upon paste into
 interpreter
In-Reply-To: <1425681436.7.0.781270448465.issue23599@psf.upfronthosting.co.za>
Message-ID: <1425685177.36.0.966453116877.issue23599@psf.upfronthosting.co.za>


Jeff Doak added the comment:

I noticed they are smart quotes and came back to see David already mentioned it.
As for Demian's question:
2.7.6:
>>> print("{?Test?}")   
{?Test?}
3.4.2:
>>> print("{Test}") 
{Test}

It is upon paste that the quotes are lost. I'm on OSX 10.10.2 as well.

----------

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

From report at bugs.python.org  Sat Mar  7 00:40:25 2015
From: report at bugs.python.org (Gian-Carlo Pascutto)
Date: Fri, 06 Mar 2015 23:40:25 +0000
Subject: [issue10513] sqlite3.InterfaceError after commit
In-Reply-To: <1290515734.43.0.643837241692.issue10513@psf.upfronthosting.co.za>
Message-ID: <1425685225.27.0.629570338796.issue10513@psf.upfronthosting.co.za>


Gian-Carlo Pascutto added the comment:

I believe http://bugs.python.org/issue23129 is a dupe of this.

The patch here has been in "patch review" for 9 months. That seems fairly long for something that's a regression that potentially silently produces the wrong data.

----------
nosy: +Gian-Carlo Pascutto

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

From report at bugs.python.org  Sat Mar  7 00:47:32 2015
From: report at bugs.python.org (Ned Deily)
Date: Fri, 06 Mar 2015 23:47:32 +0000
Subject: [issue23599] single and double quotes stripped upon paste into
 interpreter
In-Reply-To: <1425681436.7.0.781270448465.issue23599@psf.upfronthosting.co.za>
Message-ID: <1425685652.59.0.529409799421.issue23599@psf.upfronthosting.co.za>


Ned Deily added the comment:

You've already answered this but since I've already typed it: one possible pitfall here is the automatic smart quotes feature of the OS X text system which may or may not be a factor depending on which programs are in use.  You can disable smart quotes in: System Preferences -> Keyboard -> Text -> Use smart quotes and dashes (this is on OS X 10.10).

But we really need more details to try to explain what you are seeing.  Can you give a step by step procedure on how to reproduce, including exactly what apps are being used (e.g. Terminal.app vs iTerm.app vs IDLE), and the results of the following commands in a terminal shell:

python3.4 -c 'import sys;print(sys.version)'
python3.4 -c 'import readline;print(readline.__doc__)'
env | egrep '(LC)|(LANG)'

----------

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

From report at bugs.python.org  Sat Mar  7 01:16:28 2015
From: report at bugs.python.org (Jeff Doak)
Date: Sat, 07 Mar 2015 00:16:28 +0000
Subject: [issue23599] single and double quotes stripped upon paste into
 interpreter
In-Reply-To: <1425681436.7.0.781270448465.issue23599@psf.upfronthosting.co.za>
Message-ID: <1425687388.31.0.892897417832.issue23599@psf.upfronthosting.co.za>


Jeff Doak added the comment:

I am in a standard Terminal session. I have a symbolic link for python 3.4:
/usr/bin/python -> /opt/local/bin/python3.4
so I can run python... or the following:
$ /opt/local/bin/python3.4 -c 'import sys;print(sys.version)'
3.4.2 (default, Oct 22 2014, 01:08:11) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.54)]

$ /opt/local/bin/python3.4 -c 'import readline;print(readline.__doc__)'
Importing this module enables command line editing using libedit readline.

----------

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

From report at bugs.python.org  Sat Mar  7 01:39:41 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Mar 2015 00:39:41 +0000
Subject: [issue23599] single and double quotes stripped upon paste into
 interpreter
In-Reply-To: <1425681436.7.0.781270448465.issue23599@psf.upfronthosting.co.za>
Message-ID: <1425688781.17.0.435451572061.issue23599@psf.upfronthosting.co.za>


Ned Deily added the comment:

OK, thanks, now we're getting somewhere!  From the pathname (/opt/local/bin), I assume you are using the Python 3.4 from MacPorts and from the readline docstring that Python 3.4 is linked with BSD libedit rather than GNU readline.  MacPorts supplies its own, newer version of libedit rather than the Apple-supplied one shipped with OS X.  It looks there is something funky going on there such that the pasted characters are being edited. The python.org Python 3.4 links with the older system libedit and it does not display this behavior.  It could also be due to a patch in the MacPorts Python 3.4 or libedit.  In any case, there seems to be an easy workaround: have the MacPorts Python use GNU readline instead.  You can do that by running:

sudo port py34-readline

I'll leave this open to investigate further later, assuming the workaround works for you.

----------

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

From report at bugs.python.org  Sat Mar  7 01:40:27 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Mar 2015 00:40:27 +0000
Subject: [issue23599] single and double quotes stripped upon paste into
 interpreter
In-Reply-To: <1425681436.7.0.781270448465.issue23599@psf.upfronthosting.co.za>
Message-ID: <1425688827.82.0.967598485716.issue23599@psf.upfronthosting.co.za>


Ned Deily added the comment:

Er, make that:

sudo port install py34-readline

----------

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

From report at bugs.python.org  Sat Mar  7 01:43:03 2015
From: report at bugs.python.org (Peter J C Law)
Date: Sat, 07 Mar 2015 00:43:03 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
Message-ID: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>


New submission from Peter J C Law:

There's a difference in behaviour between the ``fromutc`` method on a tzinfo between Python 2 and Python 3, though only under the specific case of Summer Time in regions whose usual offset is 0.

>From what I can tell, it's the Python 3 one which is wrong, based on it no longer matching the sample implementation provided in the docs and on it appearing to report the wrong times for ``datetime.now(tz)`` when on a machine configured for BST during June 2015.
Similar results can also be achieved using a manually constructed ``datetime`` for dates during summer 2014.

I've put the python script (and sample outputs) I used to investigate in a gist at https://gist.github.com/PeterJCLaw/d8bcc168d68acf066811#file-time_issues-py. The outputs there are for pythons 2.7.9 and 3.4.0.

----------
components: Library (Lib)
messages: 237407
nosy: peterjclaw
priority: normal
severity: normal
status: open
title: tizinfo.fromutc changed for tzinfo wih StdOffset=0, DstOffset=1
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar  7 01:44:38 2015
From: report at bugs.python.org (Dmitry Chichkov)
Date: Sat, 07 Mar 2015 00:44:38 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1425689078.47.0.473801800248.issue4356@psf.upfronthosting.co.za>


Dmitry Chichkov added the comment:

Use case: a custom immutable array with a large number of items and indirect key field access. For example ctypes.array, memoryview or ctypes.pointer or any other custom container.


1. I'm not sure how anyone can consider a precached key array as a right ans scalable answer. It is just a ridiculuos idea. Precashing key array is a O(N) operation.  While bisect is O(log(N)).

2. @Raymond There is a statement that "adding 'key()' would encourage bad design and steer people after from better solutions."  Well, right now, the design that is being encouraged results in O(N) code. Because lazy developers are just 'pre-cacaching' (copying) the keys!

3. There is a statement that key() have to be called multiple times per item. What?  Why?

4. There is a statement that one can always add a _cmp_ function to an object. This is ridiculuous. The object could be immutable. There should be no need to modify the object/array when all that you need to do is to bisect it.

----------
nosy: +dmtr

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

From report at bugs.python.org  Sat Mar  7 02:41:26 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Mar 2015 01:41:26 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425692486.58.0.563461151472.issue21619@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for getting the test working. Just to tidy things up here I would like to get rid of my stdout signalling in the test, which is no longer needed and could be misleading. See overflow-pipe-test.patch.

----------
status: closed -> open
Added file: http://bugs.python.org/file38364/overflow-pipe-test.patch

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

From report at bugs.python.org  Sat Mar  7 03:29:55 2015
From: report at bugs.python.org (Demian Brecht)
Date: Sat, 07 Mar 2015 02:29:55 +0000
Subject: [issue22852] urllib.parse wrongly strips empty #fragment
In-Reply-To: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za>
Message-ID: <1425695395.64.0.703561995956.issue22852@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +demian.brecht

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

From report at bugs.python.org  Sat Mar  7 03:32:39 2015
From: report at bugs.python.org (Demian Brecht)
Date: Sat, 07 Mar 2015 02:32:39 +0000
Subject: [issue1508475] transparent gzip compression in urllib
Message-ID: <1425695559.35.0.869782307222.issue1508475@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +demian.brecht

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

From report at bugs.python.org  Sat Mar  7 03:36:51 2015
From: report at bugs.python.org (Demian Brecht)
Date: Sat, 07 Mar 2015 02:36:51 +0000
Subject: [issue23328] urllib2 fails for proxy credentials that contain a '/'
 character
In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za>
Message-ID: <1425695811.96.0.0777928081707.issue23328@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +demian.brecht

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

From report at bugs.python.org  Sat Mar  7 03:52:31 2015
From: report at bugs.python.org (Jeff Doak)
Date: Sat, 07 Mar 2015 02:52:31 +0000
Subject: [issue23599] single and double quotes stripped upon paste into
 interpreter
In-Reply-To: <1425681436.7.0.781270448465.issue23599@psf.upfronthosting.co.za>
Message-ID: <1425696751.64.0.0694529521692.issue23599@psf.upfronthosting.co.za>


Jeff Doak added the comment:

Thanks Ned and everyone!  It turns out that Ned was correct and it works fine now that I followed his instructions.

----------

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

From report at bugs.python.org  Sat Mar  7 03:53:11 2015
From: report at bugs.python.org (Yassine ABOUKIR)
Date: Sat, 07 Mar 2015 02:53:11 +0000
Subject: [issue23505] Urlparse insufficient validation leads to open redirect
In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za>
Message-ID: <1425696791.58.0.0875698066931.issue23505@psf.upfronthosting.co.za>


Yassine ABOUKIR added the comment:

From: cve-assign () mitre org
Date: Thu, 5 Mar 2015 16:42:02 -0500 (EST)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We think that the issue reduces to the question of whether it's
acceptable for urlparse to provide inconsistent information about the
structure of a URL.

https://docs.python.org/2/library/urlparse.html says:

   urlparse.urlparse(urlstring[, scheme[, allow_fragments]])
   Parse a URL into six components, returning a 6-tuple. This
   corresponds to the general structure of a URL:
   scheme://netloc/path;parameters?query#fragment.


   urlparse.urlunparse(parts)
   Construct a URL from a tuple as returned by urlparse(). The parts
   argument can be any six-item iterable. This may result in a
   slightly different, but equivalent URL, if the URL that was parsed
   originally had unnecessary delimiters (for example, a ? with an
   empty query; the RFC states that these are equivalent).

The first issue is that the urlunparse documentation is ambiguous. We
believe the reasonable interpretation is that there is a missing third
sentence: "This ALWAYS results in a URL that is either identical or
equivalent to the URL that was parsed originally." There's another
interpretation that we believe is unreasonable: "This may result in a
slightly different, but equivalent URL, if the URL that was parsed
originally had unnecessary delimiters. If the URL that was parsed
originally did not have unnecessary delimiters, then the behavior of
urlunparse is UNDEFINED."

So, our expectation is that urlunparse(urlparse(original_url)) should
not have any significant effect on the meaning of original_url. We
also think that a Python user should be able to rely on that property
to make security-relevant decisions. To simply the situation, consider
a case where the URL is used exclusively within Python code, and is
never accessed by any web browser.

The actual behavior is:

   >>> from urlparse import urlparse, urlunparse
   >>> print urlparse("////example.com")
   ParseResult(scheme='', netloc='', path='//example.com', params='', query='', fragment='')
   >>> print urlparse(urlunparse(urlparse("////example.com")))
   ParseResult(scheme='', netloc='example.com', path='', params='', query='', fragment='')
   >>> print urlparse(urlunparse(urlparse(urlunparse(urlparse("////example.com")))))
   ParseResult(scheme='', netloc='example.com', path='', params='', query='', fragment='')

Here, urlparse(urlunparse(original_url)) does have a significant
effect on the meaning of original_url. The Python user may have wanted
to make a security-relevant decision based on whether netloc was an
empty string. However, netloc is different depending on whether
urlparse(urlunparse(original_url)) occurs at least once. The user's
application (suppose it's called "PyNetlocExaminer") is affected in a
security-relevant way.

The next question is, if there is a CVE for a report of a
security-relevant problem, what product is named as the primary
affected product within that CVE. There is no perfect answer to this
question. Especially in the case of a general-purpose language such as
Python, there's an extremely wide range of bugs that might become
security-relevant in some applications. What we usually try to do is
make the CVE useful to users who may need to perform a software
update. Specifically:

  1. If the language implementation is not ever going to be changed
     (for example: because the language maintainer believes the
     observed behavior has always been correct, or the language
     maintainer believes that it has retroactively become correct
     because any change would break compatibility with other
     applications), then the application is named as the primary
     affected product in the CVE. In other words, if the inconsistency
     between netloc='' and netloc='example.com' were actually the
     intended behavior all along, then PyNetlocExaminer would be named
     in the CVE. Here, realistically, the end user would need to
     update or manually fix PyNetlocExaminer.

  2. If the language implementation is incorrect and is planned to be
     changed at some point, and that would eliminate the
     security-relevant problem, then the language implementation is
     named in the CVE. (An application might also be named in the CVE,
     especially if there are very few affected applications.) This
     option occurs regardless of whether the language maintainer
     believes that it is a language vulnerability. (The language
     maintainer has the option of composing a dispute that would be
     appended to the CVE.) Here, the end user may ultimately decide to
     address the problem by updating their Python installation, not by
     updating PyNetlocExaminer.

Again, this is imperfect. It works best in the relatively common case
where a language bug has security relevance in many applications. It
might work especially poorly in a case where a language bug has
security relevance in exactly one application. However, it seems
preferable to do the above consistently, rather than make the outcome
depend on application populations, or depend on reaching universal
agreement about what code should have been written differently.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]

----------

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

From report at bugs.python.org  Sat Mar  7 03:55:10 2015
From: report at bugs.python.org (Yassine ABOUKIR)
Date: Sat, 07 Mar 2015 02:55:10 +0000
Subject: [issue23505] Urlparse insufficient validation leads to open redirect
In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za>
Message-ID: <1425696910.76.0.0796022266632.issue23505@psf.upfronthosting.co.za>


Yassine ABOUKIR added the comment:

From: Amos Jeffries <squid3 () treenet co nz>
Date: Fri, 06 Mar 2015 14:09:55 +1300

On 6/03/2015 10:42 a.m., cve-assign () mitre org wrote:

    We think that the issue reduces to the question of whether it's
    acceptable for urlparse to provide inconsistent information about the
    structure of a URL.

    https://docs.python.org/2/library/urlparse.html says:

       urlparse.urlparse(urlstring[, scheme[, allow_fragments]])
       Parse a URL into six components, returning a 6-tuple. This
       corresponds to the general structure of a URL:
       scheme://netloc/path;parameters?query#fragment.


My 2c ... no it does not.

There are 7 parts in a URL. What is called "netloc" in that description
is actually two fields: [userinfo '@'] authority

The userinfo field is very much alive and well in non-HTTP schemes.


Ignoring the userinfo field leaves implementations open to attacks of
the form:
   scheme://example.com () phishing com/path

AYJ

----------

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

From report at bugs.python.org  Sat Mar  7 03:59:07 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Mar 2015 02:59:07 +0000
Subject: [issue23599] single and double quotes stripped upon paste with
 MacPorts libedit
In-Reply-To: <1425681436.7.0.781270448465.issue23599@psf.upfronthosting.co.za>
Message-ID: <1425697147.41.0.422578336198.issue23599@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee:  -> ned.deily
title: single and double quotes stripped upon paste into interpreter -> single and double quotes stripped upon paste with MacPorts libedit

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

From report at bugs.python.org  Sat Mar  7 04:10:47 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Mar 2015 03:10:47 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1425697847.88.0.586722455912.issue23600@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +belopolsky

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

From report at bugs.python.org  Sat Mar  7 04:39:56 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 07 Mar 2015 03:39:56 +0000
Subject: [issue23574] datetime: support leap seconds
In-Reply-To: <1425393743.39.0.519990063132.issue23574@psf.upfronthosting.co.za>
Message-ID: <1425699596.8.0.441789190248.issue23574@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> POSIX is a ``standard'' designed by a vendor consortium several years ago to eliminate progress and protect the installed base.


No, POSIX is an attempt to bring some sanity to the installed base of human calendars.  The established standard tell's us that a year is 365 days.  Wait, every 4-th year is 366 days, except some other rule every 400 years.

POSIX says: fine as long as we can enumerate all YYYY-MM-DD's, we can live  with it.  But the line is drawn where each day is divided into 86,400 seconds.

The problem is that unlike ancient astronomers who were finding better and better approximations to the ratio of two Earth's rotation periods (around the Sun and around itself) every few hundred years, modern astronomers will tell us how many seconds there will be in any given year with only a six month notice.

----------

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

From report at bugs.python.org  Sat Mar  7 04:48:03 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 07 Mar 2015 03:48:03 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1425700083.19.0.829111690964.issue23600@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Peter,

Can you attach your demo script to the issue?  Better yet, is it possible to explain the issue without referring to 100 lines of code?

----------

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

From report at bugs.python.org  Sat Mar  7 05:44:17 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 07 Mar 2015 04:44:17 +0000
Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if
 sem_open is not implemented
In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za>
Message-ID: <1425703457.91.0.172796690129.issue23400@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> If not, I am tempted to bend on my instinctive reaction here and go with Serhiy's style.

+1 to Serhiy's suggestion.

----------

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

From report at bugs.python.org  Sat Mar  7 05:48:29 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Mar 2015 04:48:29 +0000
Subject: [issue23546] windows, IDLE and pep 397
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1425703709.89.0.953143003735.issue23546@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

To be more exact, (I believe) 'Edit with Idle' runs the equivalent of '<python> -m idlelib -e <file>' where <python> is the current default python (ad <file> is the file right-clicked on).  Idle just goes alone for the ride.  You are proposing more or less that <python> be replaced with 'py'.

The problems with this are that it is still opaque which version of python (and hence Idle) will be run, there is no way to select the version to be run, most people do not use #! on Windows, especially beginners, and some people want to be able to open, edit, and run a file on both 2.x and 3.x (currently most often 2.7 and 3.4).

This same issue has come up on stackoverflow.  To me, a much better solution would be an explicit 'Open with Idle x.y' on the context menu for each version of Idle installed.  This would be explicit and allow version selection.  (I am obviously proposing that the 2.7 and 3.4 installers be tweaked also.)

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Sat Mar  7 05:50:50 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Mar 2015 04:50:50 +0000
Subject: [issue23546] Windows, IDLE and py.exe
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1425703850.11.0.473231312197.issue23546@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
components:  -IDLE
stage:  -> needs patch
title: windows, IDLE and pep 397 -> Windows, IDLE and py.exe
versions: +Python 2.7 -Python 3.3

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

From report at bugs.python.org  Sat Mar  7 06:13:33 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Mar 2015 05:13:33 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1425705213.98.0.386255981423.issue23546@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Windows, IDLE and py.exe -> Windows, 'Edit withIDLE', and multplie installed versions

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

From report at bugs.python.org  Sat Mar  7 07:59:55 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 07 Mar 2015 06:59:55 +0000
Subject: [issue23432] Duplicate content in SystemExit documentation
In-Reply-To: <1423571355.15.0.388380550498.issue23432@psf.upfronthosting.co.za>
Message-ID: <1425711595.04.0.496117137516.issue23432@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thank you for your suggestion, Martin. Here is an updated patch.

----------
Added file: http://bugs.python.org/file38365/systemexit_v2.diff

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

From report at bugs.python.org  Sat Mar  7 08:06:15 2015
From: report at bugs.python.org (Sayan Chowdhury)
Date: Sat, 07 Mar 2015 07:06:15 +0000
Subject: [issue23579] Amazon.com links
In-Reply-To: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>
Message-ID: <1425711975.75.0.74736372217.issue23579@psf.upfronthosting.co.za>


Sayan Chowdhury added the comment:

Attached a patch by changing the amazon links to official websites.

----------
keywords: +patch
nosy: +sayanchowdhury
Added file: http://bugs.python.org/file38366/issue23579.patch

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

From report at bugs.python.org  Sat Mar  7 08:10:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Mar 2015 07:10:55 +0000
Subject: [issue23432] Duplicate content in SystemExit documentation
In-Reply-To: <1423571355.15.0.388380550498.issue23432@psf.upfronthosting.co.za>
Message-ID: <1425712255.01.0.837370801033.issue23432@psf.upfronthosting.co.za>


Martin Panter added the comment:

New patch looks fine

----------

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

From report at bugs.python.org  Sat Mar  7 08:11:52 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Mar 2015 07:11:52 +0000
Subject: [issue16232] curses.textpad.Textbox backtrace support
In-Reply-To: <1350225485.82.0.832122533952.issue16232@psf.upfronthosting.co.za>
Message-ID: <1425712312.25.0.791047130772.issue16232@psf.upfronthosting.co.za>


Ned Deily added the comment:

This has also been reported in Issue23598 including a patch to add DEL as suggested.  I have little experience with curses so I don't have any insight as to pros and cons of using erasechar() rather than the hardcoded BS and DEL chars.  A test would be nice if someone has a creative approach for creating one.  I see that a patch for Issue13061 contains a suggested test for another problem with curses.textpad; perhaps it could be adapted.

----------
keywords: +easy
nosy: +ned.deily, ragreener
stage:  -> test needed

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

From report at bugs.python.org  Sat Mar  7 08:12:27 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Mar 2015 07:12:27 +0000
Subject: [issue23598] No backspace on curses on iTerm (mac)
In-Reply-To: <1425643004.82.0.795836967438.issue23598@psf.upfronthosting.co.za>
Message-ID: <1425712347.54.0.719527487524.issue23598@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the suggested change.  This problem and a similar change has already been suggested in open Issue16232.  Closing this issue as a duplicate and continuing the discussion there.

----------
nosy:  -ronaldoussoren
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> curses.textpad.Textbox backtrace support

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

From report at bugs.python.org  Sat Mar  7 08:12:36 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 07 Mar 2015 07:12:36 +0000
Subject: [issue23579] Amazon.com links
In-Reply-To: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>
Message-ID: <1425712356.1.0.322954845714.issue23579@psf.upfronthosting.co.za>


Georg Brandl added the comment:

LGTM.

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Sat Mar  7 08:13:53 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Mar 2015 07:13:53 +0000
Subject: [issue16232] curses.textpad.Textbox backtrace support
In-Reply-To: <1350225485.82.0.832122533952.issue16232@psf.upfronthosting.co.za>
Message-ID: <1425712433.97.0.933964585318.issue16232@psf.upfronthosting.co.za>


Ned Deily added the comment:

This has also been reported in Issue23598 including a patch to add DEL as suggested.  I have little experience with curses so I don't have any insight as to pros and cons of using erasechar() rather than the hardcoded BS and DEL chars.  A test would be nice if someone has a creative approach for creating one.  I see that a patch for Issue13051 contains a suggested test for another problem with curses.textpad; perhaps it could be adapted.

----------

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

From report at bugs.python.org  Sat Mar  7 08:14:04 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Mar 2015 07:14:04 +0000
Subject: [issue16232] curses.textpad.Textbox backtrace support
In-Reply-To: <1350225485.82.0.832122533952.issue16232@psf.upfronthosting.co.za>
Message-ID: <1425712444.08.0.932438864742.issue16232@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
Removed message: http://bugs.python.org/msg237420

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

From report at bugs.python.org  Sat Mar  7 08:18:43 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Mar 2015 07:18:43 +0000
Subject: [issue23529] Limit decompressed data when reading from LZMAFile and
 BZ2File
In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za>
Message-ID: <1425712723.97.0.267984627537.issue23529@psf.upfronthosting.co.za>


Martin Panter added the comment:

I am posting LZMAFile-etc.v3.patch, where I have implemented a ?buffer_size? parameter to the buffered LZMAFile etc classes. I have not implemented open(buffering=...) for the time being (which should probably delegate to the buffer_size parameter or return a raw _DecompressReader object, at least for read mode). Other changes:

* Restored the _MODE_WRITE = 3 value
* Explained the _pos and _size attributes in _DecompressReader
* Factored out decomp_factory and args, decomp_error parameters to make _DecompressReader generic
* BZ2File modified similarly to LZMAFile
* I removed the deprecated and unused BZ2File(buffering=...) parameter; buffer_size takes its place. The old buffering parameter appears to have been documented, but never implemented in C Python, so hopefully this is not a big deal.

Still to do: Need to find a better home for the _DecompressReader and _BaseStream classes. Currently it lives in ?lzma?, but apparently it is possible for any of the gzip, bz2, lzma modules to not be importable, so it would have to live elsewhere. Possible options are the io module, or a brand new internal module (e.g. Lib/_compression.py). Thoughts?

Also I am about to see if I can make GzipFile use the _DecompressReader class. I will have to add GzipFile(buffer_size=...) as a keyword-only parameter since the third parameter position is already taken. There are quite a few quirks with gzip and zlib compared to bz2 and lzma, so I will see how I go.

----------
Added file: http://bugs.python.org/file38367/LZMAFile-etc.v3.patch

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

From report at bugs.python.org  Sat Mar  7 08:27:34 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 07 Mar 2015 07:27:34 +0000
Subject: [issue19610] setup.py does not allow a tuple for classifiers
In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za>
Message-ID: <1425713254.07.0.76651410191.issue19610@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> Does current code work with None or empty tuple?

Yes, it works with both None and ().

----------

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

From report at bugs.python.org  Sat Mar  7 08:45:53 2015
From: report at bugs.python.org (John Nagle)
Date: Sat, 07 Mar 2015 07:45:53 +0000
Subject: [issue9679] unicode DNS names in urllib, urlopen
In-Reply-To: <1282721968.42.0.723881796109.issue9679@psf.upfronthosting.co.za>
Message-ID: <1425714353.53.0.716672213773.issue9679@psf.upfronthosting.co.za>


John Nagle added the comment:

Three years later, I'm converting to Python 3. Did this get fixed in Python 3?

----------

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

From report at bugs.python.org  Sat Mar  7 08:46:32 2015
From: report at bugs.python.org (Demian Brecht)
Date: Sat, 07 Mar 2015 07:46:32 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
 "chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1425714392.71.0.57321924833.issue12319@psf.upfronthosting.co.za>


Demian Brecht added the comment:

FWIW, so far I've tested this change against:

cherrypy 3.6.0
uwsgi 2.0.9 (--http-raw-body)
nginx 1.6.2 (chunked_transfer_encoding on, proxy_buffering off;) + uwsgi 2.0.9 (--http-raw-body)

The chunked body works as expected. Unfortunately, all implementations seem to be ignorant of the trailer part. So it seems that although RFC-compliant (and I can definitely see the use case for it), they trailer implementation may not be overly practical. I still think that it's worthwhile keeping it, but perhaps adding a note that it may not be supported at this point.

Relevant gists: https://gist.github.com/demianbrecht/3fd60994eceeb3da8f13

----------

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

From report at bugs.python.org  Sat Mar  7 09:38:49 2015
From: report at bugs.python.org (koobs)
Date: Sat, 07 Mar 2015 08:38:49 +0000
Subject: [issue7352] pythonx.y-config --ldflags out of /usr and missing
 -L<install_lib_dir>
In-Reply-To: <1258578467.08.0.137292547946.issue7352@psf.upfronthosting.co.za>
Message-ID: <1425717529.85.0.798418689416.issue7352@psf.upfronthosting.co.za>


Changes by koobs <koobs.freebsd at gmail.com>:


----------
nosy: +koobs

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

From report at bugs.python.org  Sat Mar  7 10:01:58 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Mar 2015 09:01:58 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1425718918.79.0.617943462704.issue2211@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
status: languishing -> open

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

From report at bugs.python.org  Sat Mar  7 10:02:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Mar 2015 09:02:20 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1425718940.85.0.583554530293.issue2211@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld.

----------

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

From report at bugs.python.org  Sat Mar  7 10:11:05 2015
From: report at bugs.python.org (koobs)
Date: Sat, 07 Mar 2015 09:11:05 +0000
Subject: [issue7352] pythonx.y-config --ldflags out of /usr and missing
 -L<install_lib_dir>
In-Reply-To: <1258578467.08.0.137292547946.issue7352@psf.upfronthosting.co.za>
Message-ID: <1425719465.35.0.532045011835.issue7352@psf.upfronthosting.co.za>


koobs added the comment:

Still an issue on 2.7, 3.2, 3.3. Updating Versions to reflect this fact and assist downstreams in backporting a forthcoming fix to those versions that won't get it due to security-fix only branches.

See Also:

Issue: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197757
Patch: https://bz-attachments.freebsd.org/attachment.cgi?id=153794

----------
nosy: +haypo
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Sat Mar  7 10:11:42 2015
From: report at bugs.python.org (koobs)
Date: Sat, 07 Mar 2015 09:11:42 +0000
Subject: [issue7352] pythonx.y-config --ldflags out of /usr and missing
 -L<install_lib_dir>
In-Reply-To: <1258578467.08.0.137292547946.issue7352@psf.upfronthosting.co.za>
Message-ID: <1425719502.11.0.981122948383.issue7352@psf.upfronthosting.co.za>


koobs added the comment:

+nosy doko on ned_deily's advice

----------
nosy: +doko

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

From report at bugs.python.org  Sat Mar  7 10:43:42 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Mar 2015 09:43:42 +0000
Subject: [issue23584] test_doctest lineendings fails in verbose mode
In-Reply-To: <1425487231.91.0.280595585638.issue23584@psf.upfronthosting.co.za>
Message-ID: <1425721422.81.0.826815077222.issue23584@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
stage:  -> patch review
type:  -> behavior
versions: +Python 3.5

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

From report at bugs.python.org  Sat Mar  7 10:44:29 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Mar 2015 09:44:29 +0000
Subject: [issue23579] Amazon.com links
In-Reply-To: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>
Message-ID: <1425721469.89.0.887007671086.issue23579@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Mar  7 10:52:41 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Mar 2015 09:52:41 +0000
Subject: [issue21793] httplib client/server status refactor
In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za>
Message-ID: <20150307095237.117189.57420@psf.io>


Roundup Robot added the comment:

New changeset ad64b6a7c0e2 by Serhiy Storchaka in branch 'default':
Issue #21793: BaseHTTPRequestHandler again logs response code as numeric,
https://hg.python.org/cpython/rev/ad64b6a7c0e2

----------

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

From report at bugs.python.org  Sat Mar  7 10:55:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Mar 2015 09:55:30 +0000
Subject: [issue21793] httplib client/server status refactor
In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za>
Message-ID: <1425722130.67.0.11387467184.issue21793@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Martin for noticing a logging issue.

----------
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Mar  7 11:00:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Mar 2015 10:00:35 +0000
Subject: [issue23138] cookiejar parses cookie value as int with empty
 name-value pair and Expires
In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za>
Message-ID: <1425722435.51.0.134732575613.issue23138@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sat Mar  7 11:19:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Mar 2015 10:19:01 +0000
Subject: [issue23138] cookiejar parses cookie value as int with empty
 name-value pair and Expires
In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za>
Message-ID: <1425723541.77.0.456185727528.issue23138@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

According to RFC 6265, Section 5.2:

   2.  If the name-value-pair string lacks a %x3D ("=") character,
       ignore the set-cookie-string entirely.

But "Set-Cookie: spam; Expires=Thu, 01 Jan 1970 00:00:10 GMT" is accepted. key="spam", value=None.

   5.  If the name string is empty, ignore the set-cookie-string
       entirely.

But "Set-Cookie: =spam; Expires=Thu, 01 Jan 1970 00:00:10 GMT" is accepted. key="", value="spam".

----------

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

From report at bugs.python.org  Sat Mar  7 11:33:57 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 07 Mar 2015 10:33:57 +0000
Subject: [issue21793] httplib client/server status refactor
In-Reply-To: <1403031756.71.0.442697149496.issue21793@psf.upfronthosting.co.za>
Message-ID: <1425724437.13.0.588250385876.issue21793@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: commit review -> resolved

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

From report at bugs.python.org  Sat Mar  7 11:47:19 2015
From: report at bugs.python.org (=?utf-8?b?SMOla2FuIEzDtnZkYWhs?=)
Date: Sat, 07 Mar 2015 10:47:19 +0000
Subject: [issue23581] unittest.mock.MagicMock doesn't support matmul (@)
 operator
In-Reply-To: <1425461221.82.0.715365961896.issue23581@psf.upfronthosting.co.za>
Message-ID: <1425725239.39.0.643581795712.issue23581@psf.upfronthosting.co.za>


H?kan L?vdahl added the comment:

Here is a suggestion for a patch. It adds the missing matmul and has a small test for it.

----------
keywords: +patch
nosy: +H?kan L?vdahl
Added file: http://bugs.python.org/file38368/issue23581.patch

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

From report at bugs.python.org  Sat Mar  7 11:56:37 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 07 Mar 2015 10:56:37 +0000
Subject: [issue23581] unittest.mock.MagicMock doesn't support matmul (@)
 operator
In-Reply-To: <1425461221.82.0.715365961896.issue23581@psf.upfronthosting.co.za>
Message-ID: <1425725797.98.0.780775216604.issue23581@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Looks good. I'll tweak the patch and commit it. Thanks H?kan.

----------
stage:  -> patch review
type: behavior -> enhancement

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

From report at bugs.python.org  Sat Mar  7 12:03:07 2015
From: report at bugs.python.org (Julian Taylor)
Date: Sat, 07 Mar 2015 11:03:07 +0000
Subject: [issue23530] os and multiprocessing.cpu_count do not respect
 cpuset/affinity
In-Reply-To: <1424961054.13.0.0830068196807.issue23530@psf.upfronthosting.co.za>
Message-ID: <1425726187.25.0.474263949099.issue23530@psf.upfronthosting.co.za>


Julian Taylor added the comment:

attached documentation update patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file38369/0001-Issue-23530-Update-documentation-clarify-relation-of.patch

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

From report at bugs.python.org  Sat Mar  7 12:03:28 2015
From: report at bugs.python.org (Tuomas Suutari)
Date: Sat, 07 Mar 2015 11:03:28 +0000
Subject: [issue22154] ZipFile.open context manager support
In-Reply-To: <1407311800.94.0.537081542584.issue22154@psf.upfronthosting.co.za>
Message-ID: <1425726208.81.0.52396667628.issue22154@psf.upfronthosting.co.za>


Tuomas Suutari added the comment:

The context manager support was added on issue #5511, so the documentation should go to 2.7, 3.4 and default. Also the version added notes should be added.

----------
nosy: +Tuomas Suutari

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

From report at bugs.python.org  Sat Mar  7 12:10:51 2015
From: report at bugs.python.org (Tuomas Suutari)
Date: Sat, 07 Mar 2015 11:10:51 +0000
Subject: [issue23460] Decimals do not obey ':g' exponential notation
 formatting rules
In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za>
Message-ID: <1425726651.28.0.0462891855827.issue23460@psf.upfronthosting.co.za>


Tuomas Suutari added the comment:

Here's a patch that fixes the description for 'g' to explain what happens for `Decimal` and also documents the Decimal.__format__ in the documentation of the decimal module.

----------
keywords: +patch
nosy: +Tuomas Suutari
Added file: http://bugs.python.org/file38370/issue23460.patch

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

From report at bugs.python.org  Sat Mar  7 12:24:41 2015
From: report at bugs.python.org (Julian Taylor)
Date: Sat, 07 Mar 2015 11:24:41 +0000
Subject: [issue23601] use small object allocator for dict key storage
Message-ID: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za>


New submission from Julian Taylor:

dictionary creation spends a not insignificant amount of time in malloc allocating keys objects. Python has a nice small object allocator that avoids a lot of this overhead and falls back to malloc for larger allocations.
Is there a reason the dictionary does not use that allocator for its keys objects?
doing so e.g. via attached incomplete patch improves small dict creation performance by 15%.

import  timeit
print(timeit.repeat("dict(a=5, b=2)"))

with change:
[0.42825599999923725, 0.4272580000015296, 0.4362329999985377]
without
[0.5160610000002634, 0.5181720000000496, 0.518421999999191]


or is there something I am overlooking and the use of PyMem_Malloc instead of PyObject_Malloc is an intentional design decision?

----------
components: Interpreter Core
files: 0001-use-small-object-allocator-for-keys-object.patch
keywords: patch
messages: 237439
nosy: jtaylor
priority: normal
severity: normal
status: open
title: use small object allocator for dict key storage
versions: Python 3.5
Added file: http://bugs.python.org/file38371/0001-use-small-object-allocator-for-keys-object.patch

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

From report at bugs.python.org  Sat Mar  7 12:33:17 2015
From: report at bugs.python.org (Peter J C Law)
Date: Sat, 07 Mar 2015 11:33:17 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1425727997.55.0.850666894118.issue23600@psf.upfronthosting.co.za>


Peter J C Law added the comment:

Hi,

Sorry for the overkill demo. I've attached a much shorter version, the key portion of which seems to be that, for the case of UK summer time the timezone, the tzinfo's `dst()` and `utcoffset()` methods return the same value.

This results in the delta between the two (which my understanding suggests equates to the non-dst offset of the timezone) is zero (which is right).

The python implementations (both in datetime.py and in the docs) cope with this by checking the DST difference and applying this after the timezone adjustments have happened.

>From a look through the CPython implementation, it looks to me like it's checking the wrong value before applying the DST difference. Specifically, on line 3033 in Modules/_datetimemodule.c, it checks `delta` before applying the DST.

For the majority of timezones this happens to work since the standard offset is not 0 and it ends up doing the addition anyway (and no functionality is lost if the DST value is 0).

Having tested changing the checked value to being dst rather than delta this does appear to fix this and all the existing tests still pass.

Peter

----------
Added file: http://bugs.python.org/file38372/time_issues.py

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

From report at bugs.python.org  Sat Mar  7 12:40:40 2015
From: report at bugs.python.org (SilentGhost)
Date: Sat, 07 Mar 2015 11:40:40 +0000
Subject: [issue23601] use small object allocator for dict key storage
In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za>
Message-ID: <1425728440.44.0.513503153638.issue23601@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +lemburg, tim.peters

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

From report at bugs.python.org  Sat Mar  7 12:48:40 2015
From: report at bugs.python.org (Peter Otten)
Date: Sat, 07 Mar 2015 11:48:40 +0000
Subject: [issue23551] IDLE to provide menu options for using PIP
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1425728920.29.0.917717649758.issue23551@psf.upfronthosting.co.za>


Changes by Peter Otten <__peter__ at web.de>:


----------
nosy: +peter.otten

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

From report at bugs.python.org  Sat Mar  7 12:57:16 2015
From: report at bugs.python.org (Peter Otten)
Date: Sat, 07 Mar 2015 11:57:16 +0000
Subject: [issue23495] The writer.writerows method should be documented as
 accepting any iterable (not only a list)
In-Reply-To: <1424465153.78.0.58816335685.issue23495@psf.upfronthosting.co.za>
Message-ID: <1425729436.65.0.376650883591.issue23495@psf.upfronthosting.co.za>


Changes by Peter Otten <__peter__ at web.de>:


----------
nosy: +peter.otten

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

From report at bugs.python.org  Sat Mar  7 13:04:08 2015
From: report at bugs.python.org (=?utf-8?b?SMOla2FuIEzDtnZkYWhs?=)
Date: Sat, 07 Mar 2015 12:04:08 +0000
Subject: [issue23568] unittest.mock.MagicMock doesn't support __rdivmod__
In-Reply-To: <1425371785.99.0.969035398065.issue23568@psf.upfronthosting.co.za>
Message-ID: <1425729848.24.0.742425101209.issue23568@psf.upfronthosting.co.za>


H?kan L?vdahl added the comment:

I wrote a small patch and a test for it. Tested it on Python 3.5 and it worked.

----------
keywords: +patch
nosy: +H?kan L?vdahl
Added file: http://bugs.python.org/file38373/issue23568.patch

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

From report at bugs.python.org  Sat Mar  7 13:48:33 2015
From: report at bugs.python.org (Mark Shannon)
Date: Sat, 07 Mar 2015 12:48:33 +0000
Subject: [issue23601] use small object allocator for dict key storage
In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za>
Message-ID: <1425732513.36.0.442585883181.issue23601@psf.upfronthosting.co.za>


Changes by Mark Shannon <mark at hotpy.org>:


----------
nosy: +Mark.Shannon

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

From report at bugs.python.org  Sat Mar  7 13:57:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Mar 2015 12:57:11 +0000
Subject: [issue23601] use small object allocator for dict key storage
In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za>
Message-ID: <1425733031.66.0.151074755919.issue23601@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue16465.

----------
nosy: +pitrou, rhettinger, serhiy.storchaka

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

From report at bugs.python.org  Sat Mar  7 14:05:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Mar 2015 13:05:23 +0000
Subject: [issue23103] Reduce memory usage for ipaddress object instances
In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za>
Message-ID: <1425733523.96.0.325627664027.issue23103@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Nick, what is your thoughts about the patch?

----------

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

From report at bugs.python.org  Sat Mar  7 14:06:22 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Mar 2015 13:06:22 +0000
Subject: [issue23601] use small object allocator for dict key storage
In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za>
Message-ID: <1425733582.04.0.922013376096.issue23601@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Interesting. I can reproduce the speedup on 64-bit Linux (Ubuntu 14.10).

----------
stage:  -> patch review
type:  -> performance

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

From report at bugs.python.org  Sat Mar  7 14:16:49 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Mar 2015 13:16:49 +0000
Subject: [issue23601] use small object allocator for dict key storage
In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za>
Message-ID: <1425734209.79.0.768121706186.issue23601@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

$ ./python -m timeit "dict(a=5, b=2)"
Unpatched:         100000 loops, best of 3: 2.5 usec per loop
issue16465 patch: 1000000 loops, best of 3: 1.87 usec per loop
issue23601 patch: 1000000 loops, best of 3: 1.98 usec per loop

----------

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

From report at bugs.python.org  Sat Mar  7 14:25:35 2015
From: report at bugs.python.org (Ben Hoyt)
Date: Sat, 07 Mar 2015 13:25:35 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <1425734735.94.0.098368164335.issue22524@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

Oops, I'm sorry re previous comment -- looks like I forgot to attach scandir-8.patch. Now attached. Please re-read my previous comment and review. :-)

----------
Added file: http://bugs.python.org/file38374/scandir-8.patch

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

From report at bugs.python.org  Sat Mar  7 14:43:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Mar 2015 13:43:02 +0000
Subject: [issue19610] setup.py does not allow a tuple for classifiers
In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za>
Message-ID: <1425735782.12.0.953498746812.issue19610@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch changes this.

----------

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

From report at bugs.python.org  Sat Mar  7 14:43:18 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 07 Mar 2015 13:43:18 +0000
Subject: [issue23601] use small object allocator for dict key storage
In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za>
Message-ID: <1425735798.04.0.747732037604.issue23601@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

There seem to be quite a few other places where this simple optimization could make sense as well, perhaps even going as far
as converting all uses of PyMem_MALLOC to PyObject_MALLOC.

There was a time when the small memory allocator did not return
free arenas to the system allocator, but those are long ago.

The only detail to watch out for is not mixing the malloc/free APIs. In particular, memory which is allocated in the interpreter and then deallocated elsewhere in extensions needs to continue using the PyMem_* APIs.

----------

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

From report at bugs.python.org  Sat Mar  7 15:35:20 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Mar 2015 14:35:20 +0000
Subject: [issue23579] Amazon.com links
In-Reply-To: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>
Message-ID: <20150307143503.1369.17647@psf.io>


Roundup Robot added the comment:

New changeset 5903ab233a1d by Benjamin Peterson in branch '3.4':
replace Amazon links in the documentation (closes #23579)
https://hg.python.org/cpython/rev/5903ab233a1d

New changeset 4ad1ea911fd0 by Benjamin Peterson in branch '2.7':
replace Amazon links in the documentation (closes #23579)
https://hg.python.org/cpython/rev/4ad1ea911fd0

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Mar  7 15:43:56 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Mar 2015 14:43:56 +0000
Subject: [issue22928] HTTP header injection in
 urrlib2/urllib/httplib/http.client
In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za>
Message-ID: <1425739436.06.0.587537118573.issue22928@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld.

Is there a limit to the length of header line? Would not unfolding all header values exceed the limit?

----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sat Mar  7 16:02:41 2015
From: report at bugs.python.org (Alistair Lynn)
Date: Sat, 07 Mar 2015 15:02:41 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1425740561.47.0.396263833.issue23600@psf.upfronthosting.co.za>


Changes by Alistair Lynn <arplynn at gmail.com>:


----------
nosy: +alynn

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

From report at bugs.python.org  Sat Mar  7 16:17:05 2015
From: report at bugs.python.org (=?utf-8?b?SMOla2FuIEzDtnZkYWhs?=)
Date: Sat, 07 Mar 2015 15:17:05 +0000
Subject: [issue16462] smtpd should return greeting
In-Reply-To: <1352732891.73.0.549374987784.issue16462@psf.upfronthosting.co.za>
Message-ID: <1425741425.78.0.366138382155.issue16462@psf.upfronthosting.co.za>


Changes by H?kan L?vdahl <hlovdahl at gmail.com>:


----------
nosy: +H?kan L?vdahl

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

From report at bugs.python.org  Sat Mar  7 16:31:16 2015
From: report at bugs.python.org (Davin Potts)
Date: Sat, 07 Mar 2015 15:31:16 +0000
Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if
 sem_open is not implemented
In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za>
Message-ID: <1425742276.68.0.204359401077.issue23400@psf.upfronthosting.co.za>


Davin Potts added the comment:

Attaching updated single patch for both default/3.5 and 3.4 to use Serhiy's insightful simplification.

This updated patch has been tested on current Debian Hurd (see earlier comments about full battery of tests there) and OS X 10.10 (full, verbose tests).

Note that the patch for 2.7 does not need a similar update as it contains purely documentation and no code changes.

Thanks goes to Serhiy and Berker for their thoughtful reviews and follow-ups.

----------
Added file: http://bugs.python.org/file38375/issue23400_py35_and_py34_furtherimproveddocsandstyle.patch

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

From report at bugs.python.org  Sat Mar  7 16:40:21 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 07 Mar 2015 15:40:21 +0000
Subject: [issue21779] test_multiprocessing_spawn fails when ran with -Werror
In-Reply-To: <1402932904.12.0.0907209632693.issue21779@psf.upfronthosting.co.za>
Message-ID: <1425742821.35.0.259134483365.issue21779@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

This can be reproduced on Windows 8.1.

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Sat Mar  7 16:41:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Mar 2015 15:41:55 +0000
Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()]
 deadlock
In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za>
Message-ID: <1425742915.59.0.145515109677.issue23051@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

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

From report at bugs.python.org  Sat Mar  7 16:42:26 2015
From: report at bugs.python.org (=?utf-8?b?SMOla2FuIEzDtnZkYWhs?=)
Date: Sat, 07 Mar 2015 15:42:26 +0000
Subject: [issue21800] Implement RFC 6855 (IMAP Support for UTF-8) in imaplib.
In-Reply-To: <1404175815.98.0.684783714649.issue21800@psf.upfronthosting.co.za>
Message-ID: <1425742946.6.0.236188637568.issue21800@psf.upfronthosting.co.za>


Changes by H?kan L?vdahl <hlovdahl at gmail.com>:


----------
nosy: +H?kan L?vdahl

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

From report at bugs.python.org  Sat Mar  7 16:46:04 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 07 Mar 2015 15:46:04 +0000
Subject: [issue21992] New AST node Else() should be introduced
In-Reply-To: <1405527228.32.0.961029538035.issue21992@psf.upfronthosting.co.za>
Message-ID: <1425743164.81.0.154327902493.issue21992@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

The referenced issue1659410 has been closed as "too late".  Does that also apply here or is this still considered to be a valid enhancement request?

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 2.7

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

From report at bugs.python.org  Sat Mar  7 17:02:05 2015
From: report at bugs.python.org (Davin Potts)
Date: Sat, 07 Mar 2015 16:02:05 +0000
Subject: [issue21779] test_multiprocessing_spawn fails when ran with -Werror
In-Reply-To: <1402932904.12.0.0907209632693.issue21779@psf.upfronthosting.co.za>
Message-ID: <1425744125.32.0.689838558111.issue21779@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


----------
nosy: +davin

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

From report at bugs.python.org  Sat Mar  7 17:06:29 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 07 Mar 2015 16:06:29 +0000
Subject: [issue22227] Simplify tarfile iterator
In-Reply-To: <1408435555.43.0.257116130786.issue22227@psf.upfronthosting.co.za>
Message-ID: <1425744389.69.0.840883836593.issue22227@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

LGTM at a quick glance.  Can we have a formal patch review please.

----------
nosy: +BreamoreBoy

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

From report at bugs.python.org  Sat Mar  7 17:13:23 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 07 Mar 2015 16:13:23 +0000
Subject: [issue22268] add dedicated functions mrohasattr and mrogetattr
In-Reply-To: <1408918667.95.0.696624554898.issue22268@psf.upfronthosting.co.za>
Message-ID: <1425744803.25.0.252290054167.issue22268@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
title: mrohasattr and mrogetattr -> add dedicated functions mrohasattr and mrogetattr

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

From report at bugs.python.org  Sat Mar  7 17:18:57 2015
From: report at bugs.python.org (Davin Potts)
Date: Sat, 07 Mar 2015 16:18:57 +0000
Subject: [issue21162] code in multiprocessing.pool freeze if inside some code
 from scikit-learn (and probably liblinear) executed on ubuntu
 12.04 64 Bit
In-Reply-To: <1396716060.12.0.828109902525.issue21162@psf.upfronthosting.co.za>
Message-ID: <1425745137.79.0.635533374652.issue21162@psf.upfronthosting.co.za>


Davin Potts added the comment:

I am unable to reproduce the described behavior using the script provided in that gist using Python 2.7.9 on OS X 10.10 with scikit-learn 0.15.2, scipy 0.14.0, numpy 1.9.0.

For me, the sample code runs happily through to completion.

Can the OP still reproduce the behavior?  If not, it looks like scikit-learn and scipy have changed in the interim, addressing this behavior.

----------
nosy: +davin
status: open -> pending
type:  -> behavior

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

From report at bugs.python.org  Sat Mar  7 17:40:30 2015
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Sat, 07 Mar 2015 16:40:30 +0000
Subject: [issue23551] IDLE to provide menu options for using PIP
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1425746430.88.0.875372077092.issue23551@psf.upfronthosting.co.za>


Saimadhav Heblikar added the comment:

For the initial version here is what I plan to code:
A single package manager entry in a suitable menu. This would open a dialog window
containing options for (inspired from msg236906).
    1. Show installed packages(freeze)
        This menu would have options to update and remove the said package.
    2. Install package 
        The user may specify an url, paste a requirements.txt type file or
        point to a requirements.txt file.
    3. Settings
       Change install directory 

    The user will be able to update/revert to a specific version.
    Incase of an error, the error message which would be have been printed to the terminal will be displayed to the user in a dialog box.

Any changes made to packages would be for the version using which IDLE was started.

Also, what do you feel about support from non-PyPI repositories like github? Do we intend to support everything pip supports or only a subset of it (say PyPI)?

For this initial version, I would like to keep cloning across versions for later version. For now these are the things I would like to get right first.

----------

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

From report at bugs.python.org  Sat Mar  7 17:41:34 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Mar 2015 16:41:34 +0000
Subject: [issue23144] html.parser.HTMLParser: setting 'convert_charrefs =
 True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1425746494.16.0.47780449049.issue23144@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Here is a patch that fixes the problem.
Even though calling .close() is the correct solution, I preferred to restore the previous behavior and call handle_data as soon as possible.
There is a corner case in which a charref might be cut in half while feeding chunks to the parser -- in that case the parser will wait and it might still be necessary to call .close() if an incomplete charref is at the end of the string.
Adding context manager support to HTMLParser might also help solving the problem, but that's a separate issue.
(Also thanks to Serhiy for the feedback he provided me on IRC.)

----------
keywords: +patch
nosy: +serhiy.storchaka
stage:  -> commit review
versions: +Python 2.7, Python 3.5
Added file: http://bugs.python.org/file38376/issue23144.diff

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

From report at bugs.python.org  Sat Mar  7 17:49:56 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Mar 2015 16:49:56 +0000
Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()]
 deadlock
In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za>
Message-ID: <1425746996.39.0.251248611597.issue23051@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be the code would cleaner when convert the "for" loop to the "while" loop and wrap in try/except only next()?

----------
Added file: http://bugs.python.org/file38377/issue_23051_4-3.4.patch

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

From report at bugs.python.org  Sat Mar  7 17:57:51 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Mar 2015 16:57:51 +0000
Subject: [issue17570] Improve devguide Windows instructions
In-Reply-To: <1364523214.84.0.368819983889.issue17570@psf.upfronthosting.co.za>
Message-ID: <1425747471.62.0.260296842654.issue17570@psf.upfronthosting.co.za>


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


----------
nosy: +steve.dower

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

From report at bugs.python.org  Sat Mar  7 17:58:37 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Mar 2015 16:58:37 +0000
Subject: [issue23103] Reduce memory usage for ipaddress object instances
In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za>
Message-ID: <1425747517.06.0.480950369882.issue23103@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

+1 from me, although since we're committing to preserving the weakref support for compatibility reasons now, I'm wondering if we should also add a test for it.

----------

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

From report at bugs.python.org  Sat Mar  7 18:06:09 2015
From: report at bugs.python.org (Tuomas Suutari)
Date: Sat, 07 Mar 2015 17:06:09 +0000
Subject: [issue23602] Implement __format__ for Fraction
Message-ID: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>


New submission from Tuomas Suutari:

Since Decimal supports __format__, it would be nice that Fraction did too.

----------
components: Library (Lib)
messages: 237460
nosy: tuomas.suutari
priority: normal
severity: normal
status: open
title: Implement __format__ for Fraction
versions: Python 3.5

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

From report at bugs.python.org  Sat Mar  7 18:07:26 2015
From: report at bugs.python.org (Tuomas Suutari)
Date: Sat, 07 Mar 2015 17:07:26 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1425748046.65.0.838665540395.issue23602@psf.upfronthosting.co.za>


Tuomas Suutari added the comment:

Here's a patch that adds Fraction.__format__ implementation, test cases and documentation.

----------
keywords: +patch
Added file: http://bugs.python.org/file38378/issue23602.patch

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

From report at bugs.python.org  Sat Mar  7 18:22:30 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Mar 2015 17:22:30 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1425748950.29.0.414554074668.issue23602@psf.upfronthosting.co.za>


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


----------
nosy: +eric.smith, ezio.melotti, mark.dickinson, rhettinger, skrah
stage:  -> patch review
type:  -> enhancement

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

From report at bugs.python.org  Sat Mar  7 18:33:39 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Mar 2015 17:33:39 +0000
Subject: [issue21992] New AST node Else() should be introduced
In-Reply-To: <1405527228.32.0.961029538035.issue21992@psf.upfronthosting.co.za>
Message-ID: <1425749619.95.0.316640316744.issue21992@psf.upfronthosting.co.za>


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


----------
nosy: +georg.brandl

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

From report at bugs.python.org  Sat Mar  7 18:33:56 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Mar 2015 17:33:56 +0000
Subject: [issue13583] sqlite3.Row doesn't support slice indexes
In-Reply-To: <1323639948.36.0.717803065724.issue13583@psf.upfronthosting.co.za>
Message-ID: <1425749636.86.0.762450092304.issue13583@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch with much simpler implementation.

----------
components: +Extension Modules
Added file: http://bugs.python.org/file38379/sqlite3_row_slice.patch

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

From report at bugs.python.org  Sat Mar  7 18:41:26 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Mar 2015 17:41:26 +0000
Subject: [issue7352] pythonx.y-config --ldflags out of /usr and missing
 -L<install_lib_dir>
In-Reply-To: <1258578467.08.0.137292547946.issue7352@psf.upfronthosting.co.za>
Message-ID: <1425750086.58.0.977314932207.issue7352@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy

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

From report at bugs.python.org  Sat Mar  7 18:50:10 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Mar 2015 17:50:10 +0000
Subject: [issue23144] html.parser.HTMLParser: setting 'convert_charrefs =
 True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1425750610.66.0.965678673936.issue23144@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file38376/issue23144.diff

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

From report at bugs.python.org  Sat Mar  7 18:50:40 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Mar 2015 17:50:40 +0000
Subject: [issue23144] html.parser.HTMLParser: setting 'convert_charrefs =
 True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1425750640.17.0.592220007597.issue23144@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file38380/issue23144.diff

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

From report at bugs.python.org  Sat Mar  7 18:59:09 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Mar 2015 17:59:09 +0000
Subject: [issue23551] IDLE to provide menu options for using PIP
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1425751149.08.0.660552698136.issue23551@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

On Windows, I think we should consider directly supportting
http://www.lfd.uci.edu/~gohlke/pythonlibs/
Unofficial Windows Binaries for Python Extension Packages
When possible, this has 2.6, 2.7, 3.3, and 3.4 binaries for 32 and 64 bits.

I and others use this site, but beginners would not know to use it.  Since last summer, Christoph has switched nearly all files from .zip to pip-installable .whl.  The site says to download and point pip to the local downloaded copy, but I presume pip can be directly pointed to the site.

----------

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

From report at bugs.python.org  Sat Mar  7 19:00:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Mar 2015 18:00:22 +0000
Subject: [issue23103] Reduce memory usage for ipaddress object instances
In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za>
Message-ID: <1425751222.16.0.737548501373.issue23103@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

OK. But I hesitate that weakref support is useful for IP addresses.

----------
assignee:  -> serhiy.storchaka

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

From report at bugs.python.org  Sat Mar  7 19:01:30 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Mar 2015 18:01:30 +0000
Subject: [issue23551] IDLE to provide menu options for using PIP
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1425751290.39.0.380840514421.issue23551@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

PS. I am fine with your initial plan.

----------

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

From report at bugs.python.org  Sat Mar  7 19:09:16 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Mar 2015 18:09:16 +0000
Subject: [issue23103] Reduce memory usage for ipaddress object instances
In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za>
Message-ID: <20150307180913.19097.20793@psf.io>


Roundup Robot added the comment:

New changeset 88a5c1698ca4 by Serhiy Storchaka in branch 'default':
Issue #23103: Reduced the memory consumption of IPv4Address and IPv6Address.
https://hg.python.org/cpython/rev/88a5c1698ca4

----------
nosy: +python-dev

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

From report at bugs.python.org  Sat Mar  7 19:09:22 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 07 Mar 2015 18:09:22 +0000
Subject: [issue23551] IDLE to provide menu options for using PIP
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1425751762.81.0.215426837288.issue23551@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I really do think we should support Christoph's site.  It has saved me many a headache over the years.  For beginners it's also got to be preferable to seeing the rather cryptic "Unable to find vcvarsall.bat" message, plus how many of them want to install VS?

----------
nosy: +BreamoreBoy

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

From report at bugs.python.org  Sat Mar  7 19:15:56 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Mar 2015 18:15:56 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1425752156.63.0.740194302931.issue23602@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

>>> from fractions import Fraction as F
>>> format(F(1, 3), '.30f')
'0.333333333333333333333333333300'

----------
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Sat Mar  7 19:19:29 2015
From: report at bugs.python.org (Mark Shannon)
Date: Sat, 07 Mar 2015 18:19:29 +0000
Subject: [issue21992] New AST node Else() should be introduced
In-Reply-To: <1405527228.32.0.961029538035.issue21992@psf.upfronthosting.co.za>
Message-ID: <1425752369.61.0.490305934963.issue21992@psf.upfronthosting.co.za>


Mark Shannon added the comment:

I would say yes, it is too late. Any change to the AST is a breaking change.

The current AST is full of missing line numbers, incorrect column offsets and other inconsistencies. To fix them all would be a major undertaking with no obvious benefit to the core interpreter.

If you are interested in implementing a parser with proper location information, I would suggest discussing it on the code-quality mailing list:
https://mail.python.org/mailman/listinfo/code-quality

----------
nosy: +Mark.Shannon

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

From report at bugs.python.org  Sat Mar  7 20:12:06 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Sat, 07 Mar 2015 19:12:06 +0000
Subject: [issue4851] xml.dom.minidom.Element.cloneNode fails with
 AttributeError
In-Reply-To: <1231192810.66.0.263343969898.issue4851@psf.upfronthosting.co.za>
Message-ID: <1425755526.43.0.128441186985.issue4851@psf.upfronthosting.co.za>


Changes by Claudiu Popa <pcmanticore at gmail.com>:


----------
nosy: +Claudiu.Popa
versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Mar  7 20:20:47 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 07 Mar 2015 19:20:47 +0000
Subject: [issue22455] idna/punycode give wrong results on narrow builds
In-Reply-To: <1411337375.42.0.97875155095.issue22455@psf.upfronthosting.co.za>
Message-ID: <1425756047.1.0.135174066265.issue22455@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

As 2.7 is to be supported until 2020 and a potential fix is available shouldn't we be using it?

----------
nosy: +BreamoreBoy

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

From report at bugs.python.org  Sat Mar  7 20:36:52 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 07 Mar 2015 19:36:52 +0000
Subject: [issue23279] test_site/test_startup_imports fails when mpl_toolkit or
 logilab based modules installed
In-Reply-To: <1421729308.95.0.570059573722.issue23279@psf.upfronthosting.co.za>
Message-ID: <1425757012.09.0.927620377474.issue23279@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I've added names from the nosy list for #20986 as it appears to be similar.

----------
nosy: +BreamoreBoy, brett.cannon, christian.heimes, ncoghlan, vinay.sajip

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

From report at bugs.python.org  Sat Mar  7 20:58:08 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Sat, 07 Mar 2015 19:58:08 +0000
Subject: [issue13397] Option for XMLRPC clients to automatically transform
 Fault exceptions into standard exceptions
In-Reply-To: <1321218030.66.0.0560016220773.issue13397@psf.upfronthosting.co.za>
Message-ID: <1425758288.47.0.626177846454.issue13397@psf.upfronthosting.co.za>


Changes by Claudiu Popa <pcmanticore at gmail.com>:


----------
nosy:  -Claudiu.Popa

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

From report at bugs.python.org  Sat Mar  7 21:02:06 2015
From: report at bugs.python.org (Ashish Sadanandan)
Date: Sat, 07 Mar 2015 20:02:06 +0000
Subject: [issue23603] MinGW-64
Message-ID: <1425758526.01.0.875818979723.issue23603@psf.upfronthosting.co.za>


New submission from Ashish Sadanandan:

I'm trying to embed Python 3.4.3 (x64) in a program compiled using MinGW-W64 g++ 4.9.2 (output from "g++ -v" attached) and Boost.Python 1.57.0. A simple example kept crashing at runtime and I managed to track it down to this testcase (which is not using Boost.Python but demonstrates why a check in Boost is failing). `python34.zip` in the `Py_SetPath()` call is a zip archive containing the entire contents of the `Lib` directory in my Python3.4 installation.


		#include <Python.h>
		#include <iostream>

		int main()
		{
			Py_SetPath(L"python34.zip");
			Py_Initialize();

			PyObject *s = PyUnicode_FromString("Hello World");
			std::cout << PyUnicode_Check(s) << std::endl;
			std::cout << PyUnicode_CheckExact(s) << std::endl;
			std::cout << PyUnicode_AsUTF8(s) << std::endl;

			PyRun_SimpleString("from time import time, ctime\n"
							   "print('Today is', ctime(time())\n)");

			Py_Finalize();
		}


I compile this using

                g++ -ID:/Tools/Python/3.4/x64/include -O0 -g3 -pedantic -Wall -Wextra -std=c++14 test.cpp -LD:/Tools/Python/3.4/x64/libs -lpython34 -o test.exe

Running test.exe results in

                0
                1
                Hello World
                Today is Sat Mar  7 12:06:53 2015

The problem is the first line of output. Creating a `PyObject` using `PyUnicode_FromString()` and then calling `PyUnicode_Check()` on the earlier result is returning `0`. The cause of this is that the `tp_flags` field somewhere within `PyObject` is `0` and `PyUnicode_Check()` performs a bitand with that and returns `0`. If I understand the docs correctly, when `PyUnicode_CheckExact()` returns true, `PyUnicode_Check()` should also return true because the former is a more stringent check than the latter.

Additional details that may or may not be relevant. I followed these steps to create `libpython34.a` for linking with g++. From an MSYS prompt 

                $ gendef.exe /C/Windows/System32/python34.dll
                $ dlltool --dllname /C/Windows/System32/python34.dll --def python34.def --output-lib libpython34.a

I also tried downloading libpython34.a from Christoph Gohlke's website (http://www.lfd.uci.edu/~gohlke/pythonlibs/#libpython) but that produces the same result.

Is this a bug, or do I not understand what `PyUnicode_Check()` is supposed to do?

----------
components: Extension Modules
files: g++dashv.txt
messages: 237472
nosy: Ashish Sadanandan
priority: normal
severity: normal
status: open
title: MinGW-64
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file38381/g++dashv.txt

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

From report at bugs.python.org  Sat Mar  7 21:03:00 2015
From: report at bugs.python.org (Mark Shannon)
Date: Sat, 07 Mar 2015 20:03:00 +0000
Subject: [issue23601] use small object allocator for dict key storage
In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za>
Message-ID: <1425758580.65.0.595454180374.issue23601@psf.upfronthosting.co.za>


Mark Shannon added the comment:

I don't remember why PyMem_Malloc rather than PyObject_MALLOC was used, it may have been inherited from the allocation of dict tables in the earlier implementation.

My only concern is that the benchmark only tests performance for very small dictionaries. The small object allocator is limited to 512 bytes before it falls back on malloc, so for larger dict keys the speed up would vanish.

A benchmark with a range of sizes would be more convincing, if only to show that it is no slower for larger dicts.

----------

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

From report at bugs.python.org  Sat Mar  7 21:03:55 2015
From: report at bugs.python.org (Ashish Sadanandan)
Date: Sat, 07 Mar 2015 20:03:55 +0000
Subject: [issue23603] MinGW-64 and embedding Python3.4
In-Reply-To: <1425758526.01.0.875818979723.issue23603@psf.upfronthosting.co.za>
Message-ID: <1425758635.36.0.704286398801.issue23603@psf.upfronthosting.co.za>


Changes by Ashish Sadanandan <ashish.sadanandan at gmail.com>:


----------
title: MinGW-64 -> MinGW-64 and embedding Python3.4

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

From report at bugs.python.org  Sat Mar  7 21:07:44 2015
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 07 Mar 2015 20:07:44 +0000
Subject: [issue7352] pythonx.y-config --ldflags out of /usr and missing
 -L<install_lib_dir>
In-Reply-To: <1258578467.08.0.137292547946.issue7352@psf.upfronthosting.co.za>
Message-ID: <1425758864.9.0.59611156394.issue7352@psf.upfronthosting.co.za>


Matthias Klose added the comment:

this seems to work for me:

$ python-config --ldflags
-L/usr/lib/python2.7/config-x86_64-linux-gnu -L/usr/lib -lpython2.7 -lpthread -ldl  -lutil -lm  -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions

the patch is incomplete, no patch for the shell script is provided.

----------

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

From report at bugs.python.org  Sat Mar  7 21:32:11 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Sat, 07 Mar 2015 20:32:11 +0000
Subject: [issue22522] sys.excepthook doesn't receive the traceback when called
 from code.InteractiveInterpreter
In-Reply-To: <1412076539.24.0.326910714196.issue22522@psf.upfronthosting.co.za>
Message-ID: <1425760331.75.0.603978912616.issue22522@psf.upfronthosting.co.za>


Claudiu Popa added the comment:

This was fixed by a different patch in https://hg.python.org/cpython/rev/5f3dd0a2b1ab

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Mar  7 21:48:33 2015
From: report at bugs.python.org (Daiyue Weng)
Date: Sat, 07 Mar 2015 20:48:33 +0000
Subject: [issue23604] Python 3.4 and 2.7 installation no Script folder and no
 pip installed
Message-ID: <1425761313.01.0.208884407276.issue23604@psf.upfronthosting.co.za>


New submission from Daiyue Weng:

Hi, I was doing a fresh installation for Python 2.7.9 (32 bit) and 3.4.3 (32 bit) (downloaded from PSF) on Win7 X64 today, and I found that there is no 'Script' folder in 'Python27' and 'Python34' folder as first child level folder, but there is one in Tools. However, I couldn't find pip within that 'Script' folder, although pip should be installed with Python by default. The other I was doing the same installation for my other PC and laptop, there was 'Script' folder (as first level child folder in 'Python27' and 'Python34') containing pip. So what is going on? how to install pip and maybe other useful scripts this way? 

'C:\Pythonxy\Lib\site-packages' contains nothing but a README file. I tried 'python -m ensurepip' in 'C:\Python34'. I got the following errors: 

Ignoring indexes: https://pypi.python.org/simple 
Collecting setuptools 
 Exception: 
 Traceback (most recent call last): 
File "C:\Users\daiyue\AppData\Local\Temp\tmppvmc8dv1\pip-6.0.8-py2.py3-none- 
any.whl\pip\basecommand.py", line 232, in main 
  status = self.run(options, args) 
File "C:\Users\daiyue\AppData\Local\Temp\tmppvmc8dv1\pip-6.0.8-py2.py3-none- 
any.whl\pip\commands\install.py", line 339, in run 
  requirement_set.prepare_files(finder) 
File "C:\Users\daiyue\AppData\Local\Temp\tmppvmc8dv1\pip-6.0.8-py2.py3-none- 
any.whl\pip\req\req_set.py", line 333, in prepare_files 
  upgrade=self.upgrade, 
File "C:\Users\daiyue\AppData\Local\Temp\tmppvmc8dv1\pip-6.0.8-py2.py3-none- 
any.whl\pip\index.py", line 326, in find_requirement 
  file_locations, url_locations = self._sort_locations(locations) 
File "C:\Users\daiyue\AppData\Local\Temp\tmppvmc8dv1\pip-6.0.8-py2.py3-none- 
any.whl\pip\index.py", line 158, in _sort_locations 
  sort_path(os.path.join(path, item)) 
File "C:\Users\daiyue\AppData\Local\Temp\tmppvmc8dv1\pip-6.0.8-py2.py3-none- 
any.whl\pip\index.py", line 139, in sort_path 
  if mimetypes.guess_type(url, strict=False)[0] == 'text/html': 
File "C:\Python34\lib\mimetypes.py", line 287, in guess_type 
  init() 
File "C:\Python34\lib\mimetypes.py", line 348, in init 
  db.read_windows_registry() 
File "C:\Python34\lib\mimetypes.py", line 255, in read_windows_registry 
  with _winreg.OpenKey(hkcr, subkeyname) as subkey: 
TypeError: OpenKey() argument 2 must be str without null characters or None,  not str 

I also tried 'python -m ensurepip' in 'C:\Python27'. I got some errors in Users\user_name\pip log file:

------------------------------------------------------------
C:\Python27\lib\ensurepip\__main__.py run on 03/07/15 01:47:03
Ignoring indexes: https://pypi.python.org/simple/
Downloading/unpacking setuptools
Cleaning up...
  Removing temporary dir c:\users\daiyue\appdata\local\temp\pip_build_daiyue...
Exception:
Traceback (most recent call last):
  File "c:\users\daiyue\appdata\local\temp\tmpxji_co\pip-1.5.6-py2.py3-none-any.whl\pip\basecommand.py", line 122, in main
    status = self.run(options, args)
  File "c:\users\daiyue\appdata\local\temp\tmpxji_co\pip-1.5.6-py2.py3-none-any.whl\pip\commands\install.py", line 278, in run
    requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bundle=self.bundle)
  File "c:\users\daiyue\appdata\local\temp\tmpxji_co\pip-1.5.6-py2.py3-none-any.whl\pip\req.py", line 1177, in prepare_files
    url = finder.find_requirement(req_to_install, upgrade=self.upgrade)
  File "c:\users\daiyue\appdata\local\temp\tmpxji_co\pip-1.5.6-py2.py3-none-any.whl\pip\index.py", line 209, in find_requirement
    file_locations, url_locations = self._sort_locations(locations)
  File "c:\users\daiyue\appdata\local\temp\tmpxji_co\pip-1.5.6-py2.py3-none-any.whl\pip\index.py", line 128, in _sort_locations
    sort_path(os.path.join(path, item))
  File "c:\users\daiyue\appdata\local\temp\tmpxji_co\pip-1.5.6-py2.py3-none-any.whl\pip\index.py", line 109, in sort_path
    if mimetypes.guess_type(url, strict=False)[0] == 'text/html':
  File "C:\Python27\lib\mimetypes.py", line 290, in guess_type
    init()
  File "C:\Python27\lib\mimetypes.py", line 351, in init
    db.read_windows_registry()
  File "C:\Python27\lib\mimetypes.py", line 254, in read_windows_registry
    with _winreg.OpenKey(hkcr, subkeyname) as subkey:
TypeError: must be string without null bytes or None, not str
 

I have also tried out 64bit Python installation, but got the same result. So how to fix this? I posted the same message on comp.lang.python and Python Google group with no response so I guess i may try some luck here.

cheers

----------
components: Extension Modules
messages: 237476
nosy: Daiyue Weng
priority: normal
severity: normal
status: open
title: Python 3.4 and 2.7 installation no Script folder and no pip installed
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat Mar  7 22:04:42 2015
From: report at bugs.python.org (Ashish Sadanandan)
Date: Sat, 07 Mar 2015 21:04:42 +0000
Subject: [issue23603] Embedding Python3.4 - PyUnicode_Check fails (MinGW-W64)
In-Reply-To: <1425758526.01.0.875818979723.issue23603@psf.upfronthosting.co.za>
Message-ID: <1425762282.2.0.212953331157.issue23603@psf.upfronthosting.co.za>


Changes by Ashish Sadanandan <ashish.sadanandan at gmail.com>:


----------
title: MinGW-64 and embedding Python3.4 -> Embedding Python3.4 - PyUnicode_Check fails (MinGW-W64)

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

From report at bugs.python.org  Sat Mar  7 22:06:58 2015
From: report at bugs.python.org (Julian Taylor)
Date: Sat, 07 Mar 2015 21:06:58 +0000
Subject: [issue23601] use small object allocator for dict key storage
In-Reply-To: <1425727481.08.0.141675339822.issue23601@psf.upfronthosting.co.za>
Message-ID: <1425762418.0.0.154067537006.issue23601@psf.upfronthosting.co.za>


Julian Taylor added the comment:

PyObject_Malloc just calls malloc above the threshold so there is no problem for larger dicts.
For larger dicts the performance of malloc is also irrelevant as the time will be spent elsewhere.

----------

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

From report at bugs.python.org  Sat Mar  7 22:09:37 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Sat, 07 Mar 2015 21:09:37 +0000
Subject: [issue21518] Expose RegUnloadKey in winreg
In-Reply-To: <1400346760.52.0.0203244636304.issue21518@psf.upfronthosting.co.za>
Message-ID: <1425762577.87.0.655571769682.issue21518@psf.upfronthosting.co.za>


Changes by Claudiu Popa <pcmanticore at gmail.com>:


Added file: http://bugs.python.org/file38382/issue21518_5.patch

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

From report at bugs.python.org  Sat Mar  7 22:45:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Mar 2015 21:45:17 +0000
Subject: [issue23103] Reduce memory usage for ipaddress object instances
In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za>
Message-ID: <1425764717.7.0.139760101816.issue23103@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved

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

From report at bugs.python.org  Sat Mar  7 22:45:37 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 Mar 2015 21:45:37 +0000
Subject: [issue23103] Reduce memory usage for ipaddress object instances
In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za>
Message-ID: <1425764737.56.0.658085940814.issue23103@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
status: open -> closed

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

From report at bugs.python.org  Sat Mar  7 23:01:17 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Mar 2015 22:01:17 +0000
Subject: [issue22928] HTTP header injection in
 urrlib2/urllib/httplib/http.client
In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za>
Message-ID: <1425765677.18.0.178542826461.issue22928@psf.upfronthosting.co.za>


Martin Panter added the comment:

Folded header fields are deprecated as of RFC 7230; see <https://tools.ietf.org/html/rfc7230#section-3.2.4>. The only reasons to fold them I can think of is for readability (debugging), when generating a messsage/http MIME message (which I don?t think the Python library supports), or maybe when dealing with a strange server limitation. Normally there is not meant to be a limit for lines in the HTTP header, although it is common to limit the total unfolded header field value.

If we go ahead and drop folding support, perhaps we should deprecate the putheader() multi-argument mode, rather than just document the arguments are now joined by spaces. It seems a pointless API now with this change.

----------

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

From report at bugs.python.org  Sat Mar  7 23:33:24 2015
From: report at bugs.python.org (SilentGhost)
Date: Sat, 07 Mar 2015 22:33:24 +0000
Subject: [issue23604] Python 3.4 and 2.7 installation no Script folder and no
 pip installed
In-Reply-To: <1425761313.01.0.208884407276.issue23604@psf.upfronthosting.co.za>
Message-ID: <1425767604.85.0.286158219.issue23604@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
components: +Installation, Windows -Extension Modules
nosy: +steve.dower, tim.golden, zach.ware

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

From report at bugs.python.org  Sat Mar  7 23:34:36 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Mar 2015 22:34:36 +0000
Subject: [issue22227] Simplify tarfile iterator
In-Reply-To: <1408435555.43.0.257116130786.issue22227@psf.upfronthosting.co.za>
Message-ID: <1425767676.6.0.736413908402.issue22227@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

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

From report at bugs.python.org  Sat Mar  7 23:39:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Mar 2015 22:39:55 +0000
Subject: [issue22227] Simplify tarfile iterator
In-Reply-To: <1408435555.43.0.257116130786.issue22227@psf.upfronthosting.co.za>
Message-ID: <1425767995.52.0.142523915646.issue22227@psf.upfronthosting.co.za>


Martin Panter added the comment:

The code changes look correct and worthwhile to me. Just added some suggestions for the comments, which would become out of date.

----------

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

From report at bugs.python.org  Sat Mar  7 23:46:43 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Mar 2015 22:46:43 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1425768403.1.0.516753608594.issue23602@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

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

From report at bugs.python.org  Sun Mar  8 00:14:08 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Mar 2015 23:14:08 +0000
Subject: [issue23144] html.parser.HTMLParser: setting 'convert_charrefs =
 True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1425770048.95.0.957950912009.issue23144@psf.upfronthosting.co.za>


Martin Panter added the comment:

I still think it would be worthwhile adding close() calls to the examples in the documentation (Doc/library/html.parser.rst).

BTW I haven?t tested this, and maybe it is not a concern, but even with this patch it looks like the parser will buffer unlimited data and output nothing until close() if each string it is fed ends with an ampersand (and otherwise contains only plain text, no tags etc).

----------

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

From report at bugs.python.org  Sun Mar  8 00:17:13 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Mar 2015 23:17:13 +0000
Subject: [issue20876] python -m test test_pathlib fails
In-Reply-To: <1394395116.03.0.645933571525.issue20876@psf.upfronthosting.co.za>
Message-ID: <1425770233.21.0.289543524208.issue20876@psf.upfronthosting.co.za>


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


----------
stage:  -> patch review
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20876>
_______________________________________

From report at bugs.python.org  Sun Mar  8 00:18:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Mar 2015 23:18:38 +0000
Subject: [issue20876] python -m test test_pathlib fails
In-Reply-To: <1394395116.03.0.645933571525.issue20876@psf.upfronthosting.co.za>
Message-ID: <20150307231835.1221.8863@psf.io>


Roundup Robot added the comment:

New changeset 40e8a8e83ed0 by Antoine Pitrou in branch '3.4':
Issue #20876: correctly close temporary file in test.support.fs_is_case_insensitive()
https://hg.python.org/cpython/rev/40e8a8e83ed0

New changeset 5406ed13bd6e by Antoine Pitrou in branch 'default':
Issue #20876: correctly close temporary file in test.support.fs_is_case_insensitive()
https://hg.python.org/cpython/rev/5406ed13bd6e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20876>
_______________________________________

From report at bugs.python.org  Sun Mar  8 00:19:16 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Mar 2015 23:19:16 +0000
Subject: [issue20876] python -m test test_pathlib fails
In-Reply-To: <1394395116.03.0.645933571525.issue20876@psf.upfronthosting.co.za>
Message-ID: <1425770356.63.0.926719192487.issue20876@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I have applied the patch to 3.4 and default. Thank you!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20876>
_______________________________________

From report at bugs.python.org  Sun Mar  8 01:08:10 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 08 Mar 2015 00:08:10 +0000
Subject: [issue23144] html.parser.HTMLParser: setting 'convert_charrefs =
 True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1425773290.85.0.88764030757.issue23144@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I still think it would be worthwhile adding close() calls to
> the examples in the documentation (Doc/library/html.parser.rst).

If I add context manager support to HTMLParser I can update the examples to use it, but otherwise I don't think it's worth changing them now.

> BTW I haven?t tested this, and maybe it is not a concern, but even with
> this patch it looks like the parser will buffer unlimited data and
> output nothing until close() if each string it is fed ends with an 
> ampersand (and otherwise contains only plain text, no tags etc).

This is true, but I don't think it's a realistic case.
For this to be a problem you would need:
1) Someone feeding the parser with arbitrary chunks.  Text files are usually fed to the parser whole, or line by line -- arbitrary chunks are uncommon.
2) A file that contains lot of entities.  In most documents charrefs are not very common, and so the chances that a chunk will split one in the middle is low.  Chances that several consecutive charrefs are split in the middle is even lower.
3) A file that is very big.  Even if all the file is buffered until a call to close(), it shouldn't be a concern, since most files have relatively small size.  It is true that this has a quadratic complexity, but I would expect the parsing to complete in a reasonable time for average sizes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23144>
_______________________________________

From report at bugs.python.org  Sun Mar  8 01:32:34 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Mar 2015 00:32:34 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1425692486.58.0.563461151472.issue21619@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZs=T90Ex-Nmit82KaA+hAcQLdhafGWR8uh_qKBHsRmjg@mail.gmail.com>


STINNER Victor added the comment:

overflow-pipe-test.patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21619>
_______________________________________

From report at bugs.python.org  Sun Mar  8 01:55:30 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Mar 2015 00:55:30 +0000
Subject: [issue23588] Errno conflicts in ssl.SSLError
In-Reply-To: <1425528608.86.0.380656858337.issue23588@psf.upfronthosting.co.za>
Message-ID: <1425776130.62.0.428177464433.issue23588@psf.upfronthosting.co.za>


Martin Panter added the comment:

[padding]

This behaviour of returning an SSL-specific error code in the ?errno? attribute is not documented. The ?errno? attribute is actually specified to hold a POSIX error code, and I don?t think this specification should be changed.

I don?t see how checking for an ?errno_scope? attribute is any better than checking for isinstance(exception, SSLError). I think the SSL error codes should be removed from ?errno?, or maybe moved to a new attribute (ssl_error?), like what is already done with the ?winerror? attribute.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23588>
_______________________________________

From report at bugs.python.org  Sun Mar  8 02:05:40 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2015 01:05:40 +0000
Subject: [issue23603] Embedding Python3.4 - PyUnicode_Check fails (MinGW-W64)
In-Reply-To: <1425758526.01.0.875818979723.issue23603@psf.upfronthosting.co.za>
Message-ID: <1425776740.15.0.426738795409.issue23603@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Your interpretation of PyUnicode_Check() is correct. I don't know why your program fails but I would suggest some kind of compiler bug or incompatibility. You can find the definition of the unicode type in Objects/unicodeobject.c. There you'll find that Py_TPFLAGS_UNICODE_SUBCLASS is set in PyUnicode_Type's tp_flags.

(for the record, under Windows we only support builds made with MSVC)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23603>
_______________________________________

From report at bugs.python.org  Sun Mar  8 02:09:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Mar 2015 01:09:38 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <20150308010935.117213.81337@psf.io>


Roundup Robot added the comment:

New changeset d04d5b9c29f6 by Victor Stinner in branch 'default':
Issue #22524: New os.scandir() function, part of the PEP 471: "os.scandir()
https://hg.python.org/cpython/rev/d04d5b9c29f6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Sun Mar  8 02:09:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Mar 2015 01:09:57 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <1425776997.4.0.38757362227.issue22524@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> KNOWN ISSUE: There's a reference leak in the POSIX version (found with "python -m test -R 3:2 test_os").

Don't worry, it was a simple refleak, I fixed it:

diff -r 392d3214fc23 Modules/posixmodule.c
--- a/Modules/posixmodule.c     Sun Mar 08 01:58:04 2015 +0100
+++ b/Modules/posixmodule.c     Sun Mar 08 02:08:05 2015 +0100
@@ -16442,6 +16442,7 @@ DirEntry_fetch_stat(DirEntry *self, int 
         result = STAT(path, &st);
     else
         result = LSTAT(path, &st);
+    Py_DECREF(bytes);
 
     if (result != 0)
         return PyErr_SetFromErrnoWithFilenameObject(PyExc_OSError, self->path);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Sun Mar  8 02:17:11 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Mar 2015 01:17:11 +0000
Subject: [issue23591] Add IntFlags
In-Reply-To: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za>
Message-ID: <1425777431.4.0.927598605916.issue23591@psf.upfronthosting.co.za>


Martin Panter added the comment:

It would make more sense and be more consistent if the str() and repr() used one?s complement in all cases, i.e.:

self.assertEqual(str(Perm(~0)), "~0")

Also, the repr() seems to be doing a bad attempt at Python pseudo code. Instead of

<Perm.R|W: 3>

maybe it could be something like these:

<Perm.R|Perm.W: 3>  # Mirroring str() -> "Perm.R|Perm.W"
<Perm R|W: 3>
<Perm: R|W = 3>

I wonder if the addition (+) operator should also be overridden; I haven?t looked, but I suspect some people may do FLAG1 + FLAG2 instead of FLAG1 | FLAG2.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23591>
_______________________________________

From report at bugs.python.org  Sun Mar  8 02:27:39 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Mar 2015 01:27:39 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425778059.29.0.34932774608.issue23524@psf.upfronthosting.co.za>


STINNER Victor added the comment:

test_os fails on Windows since the changeset 75aadb4450fd:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/5798/steps/test/logs/stdio

======================================================================
FAIL: test_15261 (test.test_os.StatAttributeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_os.py", line 581, in test_15261
    self.assertEqual(ctx.exception.errno, errno.EBADF)
AssertionError: 22 != 9

======================================================================
FAIL: test_fstat (test.test_os.TestInvalidFD)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_os.py", line 1378, in check
    f(support.make_bad_fd(), *args)
FileNotFoundError: [WinError 18] There are no more files

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\test\test_os.py", line 1371, in helper
    self.check(getattr(os, f))
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_os.py", line 1380, in check
    self.assertEqual(e.errno, errno.EBADF)
AssertionError: 2 != 9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23524>
_______________________________________

From report at bugs.python.org  Sun Mar  8 02:49:13 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Mar 2015 01:49:13 +0000
Subject: [issue23556] Scope for raise without argument is different in Python
 2 and 3
In-Reply-To: <1425212072.31.0.66074782686.issue23556@psf.upfronthosting.co.za>
Message-ID: <1425779353.45.0.72777012309.issue23556@psf.upfronthosting.co.za>


Martin Panter added the comment:

For the Python 3 case, the documentation is vague and probably wrong, depending on what you understand ?the current scope? to mean. I think it should read something like

. . . raise re-raises the current exception that is being handled. If no exception is being handled, a RuntimeError exception is raised indicating that this is an error.

I?m not sure but I suspect Python 2 is different because does not save the original exception when it handles a nested exception. In other words, at the point where the nested ?bar? exception is raised inside the ?foo? handler, Python forgets that ?foo? was being handled.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23556>
_______________________________________

From report at bugs.python.org  Sun Mar  8 02:49:21 2015
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 08 Mar 2015 01:49:21 +0000
Subject: [issue23591] Add IntFlags
In-Reply-To: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za>
Message-ID: <1425779361.91.0.505119511857.issue23591@psf.upfronthosting.co.za>


Ethan Furman added the comment:

The current patch is more along the lines of a proof-of-concept.

The final IntFlag type (if there is one) would be quite a bit more extensive since part of the reason for its existence is to not lose type -- so pretty much every __op__ would have to be overridden.

Agreed about the repr() and str(), though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23591>
_______________________________________

From report at bugs.python.org  Sun Mar  8 02:49:34 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Mar 2015 01:49:34 +0000
Subject: [issue23556] Scope for raise without argument is different in Python
 2 and 3
In-Reply-To: <1425212072.31.0.66074782686.issue23556@psf.upfronthosting.co.za>
Message-ID: <1425779374.11.0.214218739578.issue23556@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23556>
_______________________________________

From report at bugs.python.org  Sun Mar  8 02:55:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Mar 2015 01:55:45 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <1425779745.73.0.593803449206.issue22524@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I commited  scandir-8.patch with the documentation of scandir-5.patch. I wanted os.scandir() to be part of Python 3.5 alpha 2.

Thanks for your patience Ben ;-)

We should now watch buildbots to check how they appreciate os.scandir().
http://buildbot.python.org/all/waterfall?category=3.x.stable&category=3.x.unstable

Right now, test_os fails on Windows buildbots because of a regression of #23524. test_os.TestScandir succeeded on AMD64 Windows7 SP1 3.x.

We can maybe keep the issue open if someone still wants to enhance the C code, tests or the doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Sun Mar  8 03:01:28 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Mar 2015 02:01:28 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <20150308020125.19089.62013@psf.io>


Roundup Robot added the comment:

New changeset 60e5c34ec53a by Victor Stinner in branch 'default':
Issue #22524: Fix os.scandir() for platforms which don't have a d_type field in
https://hg.python.org/cpython/rev/60e5c34ec53a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Sun Mar  8 03:02:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Mar 2015 02:02:15 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <1425780135.8.0.362110737931.issue22524@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh oh, OpenIndiana doesn't support d_type: the dirent structure has no d_type field and DT_xxx constants like DT_UNKNOWN are not defined.

gcc -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -I/usr/local/include/ncursesw -m64   -Werror=declaration-after-statement   -I. -IInclude -I./Include    -DPy_BUILD_CORE  -c ./Modules/_collectionsmodule.c -o Modules/_collectionsmodule.o
./Modules/posixmodule.c: In function 'DirEntry_is_symlink':
./Modules/posixmodule.c:16393: error: 'DT_UNKNOWN' undeclared (first use in this function)
./Modules/posixmodule.c:16393: error: (Each undeclared identifier is reported only once
./Modules/posixmodule.c:16393: error: for each function it appears in.)
./Modules/posixmodule.c:16394: error: 'DT_LNK' undeclared (first use in this function)
./Modules/posixmodule.c:16398: warning: control reaches end of non-void function
./Modules/posixmodule.c: In function 'DirEntry_test_mode':
./Modules/posixmodule.c:16519: error: 'DT_LNK' undeclared (first use in this function)
./Modules/posixmodule.c:16520: error: 'DT_UNKNOWN' undeclared (first use in this function)
./Modules/posixmodule.c:16559: error: 'DT_DIR' undeclared (first use in this function)
./Modules/posixmodule.c:16561: error: 'DT_REG' undeclared (first use in this function)
./Modules/posixmodule.c: In function 'ScandirIterator_iternext':
./Modules/posixmodule.c:16973: error: 'struct dirent' has no member named 'd_type'
make: *** [Modules/posixmodule.o] Error 1
make: *** Waiting for unfinished jobs....

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Sun Mar  8 03:11:27 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Mar 2015 02:11:27 +0000
Subject: [issue23570] Change "with subprocess.Popen():" (context manager) to
 ignore broken pipe error
In-Reply-To: <1425376156.84.0.317071254674.issue23570@psf.upfronthosting.co.za>
Message-ID: <1425780686.99.0.902693824683.issue23570@psf.upfronthosting.co.za>


Martin Panter added the comment:

After understanding the Windows test failure in Issue 21619, I am starting to believe that code relying on a BrokenPipeError or EPIPE is flawed. It is an inherent unavoidable race condition with the receiving end of the pipe, as long as another thread or process is involved, which is always the case for the subprocess module. Another way of looking at it is that there is no guarantee that your data will have been (or will be) received, even if stdin.close() succeeds and does not raise EPIPE or similar. This is because piped data is buffered by the OS.

So the proposed change wouldn?t be a significant disadvantage, except for code that is already flawed. It is analogous to the argument used for ignoring EINTR, because depending on it for handling signals is inherently racy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23570>
_______________________________________

From report at bugs.python.org  Sun Mar  8 03:15:23 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 08 Mar 2015 02:15:23 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425780923.1.0.240064681766.issue23524@psf.upfronthosting.co.za>


Steve Dower added the comment:

This is because of the _Py_fstat change to use errno instead of GetLastError. It seems other callers are relying on GetLastError to raise the correct exception, and that seems to be the standard throughout posixmodule as far as stat calls are concerned.

Best immediate fix is to revert back to how _Py_fstat was originally and update the caller's error handling, which I'll do now. Feel free to propose a more thorough patch that will unify error number handling, but I don't think it's a such a big problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23524>
_______________________________________

From report at bugs.python.org  Sun Mar  8 03:16:53 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Mar 2015 02:16:53 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <20150308021651.1783.8942@psf.io>


Roundup Robot added the comment:

New changeset d8e49a2795e7 by Steve Dower in branch 'default':
Issue #23524: Change back to using Windows errors for _Py_fstat instead of the errno shim.
https://hg.python.org/cpython/rev/d8e49a2795e7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23524>
_______________________________________

From report at bugs.python.org  Sun Mar  8 03:29:24 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Mar 2015 02:29:24 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425781763.99.0.885706889522.issue23524@psf.upfronthosting.co.za>


STINNER Victor added the comment:

fstat_ebadf.patch: _Py_fstat() now also set errno on Windows.

It's a little bit different than your patch, because it still calls SetLastError(ERROR_INVALID_HANDLE) to explicitly set the Windows error on bad file descriptor. We must set errno et SetLastError(): some callers check for errno, some callers uses GetLastError() (ex: path_error()).

I don't have access to Windows right now, I cannot test the patch. And it's maybe safer to wait after Python 3.5 alpha 2 release to apply it, if your latest change is enough to fix test_os on Windows.

----------
Added file: http://bugs.python.org/file38383/fstat_ebadf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23524>
_______________________________________

From report at bugs.python.org  Sun Mar  8 03:29:24 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Mar 2015 02:29:24 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425781764.86.0.140068123931.issue23524@psf.upfronthosting.co.za>


STINNER Victor added the comment:

fstat_ebadf.patch: _Py_fstat() now also set errno on Windows.

It's a little bit different than your patch, because it still calls SetLastError(ERROR_INVALID_HANDLE) to explicitly set the Windows error on bad file descriptor. We must set errno et SetLastError(): some callers check for errno, some callers uses GetLastError() (ex: path_error()).

I don't have access to Windows right now, I cannot test the patch. And it's maybe safer to wait after Python 3.5 alpha 2 release to apply it, if your latest change is enough to fix test_os on Windows.

----------
Added file: http://bugs.python.org/file38384/fstat_ebadf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23524>
_______________________________________

From report at bugs.python.org  Sun Mar  8 03:29:55 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Mar 2015 02:29:55 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425781795.31.0.0046453887035.issue23524@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file38383/fstat_ebadf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23524>
_______________________________________

From report at bugs.python.org  Sun Mar  8 03:30:04 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Mar 2015 02:30:04 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425781804.71.0.980205485477.issue23524@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
Removed message: http://bugs.python.org/msg237501

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23524>
_______________________________________

From report at bugs.python.org  Sun Mar  8 03:30:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Mar 2015 02:30:15 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425781815.82.0.25718306529.issue23524@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
Removed message: http://bugs.python.org/msg237501

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23524>
_______________________________________

From report at bugs.python.org  Sun Mar  8 03:33:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Mar 2015 02:33:55 +0000
Subject: [issue23144] html.parser.HTMLParser: setting 'convert_charrefs =
 True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1425782035.42.0.87878579694.issue23144@psf.upfronthosting.co.za>


Martin Panter added the comment:

A context manager here would seem a bit strange. Is there any precedent for using context managers with feed parsers? The two others that come to mind are ElementTree.XMLParser and email.parser.FeedParser. These two build an object while parsing, and close() returns that object, so a context manager would be unhelpful.

If an exception is raised inside the context manager, should close() be called (like for file objects), or not?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23144>
_______________________________________

From report at bugs.python.org  Sun Mar  8 03:36:13 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Mar 2015 02:36:13 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
Message-ID: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The PEP 471 announces a huge speed up of the os.walk() function, but os.walk() was not modified yet. I just merged the implementation of os.scandir() (issue #22524), it's now time to work on os.walk().

We need a patch and benchmarks on Linux and Windows.

On NFS shares (on Linux), d_type is not filled (set to DT_UNKNOWN, so a syscall is required to get the file type). Benchmarks of os.walk() on a NFS share is also required.

----------
messages: 237504
nosy: haypo
priority: normal
severity: normal
status: open
title: Use the new os.scandir() function in os.walk()
type: performance
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Sun Mar  8 03:36:32 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 08 Mar 2015 02:36:32 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <1425782192.69.0.35690360805.issue22524@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I opened the issue #23605: "Use the new os.scandir() function in os.walk()".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Sun Mar  8 03:39:29 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 08 Mar 2015 02:39:29 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1425782369.76.0.519343877929.issue23524@psf.upfronthosting.co.za>


Steve Dower added the comment:

I didn't know about winerror_to_errno(), so that might help. But there are other dependencies on _Py_fstat's error code throughout posixmodule.c, so I don't think this is sufficient. (For example, patherror() is already switched on OS to handle it correctly. I gave up tracking down all the uses because it hurt more than the horrific condition in fileio.c.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23524>
_______________________________________

From report at bugs.python.org  Sun Mar  8 04:15:48 2015
From: report at bugs.python.org (Ben Hoyt)
Date: Sun, 08 Mar 2015 03:15:48 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1425784548.37.0.294827541215.issue23605@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

Attaching a first cut at this -- basically the implementation I use for walk() in scandir.py on GitHub.

One thing that's really weird to me: are the os.walk() unit tests actually being run? In test_os.py, I notice everything's in WalkTest.setUp, which is kinda weird -- and it's not actually running. At least when I add a "1/0" inside setUp() to force an error and run "python -m test test_os" I don't get any errors...

----------
keywords: +patch
nosy: +benhoyt
Added file: http://bugs.python.org/file38385/os_walk_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Sun Mar  8 04:17:34 2015
From: report at bugs.python.org (Ben Darnell)
Date: Sun, 08 Mar 2015 03:17:34 +0000
Subject: [issue23588] Errno conflicts in ssl.SSLError
In-Reply-To: <1425528608.86.0.380656858337.issue23588@psf.upfronthosting.co.za>
Message-ID: <1425784654.78.0.984206251451.issue23588@psf.upfronthosting.co.za>


Ben Darnell added the comment:

I agree that SSLError should have used a different attribute, but it's too late for that - changing it would break any code currently relying on SSL errnos (in particular asynchronous code using the SSL_ERROR_WANT_{READ,WRITE} error codes for normal operation).

errno_scope is better than checking for isinstance(SSLError) because it lets code that only wants posix errno to say so, instead of having to know about and blacklist every OSError subclass that abuses the errno attribute (is SSLError the only one?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23588>
_______________________________________

From report at bugs.python.org  Sun Mar  8 05:17:56 2015
From: report at bugs.python.org (Demian Brecht)
Date: Sun, 08 Mar 2015 04:17:56 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
 "chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1425788276.68.0.797463088908.issue12319@psf.upfronthosting.co.za>


Demian Brecht added the comment:

After sleeping on this, I think that the best route to go would be to drop the trailer implementation (if it's not practical it doesn't belong in the standard library).

Also, to better preserve backwards compatibility it may be better to circumvent the automatic chunking if transfer-encoding headers are present in the request call. That way, no changes would need to be made to existing code that already supports it at a higher level.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12319>
_______________________________________

From report at bugs.python.org  Sun Mar  8 05:41:10 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 08 Mar 2015 04:41:10 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
Message-ID: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>


New submission from Steve Dower:

With the changes to the CRT on Windows, it no longer makes any sense to call find_library("c") or ("m") as there is no single C Runtime DLL. The new structure has a grouped and layered approach that is better for versioning, so we now link to "api-ms-win-crt-*-l1-1-0.dll" where "*" is something like "filesystem", "heap", "locale", "math", "string", etc. and the "l1-1-0" part is a version.

I don't know what the intended purpose of this function is, so I can't suggest a good replacement other than very fast deprecation in 3.4 and raising an error in 3.5. Any better suggestions?

----------
components: ctypes
messages: 237510
nosy: amaury.forgeotdarc, belopolsky, meador.inge, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: ctypes.util.find_library("c") no longer makes sense
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23606>
_______________________________________

From report at bugs.python.org  Sun Mar  8 05:43:36 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 08 Mar 2015 04:43:36 +0000
Subject: [issue22227] Simplify tarfile iterator
In-Reply-To: <1408435555.43.0.257116130786.issue22227@psf.upfronthosting.co.za>
Message-ID: <1425789816.59.0.626508278814.issue22227@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22227>
_______________________________________

From report at bugs.python.org  Sun Mar  8 06:49:24 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Mar 2015 05:49:24 +0000
Subject: [issue22252] ssl blocking IO errors should inherit BlockingIOError
In-Reply-To: <1408728679.49.0.938853718586.issue22252@psf.upfronthosting.co.za>
Message-ID: <1425793764.79.0.716267335515.issue22252@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium
title: ssl blocking IO errors -> ssl blocking IO errors should inherit BlockingIOError

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22252>
_______________________________________

From report at bugs.python.org  Sun Mar  8 06:50:05 2015
From: report at bugs.python.org (eryksun)
Date: Sun, 08 Mar 2015 05:50:05 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <1425793805.46.0.586291650142.issue23606@psf.upfronthosting.co.za>


eryksun added the comment:

Shouldn't find_library("c") return "ucrtbase.dll" or "ucrtbased.dll" (debug)? 

Introducing the Universal CRT
http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23606>
_______________________________________

From report at bugs.python.org  Sun Mar  8 07:24:40 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Mar 2015 06:24:40 +0000
Subject: [issue23588] Errno conflicts in ssl.SSLError
In-Reply-To: <1425528608.86.0.380656858337.issue23588@psf.upfronthosting.co.za>
Message-ID: <1425795880.84.0.993763942878.issue23588@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay I see your point about backwards compatibility now. Indeed, I have written code myself before Python 3.3 that used to inspect err.args[0], and it would suffer a similar problem if I had not updated it to use the new Python 3.3 exception subclasses.

Below I have written a comparison of two options that have been proposed. Both have disadvantages and would potentially require changes in user code.

A third middle-ground option might be to deprecate OSError.errno as well, and replace it with OSError.posix_errno or something. But I would still prefer the option to stop setting SSLError.errno, even though it breaks backwards compatibility. I think we can at least agree that ?errno? and ?args? should be deprecated for SSLError instances.

## Option 1: Add OSError.errno_scope ##

To avoid the bug in new Python versions we would still have to modify code handling a general OSError (EnvironmentError), for example:

# Buggy handler compatible with Python 3.2
try:
  return ssl_sock.read()
except EnvironmentError as e:
  if e.errno != errno.EINTR:
    raise

# Fixed handler, supporting new Python versions only
try:
  return ssl_sock.read()
except OSError as e:
  if e.errno_scope != POSIX or e.errno != errno.EINTR:
    raise

Advantages:
* Existing code still works if you don?t care about this bug
* No code changes required in SSL error handlers

## Option 2: Stop setting SSLError.errno ##

Existing SSLError handlers written for Python < 3.3 would stop catching exceptions, because ?errno? defaults to None. This would probably cause an unhandled exception, and could be fixed as follows:

# Broken handler written for Python 3.2
try:
  return ssl_sock.read()
except SSLError as e:
  if e.errno != SSL_ERROR_WANT_READ:
    raise
  # Handle non-blocking read

# Fixed handler, supporting Python 3.3+ only
try:
  return ssl_sock.read()
except SSLWantReadError as e:
  # Handle non-blocking read

Advantages:
* Affected code should be easy to find due to breakage
* Only requires the user to change code that directly handles SSL errors
* No changes for code already written for Python 3.3
* Code changes only when relying on the undocumented errno behaviour, which is already asking for trouble

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23588>
_______________________________________

From report at bugs.python.org  Sun Mar  8 07:44:12 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Mar 2015 06:44:12 +0000
Subject: [issue23588] Errno conflicts in ssl.SSLError
In-Reply-To: <1425528608.86.0.380656858337.issue23588@psf.upfronthosting.co.za>
Message-ID: <1425797052.34.0.609731542286.issue23588@psf.upfronthosting.co.za>


Martin Panter added the comment:

Sorry I take back my claim that the error codes were undocumented; see the example code in <https://docs.python.org/3.2/library/ssl.html#ssl-nonblocking>.

Perhaps the most compatible way to fix this would be to change the SSL error codes to something (custom class?) that does not compare equal to any possible POSIX error code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23588>
_______________________________________

From report at bugs.python.org  Sun Mar  8 07:59:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 06:59:00 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425797940.45.0.678926134284.issue21619@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think we should add __enter__ for consistency.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21619>
_______________________________________

From report at bugs.python.org  Sun Mar  8 08:00:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 07:00:36 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425798036.67.0.826210971826.issue21619@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file38386/overflow-pipe-test-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21619>
_______________________________________

From report at bugs.python.org  Sun Mar  8 08:03:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Mar 2015 07:03:55 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425798235.41.0.606185314511.issue21619@psf.upfronthosting.co.za>


Martin Panter added the comment:

Sure, new version is fine by me

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21619>
_______________________________________

From report at bugs.python.org  Sun Mar  8 08:18:39 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Mar 2015 07:18:39 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <20150308071836.16645.97117@psf.io>


Roundup Robot added the comment:

New changeset 4ea40dc3d26d by Serhiy Storchaka in branch '3.4':
Issue #21619: Cleaned up test_broken_pipe_cleanup.
https://hg.python.org/cpython/rev/4ea40dc3d26d

New changeset 41ce95a5b2d8 by Serhiy Storchaka in branch 'default':
Issue #21619: Cleaned up test_broken_pipe_cleanup.
https://hg.python.org/cpython/rev/41ce95a5b2d8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21619>
_______________________________________

From report at bugs.python.org  Sun Mar  8 08:28:46 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Sun, 08 Mar 2015 07:28:46 +0000
Subject: [issue9191] winreg.c:Reg2Py() may leak memory (in unusual
 circumstances)
In-Reply-To: <1278525166.4.0.0879298798846.issue9191@psf.upfronthosting.co.za>
Message-ID: <1425799726.55.0.876881589774.issue9191@psf.upfronthosting.co.za>


Claudiu Popa added the comment:

This was fixed a couple of months ago: https://hg.python.org/cpython/rev/07968254be96. Also, malloc was changed to PyMem_New a couple of weeks ago: https://hg.python.org/cpython/rev/036a2aceae93

----------
nosy: +Claudiu.Popa
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9191>
_______________________________________

From report at bugs.python.org  Sun Mar  8 08:39:43 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Sun, 08 Mar 2015 07:39:43 +0000
Subject: [issue7877] Iterators over _winreg EnumKey and EnumValue results
In-Reply-To: <1265578300.82.0.0744515010877.issue7877@psf.upfronthosting.co.za>
Message-ID: <1425800383.73.0.0418880380021.issue7877@psf.upfronthosting.co.za>


Changes by Claudiu Popa <pcmanticore at gmail.com>:


----------
nosy: +Claudiu.Popa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7877>
_______________________________________

From report at bugs.python.org  Sun Mar  8 08:57:44 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Sun, 08 Mar 2015 07:57:44 +0000
Subject: [issue11276] 2to3: imports fixer doesn't update references to modules
 specified without attributes
In-Reply-To: <1298320370.6.0.707528298714.issue11276@psf.upfronthosting.co.za>
Message-ID: <1425801464.52.0.115084607298.issue11276@psf.upfronthosting.co.za>


Changes by Claudiu Popa <pcmanticore at gmail.com>:


----------
nosy: +Claudiu.Popa
type:  -> behavior
versions: +Python 3.5 -Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11276>
_______________________________________

From report at bugs.python.org  Sun Mar  8 09:06:02 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Sun, 08 Mar 2015 08:06:02 +0000
Subject: [issue11705] sys.excepthook doesn't work in imported modules
In-Reply-To: <1301351356.06.0.0947935400826.issue11705@psf.upfronthosting.co.za>
Message-ID: <1425801962.52.0.0100637711619.issue11705@psf.upfronthosting.co.za>


Changes by Claudiu Popa <pcmanticore at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11705>
_______________________________________

From report at bugs.python.org  Sun Mar  8 09:23:16 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Sun, 08 Mar 2015 08:23:16 +0000
Subject: [issue10805] traceback.print_exception throws AttributeError when
 exception is None
In-Reply-To: <1293978231.38.0.946265028499.issue10805@psf.upfronthosting.co.za>
Message-ID: <1425802996.54.0.469370143896.issue10805@psf.upfronthosting.co.za>


Claudiu Popa added the comment:

This was recently fixed in 3.5 by 73afda5a4e4c.

----------
nosy: +Claudiu.Popa
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10805>
_______________________________________

From report at bugs.python.org  Sun Mar  8 09:28:33 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 08 Mar 2015 08:28:33 +0000
Subject: [issue23137] Python 2.7.9 test_gdb fails on CentOS 7
In-Reply-To: <1419983350.87.0.850193733351.issue23137@psf.upfronthosting.co.za>
Message-ID: <1425803313.15.0.970322901392.issue23137@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Frankly I've no idea who should be looking at this issue.

----------
nosy: +BreamoreBoy
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23137>
_______________________________________

From report at bugs.python.org  Sun Mar  8 09:34:55 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 08 Mar 2015 08:34:55 +0000
Subject: [issue23027] test_warnings fails with -Werror
In-Reply-To: <1418248295.01.0.00165630152899.issue23027@psf.upfronthosting.co.za>
Message-ID: <1425803695.01.0.126093919668.issue23027@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

This can be reproduced with 3.5 on Windows 8.1.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23027>
_______________________________________

From report at bugs.python.org  Sun Mar  8 09:37:03 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 08 Mar 2015 08:37:03 +0000
Subject: [issue23159] argparse: Provide equivalent of
 optparse.OptionParser.{option_groups, option_list, get_option}
In-Reply-To: <1420355263.97.0.969710352141.issue23159@psf.upfronthosting.co.za>
Message-ID: <1425803823.93.0.0557064967818.issue23159@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy: +bethard, paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23159>
_______________________________________

From report at bugs.python.org  Sun Mar  8 09:38:40 2015
From: report at bugs.python.org (SilentGhost)
Date: Sun, 08 Mar 2015 08:38:40 +0000
Subject: [issue23137] Python 2.7.9 test_gdb fails on CentOS 7
In-Reply-To: <1419983350.87.0.850193733351.issue23137@psf.upfronthosting.co.za>
Message-ID: <1425803920.09.0.598524109876.issue23137@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +benjamin.peterson, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23137>
_______________________________________

From report at bugs.python.org  Sun Mar  8 09:42:12 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 08:42:12 +0000
Subject: [issue21619] Cleaning up a subprocess with a broken pipe
In-Reply-To: <1401541025.39.0.6743321007.issue21619@psf.upfronthosting.co.za>
Message-ID: <1425804132.8.0.789976975063.issue21619@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21619>
_______________________________________

From report at bugs.python.org  Sun Mar  8 09:57:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 08:57:18 +0000
Subject: [issue22227] Simplify tarfile iterator
In-Reply-To: <1408435555.43.0.257116130786.issue22227@psf.upfronthosting.co.za>
Message-ID: <1425805038.22.0.931080497387.issue22227@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch doesn't fix a bug and doesn't add new feature. It just rewrites the code in more clear manner (in my eyes). So I leave applying or rejecting the patch on Lars.

----------
assignee:  -> lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22227>
_______________________________________

From report at bugs.python.org  Sun Mar  8 10:07:35 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 08 Mar 2015 09:07:35 +0000
Subject: [issue23003] traceback.{print_exc, print_exception, format_exc,
 format_exception}: Potential AttributeError
In-Reply-To: <1417909047.64.0.652633919593.issue23003@psf.upfronthosting.co.za>
Message-ID: <1425805655.23.0.564747354315.issue23003@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This is no longer an issue after issue 17911.

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23003>
_______________________________________

From report at bugs.python.org  Sun Mar  8 10:19:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 09:19:00 +0000
Subject: [issue22928] HTTP header injection in
 urrlib2/urllib/httplib/http.client
In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za>
Message-ID: <1425806340.06.0.917517014167.issue22928@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be not drop folding support, but just deprecate the putheader() multi-argument mode? And of course add sanity checks for separate putheader() arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22928>
_______________________________________

From report at bugs.python.org  Sun Mar  8 10:31:12 2015
From: report at bugs.python.org (Tuomas Suutari)
Date: Sun, 08 Mar 2015 09:31:12 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425752156.63.0.740194302931.issue23602@psf.upfronthosting.co.za>
Message-ID: <CAPXCX8Ba2d_sygOswQrN357s7uvTgPTTiV4Z_LsYEs-gRR_X9A@mail.gmail.com>


Tuomas Suutari added the comment:

Serhiy Storchaka wrote:
>>>> from fractions import Fraction as F
>>>> format(F(1, 3), '.30f')
> '0.333333333333333333333333333300'

Good catch! I'll try to fix this and add some more test cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Sun Mar  8 11:06:46 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 08 Mar 2015 10:06:46 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1425809206.06.0.586241626175.issue23602@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I'm not sure it needs fixing: it follows from the definition of using Decimal(num) / Decimal(denom). Plus, it's controllable with a decimal context:

>>> from decimal import localcontext
>>> with localcontext() as ctx:
...   ctx.prec = 100
...   format(F(1, 3), '.30f')
...
'0.333333333333333333333333333333'
>>>

For all of the tests, I suggest using format(value, str) instead of ''.format(value). It more directly tests Fraction.__format__.

In general I think adding Fraction.__format__ is a good idea, and I think converting to Decimal is reasonable for the specified codes. My only question is what to do when "natively" formatting Fractions themselves. We might want to support field widths, padding, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Sun Mar  8 11:11:45 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Mar 2015 10:11:45 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1425809505.34.0.867325022385.issue23602@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?ve never actually used the Fraction class, but I doubt its behaviour should depend on whatever settings are in the current decimal context. Maybe you can extract the precision out of the format string, and base the internal decimal object on that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Sun Mar  8 11:35:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 10:35:01 +0000
Subject: [issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal)
Message-ID: <1425810901.79.0.570490913636.issue23607@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

First, datetime.utcfromtimestamp() drops fractional part of Decimal argument:

>>> import datetime
>>> from decimal import Decimal as D
>>> datetime.datetime.utcfromtimestamp(1425808327.307651)
datetime.datetime(2015, 3, 8, 9, 52, 7, 307651)
>>> datetime.datetime.utcfromtimestamp(D(1425808327.307651))
datetime.datetime(2015, 3, 8, 9, 52, 7)

Second, it works only with C implementation. With Python implementation Decimals are not supported at all.

>>> del sys.modules['datetime']
>>> sys.modules['_datetime'] = None
>>> import datetime
>>> datetime.datetime.utcfromtimestamp(D(1425808327.307651))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/datetime.py", line 1374, in utcfromtimestamp
    t, frac = divmod(t, 1.0)
TypeError: unsupported operand type(s) for divmod(): 'decimal.Decimal' and 'float'

In 2.7 Decimals are accepted and are not truncated.

>>> import datetime
>>> from decimal import Decimal as D
>>> datetime.datetime.utcfromtimestamp(D(1425808327.307651))
datetime.datetime(2015, 3, 8, 9, 52, 7, 307651)

So this can be considered as a regression.

----------
components: Library (Lib)
messages: 237527
nosy: belopolsky, lemburg, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Inconsistency in datetime.utcfromtimestamp(Decimal)
type: behavior
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23607>
_______________________________________

From report at bugs.python.org  Sun Mar  8 12:25:26 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Mar 2015 11:25:26 +0000
Subject: [issue23103] Reduce memory usage for ipaddress object instances
In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za>
Message-ID: <1425813926.73.0.99804968603.issue23103@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

For the record, I don't think the weakref support is likely to be particularly useful either, and if we'd used __slots__ from the beginning, I expect we would have left it out.

It's specifically the idea of *taking weakref support away* when weakrefs currently work that seems dubious to me.

It may be worth asking the question on Python dev, as it's possible I'm being overly cautious, and it would be reasonable to drop the weakref support in 3.5.0, while mentioning in the 3.5 porting notes that we'd be open to the idea of adding weakref support back in a 3.5.x maintenance release if anyone reports its removal as a regression from 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23103>
_______________________________________

From report at bugs.python.org  Sun Mar  8 12:32:12 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 08 Mar 2015 11:32:12 +0000
Subject: [issue23144] html.parser.HTMLParser: setting 'convert_charrefs =
 True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1425814332.48.0.816905940079.issue23144@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> A context manager here would seem a bit strange.

I still haven't thought this through, but I can't see any problem with it right now.  This would be similar to:

  from contextlib import closing
  with closing(MyHTMLParser()) as parser:
      parser.feed(html)

and this already seems to work fine, including with OP's case.

> If an exception is raised inside the context manager,
> should close() be called (like for file objects), or not?

The parser is guaranteed to never raise parsing-related errors during parsing, so this shouldn't be an issue.  I will open a new issue after fixing this so we can keep discussing there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23144>
_______________________________________

From report at bugs.python.org  Sun Mar  8 12:44:39 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2015 11:44:39 +0000
Subject: [issue23103] Reduce memory usage for ipaddress object instances
In-Reply-To: <1419328646.72.0.916490552999.issue23103@psf.upfronthosting.co.za>
Message-ID: <1425815079.81.0.213544626243.issue23103@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

-1 on dropping weakref support. It's a feature, and it costs almost nothing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23103>
_______________________________________

From report at bugs.python.org  Sun Mar  8 13:34:50 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 08 Mar 2015 12:34:50 +0000
Subject: [issue23608] ssl.VERIFY_X509_TRUSTED_FIRST: Incorrect value for
 versionadded
Message-ID: <1425818090.41.0.129275996711.issue23608@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

Commit bb6fb47e0141 added ".. versionadded:: 3.4.5" in documentation of ssl.VERIFY_X509_TRUSTED_FIRST, but next version of Python 3.4 will be 3.4.4.

----------
assignee: benjamin.peterson
components: Documentation
messages: 237531
nosy: Arfrever, alex, benjamin.peterson, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
status: open
title: ssl.VERIFY_X509_TRUSTED_FIRST: Incorrect value for versionadded
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23608>
_______________________________________

From report at bugs.python.org  Sun Mar  8 14:35:33 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 13:35:33 +0000
Subject: [issue23591] Add IntFlags
In-Reply-To: <1425569483.33.0.144069723147.issue23591@psf.upfronthosting.co.za>
Message-ID: <1425821733.96.0.171894106828.issue23591@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I choose repr() so that for single flag it looks as for IntEnum instance. Other variants except <Perm.R|Perm.W: 3> have different format. <Perm.R|Perm.W: 3> is too verbose, it repeats the same class name multiple times.

But I don't like current repr.

Other operators are not overridden for purpose. IntFlags is int and can be used in all cases when int is used, but not in all cases the result should preserve the type. FLAG1 + FLAG2 works as if flags would be ints, but it should be rewritten to FLAG1 | FLAG2 to got the benefit from using IntFlags.

However I forgot to override the exclusive-or operator. It should be overridden.

Updated patch changes str and repr, override the exclusive-or operator and adds some documentation.

----------
Added file: http://bugs.python.org/file38387/intflags_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23591>
_______________________________________

From report at bugs.python.org  Sun Mar  8 14:36:47 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 08 Mar 2015 13:36:47 +0000
Subject: [issue18173] Add MixedTypeKey to reprlib
In-Reply-To: <1370786072.61.0.824503392112.issue18173@psf.upfronthosting.co.za>
Message-ID: <1425821807.95.0.188647009706.issue18173@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18173>
_______________________________________

From report at bugs.python.org  Sun Mar  8 14:36:53 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 08 Mar 2015 13:36:53 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <1425821813.78.0.251399011696.issue23606@psf.upfronthosting.co.za>


Steve Dower added the comment:

That was my original thought, but it's going to lose all of its named exports and effectively become useless for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23606>
_______________________________________

From report at bugs.python.org  Sun Mar  8 14:42:49 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Mar 2015 13:42:49 +0000
Subject: [issue23608] ssl.VERIFY_X509_TRUSTED_FIRST: Incorrect value for
 versionadded
In-Reply-To: <1425818090.41.0.129275996711.issue23608@psf.upfronthosting.co.za>
Message-ID: <20150308134247.1787.98648@psf.io>


Roundup Robot added the comment:

New changeset 8264652bce68 by Benjamin Peterson in branch '3.4':
indicate correct version (closes #23608)
https://hg.python.org/cpython/rev/8264652bce68

New changeset ce67f965a37d by Benjamin Peterson in branch 'default':
merge 3.4 (#23608)
https://hg.python.org/cpython/rev/ce67f965a37d

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23608>
_______________________________________

From report at bugs.python.org  Sun Mar  8 14:44:25 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 13:44:25 +0000
Subject: [issue18173] Add MixedTypeKey to reprlib
In-Reply-To: <1370786072.61.0.824503392112.issue18173@psf.upfronthosting.co.za>
Message-ID: <1425822265.7.0.341920101245.issue18173@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue22721.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18173>
_______________________________________

From report at bugs.python.org  Sun Mar  8 14:45:43 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 13:45:43 +0000
Subject: [issue11957] re.sub confusion between count and flags args
In-Reply-To: <1304101630.86.0.175815070517.issue11957@psf.upfronthosting.co.za>
Message-ID: <1425822343.05.0.436934321875.issue11957@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +Add IntFlags

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11957>
_______________________________________

From report at bugs.python.org  Sun Mar  8 15:58:25 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Mar 2015 14:58:25 +0000
Subject: [issue23279] test_site/test_startup_imports fails when mpl_toolkit or
 logilab based modules installed
In-Reply-To: <1421729308.95.0.570059573722.issue23279@psf.upfronthosting.co.za>
Message-ID: <1425826705.78.0.508222910525.issue23279@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Python's startup performance is very sensitive to what modules get imported for all Python programs. The tests that are failing for you make sure that a core developer doesn't accidentally introduce a new startup dependency and thus slow startup times without doing so purposefully. So the tests are working as intended, you unfortunately just happen to have a startup environment thanks to those .pth files which trigger the failures.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23279>
_______________________________________

From report at bugs.python.org  Sun Mar  8 16:02:51 2015
From: report at bugs.python.org (Davin Potts)
Date: Sun, 08 Mar 2015 15:02:51 +0000
Subject: [issue19989] Error while sending function code over queue
 (multiprocessing)
In-Reply-To: <1387125540.4.0.544926984003.issue19989@psf.upfronthosting.co.za>
Message-ID: <1425826971.97.0.66799927408.issue19989@psf.upfronthosting.co.za>


Davin Potts added the comment:

While the mockup of the code that you provided is of some help, it is still unclear whether the problem could originate from your hand-rolled serialization/de-serialization implementation or somewhere else.  The traceback you shared could even suggest an unrelated problem in your project's code.  Without more information or, ideally, a runnable example of the problem that can be shared, there does not appear to be a way to take this forward.

Can more information be shared or a more complete example triggering the described behavior?

----------
nosy: +davin
status: open -> pending
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19989>
_______________________________________

From report at bugs.python.org  Sun Mar  8 16:05:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 15:05:26 +0000
Subject: [issue12916] Add inspect.splitdoc
In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za>
Message-ID: <1425827126.9.0.976380422487.issue12916@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I doubt that inspect is better place for splitdoc() than pydoc. So count my voice against moving splitdoc().

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12916>
_______________________________________

From report at bugs.python.org  Sun Mar  8 16:18:44 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 08 Mar 2015 15:18:44 +0000
Subject: [issue23491] PEP 441 - Improving Python Zip Application Support
In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za>
Message-ID: <1425827924.71.0.00403937941267.issue23491@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I left a couple of minor comments on Rietveld.

----------
nosy: +berker.peksag
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23491>
_______________________________________

From report at bugs.python.org  Sun Mar  8 16:38:24 2015
From: report at bugs.python.org (Davin Potts)
Date: Sun, 08 Mar 2015 15:38:24 +0000
Subject: [issue5527] multiprocessing won't work with Tkinter (under Linux)
In-Reply-To: <1237574081.02.0.0677822756927.issue5527@psf.upfronthosting.co.za>
Message-ID: <1425829104.4.0.997381308324.issue5527@psf.upfronthosting.co.za>


Davin Potts added the comment:

Unable to reproduce on Ubuntu 12.04.5 with Python 2.7.8 and current libtk8.5 and libtcl8.5 releases using the attached hanger.py example.

Key findings to-date:
1. Posts to this issue have concluded that there exists a problem with thread- and process-safety in specific parts of Tcl library routines and that this known issue is addressed in more recent releases.
2. For those affected versions of the Tcl libraries, there is a workaround for in building those libraries to prevent the issue.
3. The Python Tkinter module (nor other standard library modules) does not appear to be a source of the described behaviors.  Furthermore, Richard offers yet another workaround through multiprocessing's spawn.


The question was raised whether there should be a note added to the Tkinter module's docs about this situation.  Because this issue is the result of particular versions on particular platforms built in a particular way and the issue appears addressed in current releases of those third party libraries, it probably makes good sense to track this sort of issue in the Tcl/Tk projects themselves and not in the Tkinter module's docs.  If others encountering this issue in the future feel it is still too easy to end up with the right (wrong) combination of platform+tcl_version+build, they are encouraged to please open a new issue requesting a note be added to the documentation for Tkinter.

Closing this issue, marking it as "third party".

----------
nosy: +davin
resolution:  -> third party
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5527>
_______________________________________

From report at bugs.python.org  Sun Mar  8 16:50:35 2015
From: report at bugs.python.org (SilentGhost)
Date: Sun, 08 Mar 2015 15:50:35 +0000
Subject: [issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal)
In-Reply-To: <1425810901.79.0.570490913636.issue23607@psf.upfronthosting.co.za>
Message-ID: <1425829835.79.0.624503292878.issue23607@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is the python-only fix that eliminates TypeError and produces correct number of milliseconds. The problem with C implementation lies in _PyTime_ObjectToDenominator function where there is an explicit check for a float. This check could be relaxed to include decimals as the rest of the code seem to work fine with decimal. I'm not entirely sure how that could be done though.

----------
keywords: +patch
nosy: +SilentGhost
stage:  -> needs patch
Added file: http://bugs.python.org/file38388/issue23607_python.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23607>
_______________________________________

From report at bugs.python.org  Sun Mar  8 16:51:29 2015
From: report at bugs.python.org (Davin Potts)
Date: Sun, 08 Mar 2015 15:51:29 +0000
Subject: [issue21505] cx_freeze multiprocessing bug
In-Reply-To: <1400047714.39.0.600066285372.issue21505@psf.upfronthosting.co.za>
Message-ID: <1425829889.76.0.462127019859.issue21505@psf.upfronthosting.co.za>


Davin Potts added the comment:

Can the OP provide a runnable example to help us understand what they are actually trying to do?

There is simply not enough information for us to go on here -- Torsten's suggestion is a good one but we need more information to help any further.

----------
nosy: +davin
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21505>
_______________________________________

From report at bugs.python.org  Sun Mar  8 17:06:42 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 08 Mar 2015 16:06:42 +0000
Subject: [issue23309] Hang on interpreter shutdown if daemon thread prints to
 stdout
In-Reply-To: <1422107560.4.0.0145420431804.issue23309@psf.upfronthosting.co.za>
Message-ID: <1425830802.28.0.534893037427.issue23309@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23309>
_______________________________________

From report at bugs.python.org  Sun Mar  8 17:11:55 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 08 Mar 2015 16:11:55 +0000
Subject: [issue23331] Add non-interactive version of Bdb.runcall
In-Reply-To: <1422364159.49.0.0950037579412.issue23331@psf.upfronthosting.co.za>
Message-ID: <1425831115.86.0.372523607537.issue23331@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23331>
_______________________________________

From report at bugs.python.org  Sun Mar  8 17:31:57 2015
From: report at bugs.python.org (Hristo Venev)
Date: Sun, 08 Mar 2015 16:31:57 +0000
Subject: [issue23609] Export PyModuleObject in moduleobject.h
Message-ID: <1425832317.75.0.265889084011.issue23609@psf.upfronthosting.co.za>


New submission from Hristo Venev:

Please export PyModuleObject in moduleobject.h.

It's useful for subclassing module in C.

----------
components: Interpreter Core
messages: 237543
nosy: h.venev
priority: normal
severity: normal
status: open
title: Export PyModuleObject in moduleobject.h
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23609>
_______________________________________

From report at bugs.python.org  Sun Mar  8 17:59:35 2015
From: report at bugs.python.org (Paul Moore)
Date: Sun, 08 Mar 2015 16:59:35 +0000
Subject: [issue23491] PEP 441 - Improving Python Zip Application Support
In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za>
Message-ID: <1425833975.79.0.0842020101092.issue23491@psf.upfronthosting.co.za>


Paul Moore added the comment:

New patch incorporating Berker's comments

----------
Added file: http://bugs.python.org/file38389/pep-441.v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23491>
_______________________________________

From report at bugs.python.org  Sun Mar  8 18:08:07 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 08 Mar 2015 17:08:07 +0000
Subject: [issue23008] pydoc enum.{,Int}Enum fails
In-Reply-To: <1418018648.34.0.0967171282391.issue23008@psf.upfronthosting.co.za>
Message-ID: <1425834487.95.0.0350482650985.issue23008@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23008>
_______________________________________

From report at bugs.python.org  Sun Mar  8 18:19:26 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 08 Mar 2015 17:19:26 +0000
Subject: [issue23081] Document PySequence_List(o) as equivalent to list(o)
In-Reply-To: <1418908520.28.0.480794985208.issue23081@psf.upfronthosting.co.za>
Message-ID: <1425835166.26.0.914150422642.issue23081@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

LGTM, can we have a formal review please.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23081>
_______________________________________

From report at bugs.python.org  Sun Mar  8 18:25:32 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 08 Mar 2015 17:25:32 +0000
Subject: [issue23384] urllib.proxy_bypass_registry slow down under Windows if
 website has no reverse DNS and Fiddler is runing
In-Reply-To: <1422954339.65.0.892974237114.issue23384@psf.upfronthosting.co.za>
Message-ID: <1425835532.35.0.0820732053716.issue23384@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
components: +Library (Lib)
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23384>
_______________________________________

From report at bugs.python.org  Sun Mar  8 18:25:36 2015
From: report at bugs.python.org (Liam Marsh)
Date: Sun, 08 Mar 2015 17:25:36 +0000
Subject: [issue23610] -m arg behavior
Message-ID: <1425835536.72.0.145087348423.issue23610@psf.upfronthosting.co.za>


New submission from Liam Marsh:

hello!

trying the solutions proposed by the 23546'th issue, i found that the -m argument, for packages (like tkinter, or idlelib; not io or socket), trys to find the "__main__" file, not the "__init__" file, which is the main file of any package.

is that a problem?

thank you for reading this, and have a nice day/evening!

----------
components: Interpreter Core, Library (Lib)
messages: 237546
nosy: Liam.Marsh
priority: normal
severity: normal
status: open
title: -m arg behavior
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23610>
_______________________________________

From report at bugs.python.org  Sun Mar  8 18:27:10 2015
From: report at bugs.python.org (Liam Marsh)
Date: Sun, 08 Mar 2015 17:27:10 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1425835630.43.0.788887225233.issue23546@psf.upfronthosting.co.za>


Liam Marsh added the comment:

the "py -m idlelib -e <file>" command failed!
(issue 23610 created)

otherwise, yes, different versions of the "edit with idle" command sounds better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sun Mar  8 18:50:40 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 17:50:40 +0000
Subject: [issue23611] Pickle nested names with protocols < 4
Message-ID: <1425837040.48.0.408829364916.issue23611@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch allows Python implementation of the pickle module to pickle nested names (e.g. methods) with protocols < 4. Pickled data is compatible with old releases.

If this is good I'll write C implementation.

----------
components: Library (Lib)
files: pickle_nested_names.patch
keywords: patch
messages: 237548
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Pickle nested names with protocols < 4
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38390/pickle_nested_names.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23611>
_______________________________________

From report at bugs.python.org  Sun Mar  8 18:56:38 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 08 Mar 2015 17:56:38 +0000
Subject: [issue23081] Document PySequence_List(o) as equivalent to list(o)
In-Reply-To: <1418908520.28.0.480794985208.issue23081@psf.upfronthosting.co.za>
Message-ID: <1425837398.67.0.803168094988.issue23081@psf.upfronthosting.co.za>


Georg Brandl added the comment:

+1

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23081>
_______________________________________

From report at bugs.python.org  Sun Mar  8 19:03:27 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 08 Mar 2015 18:03:27 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1425837807.44.0.25332453125.issue23546@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Sorry.  That has to be "py -3 ... " unless you have configured 'py' to run 3.x, or "py -m idlelib.idle ..." for 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sun Mar  8 19:42:14 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2015 18:42:14 +0000
Subject: [issue23309] Hang on interpreter shutdown if daemon thread prints to
 stdout
In-Reply-To: <1422107560.4.0.0145420431804.issue23309@psf.upfronthosting.co.za>
Message-ID: <1425840134.96.0.591130573512.issue23309@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Your analysis sounds right to me.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23309>
_______________________________________

From report at bugs.python.org  Sun Mar  8 19:51:08 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2015 18:51:08 +0000
Subject: [issue23309] Hang on interpreter shutdown if daemon thread prints to
 stdout
In-Reply-To: <1422107560.4.0.0145420431804.issue23309@psf.upfronthosting.co.za>
Message-ID: <1425840668.86.0.0155543091009.issue23309@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

A possible solution is to tweak the IO lock acquire on shutdown: only wait for a grace period instead of waiting indefinitely. Attached patch demonstrates the solution (and solves the deadlock issue in your script).

----------
keywords: +patch
nosy: +neologix
stage:  -> patch review
Added file: http://bugs.python.org/file38391/bufio_lock_finalizing.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23309>
_______________________________________

From report at bugs.python.org  Sun Mar  8 20:05:51 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2015 19:05:51 +0000
Subject: [issue23309] Hang on interpreter shutdown if daemon thread prints to
 stdout
In-Reply-To: <1422107560.4.0.0145420431804.issue23309@psf.upfronthosting.co.za>
Message-ID: <1425841551.81.0.892817976079.issue23309@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(note that trying to print a warning or raise an error only makes things worse if the stream subject to deadlock is stderr)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23309>
_______________________________________

From report at bugs.python.org  Sun Mar  8 20:25:41 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2015 19:25:41 +0000
Subject: [issue23309] Hang on interpreter shutdown if daemon thread prints to
 stdout
In-Reply-To: <1422107560.4.0.0145420431804.issue23309@psf.upfronthosting.co.za>
Message-ID: <1425842741.9.0.841953013136.issue23309@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Attached patch is stricter and dumps a fatal error after the grace period.

----------
Added file: http://bugs.python.org/file38392/bufio_lock_finalizing_fatal_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23309>
_______________________________________

From report at bugs.python.org  Sun Mar  8 20:33:02 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2015 19:33:02 +0000
Subject: [issue23588] Errno conflicts in ssl.SSLError
In-Reply-To: <1425528608.86.0.380656858337.issue23588@psf.upfronthosting.co.za>
Message-ID: <1425843182.83.0.176556150851.issue23588@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Theoretically, SSLError could stop inheriting from OSError. Practically, it may break a lot of code (though in a rather noisy way that is easy to spot).

Otherwise, the best effort fix is to make our SSL error codes start at a high number, e.g. 2000 (but not too high, so as not to overlap with Windows' socket error codes, which start at 10000 IIRC). See the "py_ssl_error" enum at the beginning of _ssl.c.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23588>
_______________________________________

From report at bugs.python.org  Sun Mar  8 20:33:14 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 08 Mar 2015 19:33:14 +0000
Subject: [issue23612] 3.5.0a2 Windows installer does not remove 3.5.0a1
Message-ID: <1425843194.22.0.54226665206.issue23612@psf.upfronthosting.co.za>


New submission from Steve Dower:

Currently, 3.5.0a1 needs to be manually removed either before or after installing 3.5.0a2 (after *should* be okay, but before is preferable).

Installing a later version should detect and remove the earlier one. This is obviously an installer bug.

----------
assignee: steve.dower
components: Windows
messages: 237556
nosy: steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: 3.5.0a2 Windows installer does not remove 3.5.0a1
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23612>
_______________________________________

From report at bugs.python.org  Sun Mar  8 20:36:00 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2015 19:36:00 +0000
Subject: [issue23613] searchindex.js is annoying
Message-ID: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Since I get hit by this at least once a week, I thought I'd finally report a bug. The Doc/build/html/searchindex.js file is extremely annoying when grepping through the source tree (and especially when grepping in the docs), because it's very likely to match your search *and* it seems made of a huge single line of text, meaning the grep output now fills your terminal with junk.

----------
assignee: docs at python
components: Documentation
messages: 237557
nosy: docs at python, pitrou
priority: normal
severity: normal
status: open
title: searchindex.js is annoying
type: behavior
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23613>
_______________________________________

From report at bugs.python.org  Sun Mar  8 20:39:43 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 08 Mar 2015 19:39:43 +0000
Subject: [issue23612] 3.5.0a2 Windows installer does not remove 3.5.0a1
In-Reply-To: <1425843194.22.0.54226665206.issue23612@psf.upfronthosting.co.za>
Message-ID: <1425843583.91.0.659267401978.issue23612@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23612>
_______________________________________

From report at bugs.python.org  Sun Mar  8 20:48:52 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Mar 2015 19:48:52 +0000
Subject: [issue22980] C extension naming doesn't take bitness into account
In-Reply-To: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za>
Message-ID: <20150308194849.7585.50269@psf.io>


Roundup Robot added the comment:

New changeset 25356d34b79b by Antoine Pitrou in branch 'default':
Issue #22980: Under Linux, C extensions now include bitness in the file name,
https://hg.python.org/cpython/rev/25356d34b79b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22980>
_______________________________________

From report at bugs.python.org  Sun Mar  8 20:49:18 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2015 19:49:18 +0000
Subject: [issue22980] C extension naming doesn't take bitness into account
In-Reply-To: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za>
Message-ID: <1425844158.72.0.343551163624.issue22980@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I've pushed the patch for Linux. I'm keeping this issue open in case other platforms may (want to) benefit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22980>
_______________________________________

From report at bugs.python.org  Sun Mar  8 20:50:00 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 08 Mar 2015 19:50:00 +0000
Subject: [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425844200.81.0.110401588349.issue23613@psf.upfronthosting.co.za>


Georg Brandl added the comment:

And what do you suggest to do about it?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23613>
_______________________________________

From report at bugs.python.org  Sun Mar  8 20:50:40 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2015 19:50:40 +0000
Subject: [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425844240.8.0.932652780193.issue23613@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

That's a good question :) Making it a normal multiline file would be good enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23613>
_______________________________________

From report at bugs.python.org  Sun Mar  8 20:54:30 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 08 Mar 2015 19:54:30 +0000
Subject: [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425844470.49.0.0423243815286.issue23613@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Well, that's not useful in a generated file.  I propose you exclude the doc build tree from your search, or use a grepping tool like ag that ignores files ignored by the vcs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23613>
_______________________________________

From report at bugs.python.org  Sun Mar  8 20:57:29 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2015 19:57:29 +0000
Subject: [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425844649.77.0.695516065136.issue23613@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Well, that's not useful in a generated file.

Well, here's a case where it's useful... Asking me to change tools is quite obvious and quite pointless at the same time. How about we respond to all Windows-specific issues with "switch to Linux"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23613>
_______________________________________

From report at bugs.python.org  Sun Mar  8 21:03:51 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 08 Mar 2015 20:03:51 +0000
Subject: [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425845031.95.0.423489475034.issue23613@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> How about we respond to all Windows-specific issues with "switch to Linux"?

How about we don't respond to strawman arguments?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23613>
_______________________________________

From report at bugs.python.org  Sun Mar  8 21:06:32 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 08 Mar 2015 20:06:32 +0000
Subject: [issue23613] searchindex.js is annoying
In-Reply-To: <1425844649.77.0.695516065136.issue23613@psf.upfronthosting.co.za>
Message-ID: <54FCABC4.9020402@egenix.com>


Marc-Andre Lemburg added the comment:

On 08.03.2015 20:57, Antoine Pitrou wrote:
> 
> Antoine Pitrou added the comment:
> 
>> Well, that's not useful in a generated file.
> 
> Well, here's a case where it's useful... Asking me to change tools is quite obvious and quite pointless at the same time. How about we respond to all Windows-specific issues with "switch to Linux"?

Georg suggested excluding the file from your search. That's a very
reasonable answer.

You don't have to change your tools for this,
just configure them to not look in .js files or perhaps not look
in this particular file if it returns false positives for you.

I'd suggest to close this as "wont fix".

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23613>
_______________________________________

From report at bugs.python.org  Sun Mar  8 21:16:59 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 08 Mar 2015 20:16:59 +0000
Subject: [issue23612] 3.5.0a2 Windows installer does not remove 3.5.0a1
In-Reply-To: <1425843194.22.0.54226665206.issue23612@psf.upfronthosting.co.za>
Message-ID: <1425845819.16.0.231450099197.issue23612@psf.upfronthosting.co.za>


Steve Dower added the comment:

Looks like the way I was calculating the version number of the installer didn't take into account a2 and a3 - we had 3.5.0.10 for 3.5.0a*.

I think switching to $(Major).$(Minor).$(Field3Value).0 is correct here - this should give us 3.5.100.0, 3.5.101.0, 3.5.102.0 for 3.5.0a1-3, then 3.5.1100.0 for 3.5.1a1, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23612>
_______________________________________

From report at bugs.python.org  Sun Mar  8 21:45:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 20:45:17 +0000
Subject: [issue23611] Pickle nested names with protocols < 4
In-Reply-To: <1425837040.48.0.408829364916.issue23611@psf.upfronthosting.co.za>
Message-ID: <1425847517.74.0.920034854884.issue23611@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed few bugs and added C implementation.

----------
Added file: http://bugs.python.org/file38393/pickle_nested_names_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23611>
_______________________________________

From report at bugs.python.org  Sun Mar  8 21:50:21 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2015 20:50:21 +0000
Subject: [issue23611] Pickle nested names with protocols < 4
In-Reply-To: <1425837040.48.0.408829364916.issue23611@psf.upfronthosting.co.za>
Message-ID: <1425847821.64.0.762928867841.issue23611@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Interesting. I have only skimmed through the patch, but +1 on the principle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23611>
_______________________________________

From report at bugs.python.org  Sun Mar  8 22:15:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 21:15:01 +0000
Subject: [issue23611] Pickle nested names with protocols < 4
In-Reply-To: <1425837040.48.0.408829364916.issue23611@psf.upfronthosting.co.za>
Message-ID: <1425849301.64.0.032942257597.issue23611@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file38390/pickle_nested_names.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23611>
_______________________________________

From report at bugs.python.org  Sun Mar  8 22:16:52 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 08 Mar 2015 21:16:52 +0000
Subject: [issue20613] Wrong line information in bytecode generated by compiler
 module
In-Reply-To: <1392261429.58.0.605484301904.issue20613@psf.upfronthosting.co.za>
Message-ID: <1425849412.03.0.607427595995.issue20613@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Am I correct in assuming that we'd need to fix a regression in 2.7 owing to its extended life span, or would the compiler being deprecated make this not worth the trouble, or what?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20613>
_______________________________________

From report at bugs.python.org  Sun Mar  8 22:25:50 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Mar 2015 21:25:50 +0000
Subject: [issue12916] Add inspect.splitdoc
In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za>
Message-ID: <1425849950.93.0.470385941808.issue12916@psf.upfronthosting.co.za>


Martin Panter added the comment:

Serhiy, would you be in favour of making it public in the pydoc module, as originally suggested by Yury in <https://bugs.python.org/issue12916#msg216238>, or some other module, or are you saying to reject this completely?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12916>
_______________________________________

From report at bugs.python.org  Sun Mar  8 22:31:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 21:31:35 +0000
Subject: [issue12916] Add inspect.splitdoc
In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za>
Message-ID: <1425850295.89.0.721399546778.issue12916@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I support Yury.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12916>
_______________________________________

From report at bugs.python.org  Sun Mar  8 22:36:35 2015
From: report at bugs.python.org (Chris Angelico)
Date: Sun, 08 Mar 2015 21:36:35 +0000
Subject: [issue23614] Opaque error message on UTF-8 decoding to surrogates
Message-ID: <1425850595.48.0.491367645605.issue23614@psf.upfronthosting.co.za>


New submission from Chris Angelico:

>>> b"\xed\xb4\x80".decode("utf-8")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position
0: invalid continuation byte

The actual problem here is that this byte sequence would decode to U+DD00, which, being a surrogate, is invalid for the encoding. It's correct to raise UnicodeDecodeError, but the text of the message is a bit obscure. I'm not sure whether the "invalid continuation byte" is talking about the "0xed in position 0" or about one of the others; 0xED is not a continuation byte, it's a start byte - and a perfectly valid one:

>>> b"\xed\x9f\xbf".decode("utf-8")
'\ud7ff'

Pike is more explicit about what the problem is:

> utf8_to_string("\xed\xb4\x80");
UTF-8 sequence beginning with 0xed 0xb4 at index 0 would decode to a
UTF-16 surrogate character.

Is this something worth fixing?

Tested on 3.4.2 and a recent build of 3.5, probably applies to most 3.x versions. (2.7 actually permits this, which is a bigger bug, but one with backward-compatibility issues.)

----------
components: Interpreter Core, Unicode
messages: 237572
nosy: Rosuav, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: Opaque error message on UTF-8 decoding to surrogates
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23614>
_______________________________________

From report at bugs.python.org  Sun Mar  8 23:01:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 22:01:15 +0000
Subject: [issue23614] Opaque error message on UTF-8 decoding to surrogates
In-Reply-To: <1425850595.48.0.491367645605.issue23614@psf.upfronthosting.co.za>
Message-ID: <1425852075.34.0.13850975232.issue23614@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

UTF-8 codec can't decode byte 0xed because 0xed is not valid UTF-8 sequence and following byte is not expected valid continuation byte.

UTF-8 codec can produce errors of three types:

* "invalid start byte". When the byte is not start byte of UTF-8 sequence (%x00-7F, %xC2-F4).
* "invalid continuation byte".  When the byte that follow unfinished UTF-8 sequence is not valid continuation byte (the validity depends on previous byte).
* "unexpected end of data". When the there are no bytes after unfinished UTF-8 sequence.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23614>
_______________________________________

From report at bugs.python.org  Sun Mar  8 23:03:10 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Sun, 08 Mar 2015 22:03:10 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425852190.75.0.168745998267.issue23496@psf.upfronthosting.co.za>


Ryan Gonzalez added the comment:

I'm getting a weird error message building python:

ryan at DevPC-LX:~/stuff/cpydroid$ make
_PYTHON_PROJECT_BASE=/home/ryan/stuff/cpython _PYTHON_HOST_PLATFORM=linux-arm PYTHONPATH=./Lib:./Lib/plat-linux python3 -S -m sysconfig --generate-posix-vars ;\
	if test $? -ne 0 ; then \
		echo "generate-posix-vars failed" ; \
		rm -f ./pybuilddir.txt ; \
		exit 1 ; \
	fi
Could not import runpy module
Traceback (most recent call last):
  File "./Lib/runpy.py", line 15, in <module>
    import importlib.util
  File "./Lib/importlib/util.py", line 6, in <module>
    from ._bootstrap import module_from_spec
ImportError: cannot import name 'module_from_spec'
generate-posix-vars failed
make: *** [pybuilddir.txt] Error 1
ryan at DevPC-LX:~/stuff/cpydroid$ 


I'm trying to build for generic ARM Linux before I attempt updating the changes. Makes sense theoretically.

Then again, when using autotools, NOTHING ever makes sense. I'm probably looking in the wrong direction...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Sun Mar  8 23:19:19 2015
From: report at bugs.python.org (Tuomas Suutari)
Date: Sun, 08 Mar 2015 22:19:19 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425809206.06.0.586241626175.issue23602@psf.upfronthosting.co.za>
Message-ID: <CAPXCX8D4sEtSGsT+aF4K75FF_nBBLN5BXe0e6mBx0qi-TGYOyA@mail.gmail.com>


Tuomas Suutari added the comment:

Eric V. Smith wrote:
> I'm not sure it needs fixing: it follows from the definition of using Decimal(num) / Decimal(denom). Plus, it's controllable with a decimal context:

Hmm... Even though it's tempting to agree with you and just ignore the
precision bug, but to be honest I have to agree with Martin Panter
here. Depending on the current decimal context is not the way of
"Least Surprise" when formatting Fractions.

> For all of the tests, I suggest using format(value, str) instead of ''.format(value). It more directly tests Fraction.__format__.

I agree. Will change those.

> In general I think adding Fraction.__format__ is a good idea, and I think converting to Decimal is reasonable for the specified codes. My only question is what to do when "natively" formatting Fractions themselves. We might want to support field widths, padding, etc.

Thanks! Actually I already tried to support field widths, padding and
such. (See the test cases.) Or what do you mean?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Sun Mar  8 23:27:32 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 22:27:32 +0000
Subject: [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425853652.94.0.207731726549.issue23613@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Lib/pydoc_data/topics.py was extremely annoying to me for the same reason. I even didn't know about Doc/build/html/searchindex.js because it has different extension. Finally I had written few scripts like:

$ cat ~/bin/findpy
#!/bin/sh
find * -name '*.py' ! -path '*Lib/pydoc_data/topics.py' ! -path '*Lib/plat-*' -exec egrep -n --color "$@" '{}' +

and similar for *.[ch] and *.rst, and forgot about this problem.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23613>
_______________________________________

From report at bugs.python.org  Sun Mar  8 23:28:17 2015
From: report at bugs.python.org (Sven Brauch)
Date: Sun, 08 Mar 2015 22:28:17 +0000
Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes
 returned from ast.parse
In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za>
Message-ID: <1425853697.62.0.577249906717.issue21295@psf.upfronthosting.co.za>


Sven Brauch added the comment:

Why did you not CC me in this discussion? It is not very nice to have this behaviour changed back from what I relied upon in a minor version without notice.

Which regression was effectively caused by this patch, except for the documentation being out of date?

----------
nosy: +scummos

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21295>
_______________________________________

From report at bugs.python.org  Sun Mar  8 23:29:51 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Mar 2015 22:29:51 +0000
Subject: [issue23612] 3.5.0a2 Windows installer does not remove 3.5.0a1
In-Reply-To: <1425843194.22.0.54226665206.issue23612@psf.upfronthosting.co.za>
Message-ID: <20150308222948.16647.46044@psf.io>


Roundup Robot added the comment:

New changeset 97e01e107591 by Steve Dower in branch 'default':
Issue #23612: Fixes upgrade code and version for Windows installer.
https://hg.python.org/cpython/rev/97e01e107591

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23612>
_______________________________________

From report at bugs.python.org  Sun Mar  8 23:33:34 2015
From: report at bugs.python.org (Tuomas Suutari)
Date: Sun, 08 Mar 2015 22:33:34 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1425854014.72.0.894833628368.issue23602@psf.upfronthosting.co.za>


Tuomas Suutari added the comment:

Here's the next round of the patch.

For formatting fractions with any given precision I had to parse the precision from format specifier and at this point it seemed easier to just create a general parser for the Format Specification Mini-Language.  In this patch it is implemented in fractions._parse_format_specifier function, but maybe this kind of general function should be moved to better place and be documented and exported. What do you think?

----------
Added file: http://bugs.python.org/file38394/issue23602v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Sun Mar  8 23:36:18 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 08 Mar 2015 22:36:18 +0000
Subject: [issue23612] 3.5.0a2 Windows installer does not remove 3.5.0a1
In-Reply-To: <1425843194.22.0.54226665206.issue23612@psf.upfronthosting.co.za>
Message-ID: <1425854178.11.0.107731514058.issue23612@psf.upfronthosting.co.za>


Steve Dower added the comment:

Two parts to this - first that I was using the wrong version, but also the wrong upgrade code for the bundle. Those are both fixed now, but it does mean that both 3.5.0a1 and a2 will need to be manually uninstalled.

It is possible to add a list of the upgrade codes that have already been released and remove those too, but since they are only alphas I'm not worried about requiring manual uninstall of those versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23612>
_______________________________________

From report at bugs.python.org  Sun Mar  8 23:44:49 2015
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 08 Mar 2015 22:44:49 +0000
Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes
 returned from ast.parse
In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za>
Message-ID: <1425854689.8.0.578362008083.issue21295@psf.upfronthosting.co.za>


Mark Shannon added the comment:

You are on the nosy list. You should have got sent an email.

This bug is the regression.
https://hg.python.org/cpython/rev/7c5c678e4164/ resulted in incorrect column offsets for many compound expressions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21295>
_______________________________________

From report at bugs.python.org  Sun Mar  8 23:54:12 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Mar 2015 22:54:12 +0000
Subject: [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425855252.11.0.561494486813.issue23613@psf.upfronthosting.co.za>


Martin Panter added the comment:

My own one-liner kicking around in my Bash history that uses GNU Grep options to avoid specific files and directories:

grep -r . --exclude-dir={.git,.hg} --exclude={refcounts.dat,"*.js"} -nIwe PIPE_MAX_SIZE

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23613>
_______________________________________

From report at bugs.python.org  Mon Mar  9 00:23:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Mar 2015 23:23:41 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1425857021.1.0.762265375186.issue23602@psf.upfronthosting.co.za>


Martin Panter added the comment:

Regarding sharing fractions._parse_format_specifier(), perhaps have a look at _pydecimal._parse_format_specifier()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Mon Mar  9 00:38:14 2015
From: report at bugs.python.org (Neil Girdhar)
Date: Sun, 08 Mar 2015 23:38:14 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1425857894.93.0.551288795189.issue2292@psf.upfronthosting.co.za>


Changes by Neil Girdhar <mistersheik at gmail.com>:


Added file: http://bugs.python.org/file38395/starunpack36.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Mon Mar  9 01:37:38 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 09 Mar 2015 00:37:38 +0000
Subject: [issue23610] -m arg behavior
In-Reply-To: <1425835536.72.0.145087348423.issue23610@psf.upfronthosting.co.za>
Message-ID: <1425861458.1.0.959933869283.issue23610@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

This is intentional and documented behavior: https://docs.python.org/3/library/__main__.html

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23610>
_______________________________________

From report at bugs.python.org  Mon Mar  9 01:39:26 2015
From: report at bugs.python.org (Sven Brauch)
Date: Mon, 09 Mar 2015 00:39:26 +0000
Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes
 returned from ast.parse
In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za>
Message-ID: <1425861566.91.0.0653389976653.issue21295@psf.upfronthosting.co.za>


Sven Brauch added the comment:

Hmm, strange, I did not receive any emails.

"Incorrect" by what definition of incorrect? The word does not really help to clarify the issue you see with this change, since the behaviour was changed on purpose. What is the (preferably real-world) application which is broken by this change?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21295>
_______________________________________

From report at bugs.python.org  Mon Mar  9 01:44:40 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 09 Mar 2015 00:44:40 +0000
Subject: [issue20617] test_ssl does not use mock
In-Reply-To: <1392292104.23.0.984787666166.issue20617@psf.upfronthosting.co.za>
Message-ID: <1425861880.61.0.0909977922768.issue20617@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
keywords: +patch
versions: +Python 3.5 -Python 3.4
Added file: http://bugs.python.org/file38396/issue20617.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20617>
_______________________________________

From report at bugs.python.org  Mon Mar  9 01:51:17 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 09 Mar 2015 00:51:17 +0000
Subject: [issue23529] Limit decompressed data when reading from LZMAFile,
 BZ2File, GzipFile
In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za>
Message-ID: <1425862277.29.0.270956146884.issue23529@psf.upfronthosting.co.za>


Martin Panter added the comment:

I have decided not to reuse the same _DecompressReader for the "gzip" module. This is because the code for parsing the "gzip" header pulls in data by calling read(), and I would have to adapt this code to accept whatever data is pushed to it via a decompress() method. However I have rewritten the ?gzip? module to use BufferedReader, removing its own readline() etc implementations.

I have split the BaseStream and DecompressReader classes into a new file called Lib/_compression.py. Let me know if there is anything else to be done to add a new file in the Lib/ directory, or if you have any better ideas where these classes should live.

Other changes in the new patch (LZMAFile-etc.v4.patch):
* Fix documented GzipFile.peek(n) signature to match implementation
* Removed unused and inconsistent code paths in gzip._PaddedFile
* New code assumes zlib.decompressobj().flush() returns a limited amount of data, since it has no ?max_length? parameter. In reality I think flush() does not do anything at all and should be deprecated or removed; see Issue 23200.

I hope that the patch does not need any more major changes, so it should be ready for review. There are a few more suggested enhancements that I have not implemented. While they would be nice, I would prefer to handle them in separate bugs and patches. I believe strengthening Python against gzip bombs is important, and any extra refactoring of the code will probably make things harder to review, more likely to break, and less likely to make it into 3.5.

Some possible enhancements I did not do:
* Support open(buffering=...) parameter, passing through to the [...]File(buffer_size=...) parameter
* open(buffering=0) returning an unbuffered reader object, probably just a direct DecompressReader instance
* detach() method on the BufferedIOBase file classes
* Further factoring out of a common CompressedFile base class
* Apply the buffer size parameter to write mode
* Rewrite the gzip module to use the common DecompressReader base class

----------
title: Limit decompressed data when reading from LZMAFile and BZ2File -> Limit decompressed data when reading from LZMAFile, BZ2File, GzipFile
Added file: http://bugs.python.org/file38397/LZMAFile-etc.v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23529>
_______________________________________

From report at bugs.python.org  Mon Mar  9 01:53:27 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 09 Mar 2015 00:53:27 +0000
Subject: [issue20257] test_socket fails if using tipc module and SELinux
 enabled
In-Reply-To: <1389692362.24.0.80510230142.issue20257@psf.upfronthosting.co.za>
Message-ID: <1425862407.95.0.983091844195.issue20257@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

LGTM so can we have a formal patch review please, thanks.

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20257>
_______________________________________

From report at bugs.python.org  Mon Mar  9 02:21:09 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 09 Mar 2015 01:21:09 +0000
Subject: [issue23615] Reloading tokenize breaks tokenize.open()
Message-ID: <1425864069.02.0.403381374988.issue23615@psf.upfronthosting.co.za>


New submission from Thomas Kluyver:

Issue #22599 changed tokenize.open() from using builtins.open() to having a module-level reference to _builtin_open, stored by doing _builtin_open = open. However, on reloading the module, _builtin_open is pointed to tokenize.open from the last execution of the code, breaking tokenize.open():

>>> import tokenize
>>> tokenize.open
<function open at 0x7f15b660fc80>
>>> tokenize._builtin_open
<built-in function open>
>>> import imp; imp.reload(tokenize)
<module 'tokenize' from '/home/takluyver/miniconda3/envs/py34/lib/python3.4/tokenize.py'>
>>> tokenize.open
<function open at 0x7f15b660fbf8>
>>> tokenize._builtin_open
<function open at 0x7f15b660fc80>
>>> tokenize.open('foo.py')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/takluyver/miniconda3/envs/py34/lib/python3.4/tokenize.py", line 438, in open
    buffer = _builtin_open(filename, 'rb')
TypeError: open() takes 1 positional argument but 2 were given

The actual case where I'm seeing this error is nose logging a failure in a test suite, so it's not clear what is reloading tokenize, but it appears that something is. This just started failing when our Windows test system updated to Python 3.4.3.

----------
components: Library (Lib)
messages: 237588
nosy: haypo, takluyver
priority: normal
severity: normal
status: open
title: Reloading tokenize breaks tokenize.open()
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23615>
_______________________________________

From report at bugs.python.org  Mon Mar  9 03:28:51 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 09 Mar 2015 02:28:51 +0000
Subject: [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1425868131.84.0.712709341864.issue22341@psf.upfronthosting.co.za>


Martin Panter added the comment:

Posting a new patch that also removes the masking from the gzip, zipfile, tarfile, and test_zlib modules. I removed the comment about signedness in tarfile; let me know if you saw any others.

----------
versions: +Python 3.5 -Python 3.4
Added file: http://bugs.python.org/file38398/crc-sign.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22341>
_______________________________________

From report at bugs.python.org  Mon Mar  9 04:30:55 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 Mar 2015 03:30:55 +0000
Subject: [issue19610] setup.py does not allow a tuple for classifiers
In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za>
Message-ID: <1425871855.95.0.939263257733.issue19610@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I think the change is acceptable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19610>
_______________________________________

From report at bugs.python.org  Mon Mar  9 05:36:11 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 09 Mar 2015 04:36:11 +0000
Subject: [issue23610] -m arg behavior
In-Reply-To: <1425835536.72.0.145087348423.issue23610@psf.upfronthosting.co.za>
Message-ID: <1425875771.13.0.827470627868.issue23610@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23610>
_______________________________________

From report at bugs.python.org  Mon Mar  9 05:45:15 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 09 Mar 2015 04:45:15 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425837807.44.0.25332453125.issue23546@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-PXAetLcm7rZRLUFd96HLOiF=xyuzeA-podUeJ04f1ciQ@mail.gmail.com>


Zachary Ware added the comment:

Terry J. Reedy added the comment:
> Sorry.  That has to be "py -3 ... " unless you have configured 'py' to
run 3.x, or "py -m idlelib.idle ..." for 2.7.
>

Any reason not to add idlelib.__main__ to 2.7? It works the same in either
version, as far as I can tell.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Mon Mar  9 06:31:46 2015
From: report at bugs.python.org (Ashish Sadanandan)
Date: Mon, 09 Mar 2015 05:31:46 +0000
Subject: [issue23603] Embedding Python3.4 - PyUnicode_Check fails (MinGW-W64)
In-Reply-To: <1425758526.01.0.875818979723.issue23603@psf.upfronthosting.co.za>
Message-ID: <1425879106.65.0.903641376686.issue23603@psf.upfronthosting.co.za>


Ashish Sadanandan added the comment:

Thanks for the reply. MSVC does produce the expected results, I forgot to mention that earlier.

So I guess this means I can't realistically expect anyone to look into this problem? I can switch to MSVC but the spotty C++11/14 support is irritating to have to live with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23603>
_______________________________________

From report at bugs.python.org  Mon Mar  9 06:31:53 2015
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 09 Mar 2015 05:31:53 +0000
Subject: [issue22928] HTTP header injection in
 urrlib2/urllib/httplib/http.client
In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za>
Message-ID: <1425879113.65.0.795023005504.issue22928@psf.upfronthosting.co.za>


Demian Brecht added the comment:

After a chat with David and getting my head wrapped more around backwards compatibility, I also agree that the changes in the patch are far too strict. It's much more important to preserve backwards compatibility than to strictly conform to the RFC.

I've updated the patch to allow for (what should be) anything that was previously allowed as header name/value pairs minus carriage returns not immediately followed by a tab or space (obs-fold: CRLF 1*( SP / HTAB )). This change fixes the reported issue but should not otherwise affect backwards compatibility.

Additionally, even though line folding is deprecated by RFC 7230, I don't think it's necessarily an issue to support line folding until proven to be a problem in practice. With the current implementation, users have the ability to conform to the target server/proxy requirements, based on errors (if obs-fold isn't transparently dealt with as suggested) yielded by each as defined in the RFC. In light of that, I don't think that it's even worthwhile to start deprecating multi-parameter putheader at this point (but I'm open to argument on that one).

One note on the deprecation is that if we deprecate multi-parameter, we should also add a warning if an embedded line fold is detected in a single headers value.

----------
Added file: http://bugs.python.org/file38399/issue22928_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22928>
_______________________________________

From report at bugs.python.org  Mon Mar  9 07:18:26 2015
From: report at bugs.python.org (Davide Okami)
Date: Mon, 09 Mar 2015 06:18:26 +0000
Subject: [issue23616] Python IDLE (2.-3.)
Message-ID: <1425881906.7.0.913975027091.issue23616@psf.upfronthosting.co.za>


New submission from Davide Okami:

Keeping pressed the undo shortcut during a cycle until returning to the cycle declaration, IDLE will react deleting the declaration [1] or overlaying it on the result/s [2] ([2] intermittently and un-effectively on cycle execution).

----------
components: IDLE
files: Schermata 2015-03-09 alle 06.53.21.png
messages: 237594
nosy: Davide Okami
priority: normal
severity: normal
status: open
title: Python IDLE (2.-3.)
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38400/Schermata 2015-03-09 alle 06.53.21.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23616>
_______________________________________

From report at bugs.python.org  Mon Mar  9 07:22:38 2015
From: report at bugs.python.org (Davide Okami)
Date: Mon, 09 Mar 2015 06:22:38 +0000
Subject: [issue23616] Conflict between generic cycle and undo shortcut.
In-Reply-To: <1425881906.7.0.913975027091.issue23616@psf.upfronthosting.co.za>
Message-ID: <1425882158.29.0.176057889952.issue23616@psf.upfronthosting.co.za>


Davide Okami added the comment:

Keeping pressed the undo shortcut during a cycle until returning to the cycle declaration, IDLE will react deleting the declaration [1] or overlaying it on the result/s [2] ([2] intermittently and un-effectively on cycle execution).

----------
title: Python IDLE (2.-3.) -> Conflict between generic cycle and undo shortcut.
Added file: http://bugs.python.org/file38401/Schermata 2015-03-09 alle 06.53.21.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23616>
_______________________________________

From report at bugs.python.org  Mon Mar  9 07:23:16 2015
From: report at bugs.python.org (Davide Okami)
Date: Mon, 09 Mar 2015 06:23:16 +0000
Subject: [issue23616] Conflict between generic cycle and undo shortcut.
In-Reply-To: <1425881906.7.0.913975027091.issue23616@psf.upfronthosting.co.za>
Message-ID: <1425882195.99.0.554248841682.issue23616@psf.upfronthosting.co.za>


Changes by Davide Okami <dvxxx3 at gmail.com>:


Removed file: http://bugs.python.org/file38401/Schermata 2015-03-09 alle 06.53.21.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23616>
_______________________________________

From report at bugs.python.org  Mon Mar  9 07:52:16 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Mar 2015 06:52:16 +0000
Subject: [issue19610] setup.py does not allow a tuple for classifiers
In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za>
Message-ID: <1425883936.36.0.508854667298.issue19610@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What about other list parameters? platform, keywords, provides, requires, obsoletes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19610>
_______________________________________

From report at bugs.python.org  Mon Mar  9 07:53:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Mar 2015 06:53:54 +0000
Subject: [issue19610] setup.py does not allow a tuple for classifiers
In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za>
Message-ID: <1425884034.44.0.809180720824.issue19610@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I don't know in which cases a value should be a (key, value) tuple.

I think this is for field 'content' only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19610>
_______________________________________

From report at bugs.python.org  Mon Mar  9 07:54:24 2015
From: report at bugs.python.org (SilentGhost)
Date: Mon, 09 Mar 2015 06:54:24 +0000
Subject: [issue23616] Conflict between generic cycle and undo shortcut.
In-Reply-To: <1425881906.7.0.913975027091.issue23616@psf.upfronthosting.co.za>
Message-ID: <1425884064.5.0.759489338934.issue23616@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +kbk, roger.serwy, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23616>
_______________________________________

From report at bugs.python.org  Mon Mar  9 07:56:35 2015
From: report at bugs.python.org (Kentrell Johnson)
Date: Mon, 09 Mar 2015 06:56:35 +0000
Subject: [issue23617] Incorrect plural "includes" on Python Standard Library
 front page
Message-ID: <1425884195.77.0.695422727516.issue23617@psf.upfronthosting.co.za>


New submission from Kentrell Johnson:

"The Python installers for the Windows platform usually includes"

should be

"The Python installers for the Windows platform usually include"

----------
assignee: docs at python
components: Documentation
messages: 237598
nosy: docs at python, kentrell.johnson
priority: normal
severity: normal
status: open
title: Incorrect plural "includes" on Python Standard Library front page
type: enhancement
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23617>
_______________________________________

From report at bugs.python.org  Mon Mar  9 08:03:52 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Mar 2015 07:03:52 +0000
Subject: [issue23616] Conflict between generic cycle and undo shortcut.
In-Reply-To: <1425881906.7.0.913975027091.issue23616@psf.upfronthosting.co.za>
Message-ID: <1425884632.18.0.124427208664.issue23616@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: http://bugs.python.org/msg237595

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23616>
_______________________________________

From report at bugs.python.org  Mon Mar  9 08:11:58 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Mar 2015 07:11:58 +0000
Subject: [issue23616] Idle: conflict between generic cycle and undo shortcut.
In-Reply-To: <1425881906.7.0.913975027091.issue23616@psf.upfronthosting.co.za>
Message-ID: <1425885118.04.0.17940157087.issue23616@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

(Duplicate message unlinked).  I do not know what you mean by a 'cycle', 'generic cycle', or 'cycle declaration'.  Python's only declarations are global and nonlocal statements.  The image does not help me except to specify OSX (latest version) an 3.4.2.  Please describe what you actually did in enough detail that I could do the same.  What is the undo shortcut on OSX, or specifically your machine?

----------
stage:  -> test needed
title: Conflict between generic cycle and undo shortcut. -> Idle: conflict between generic cycle and undo shortcut.
versions:  -Python 3.2, Python 3.3, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23616>
_______________________________________

From report at bugs.python.org  Mon Mar  9 08:31:45 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 09 Mar 2015 07:31:45 +0000
Subject: [issue12916] Add inspect.splitdoc
In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za>
Message-ID: <1425886305.96.0.682868520614.issue12916@psf.upfronthosting.co.za>


Berker Peksag added the comment:

pydoc doesn't have public API other than its CLI and the help() function. I'd cleanup or even rewrite pydoc before declare anything public in it. On the other hand, there are already functions related to splitdoc() in the inspect module: https://docs.python.org/3/library/inspect.html#retrieving-source-code See also issue 18956.

There is no rush to make splitdoc() public. We can improve pydoc in 3.5 and 3.6 timeline and then decide what's should be part of the public API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12916>
_______________________________________

From report at bugs.python.org  Mon Mar  9 09:12:44 2015
From: report at bugs.python.org (Davide Okami)
Date: Mon, 09 Mar 2015 08:12:44 +0000
Subject: [issue23616] Idle: conflict between loop execution and undo shortcut.
In-Reply-To: <1425881906.7.0.913975027091.issue23616@psf.upfronthosting.co.za>
Message-ID: <1425888764.97.0.443695027483.issue23616@psf.upfronthosting.co.za>


Davide Okami added the comment:

Sorry for my bad technical acknowledgment, i will try to be more understandable.
Declaring a while loop statement, and launching the loop pressing enter, it is possible to delete loop results and return to the while declaration statement deleting it [1] or it's possibile to make it disappear from the line in which it was declared [2] [[2] making it appear on the loop result (overlaying it)] without breaking the loop execution [1][2]. Both are possible keeping pressed the shortcut command+z (?+z) after that loop runs (keeping it pressed until the loop statement is reached and deleted [1], or keeping it pressed for a little less time than before, to manifest the second behavior). The bug afflicts Python IDLE for OS X (i tried with a clean installation of Python 3.4.3 and i tried it also on Windows without results) in versions 2.7.8, 3.4.x (as i tried).

----------
title: Idle: conflict between generic cycle and undo shortcut. -> Idle: conflict between loop execution and undo shortcut.
versions: +Python 3.2, Python 3.3 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23616>
_______________________________________

From report at bugs.python.org  Mon Mar  9 09:26:32 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 09 Mar 2015 08:26:32 +0000
Subject: [issue20602] sys.flags and sys.float_info disappear at shutdown
In-Reply-To: <1392146521.44.0.544055558433.issue20602@psf.upfronthosting.co.za>
Message-ID: <1425889592.3.0.095451517155.issue20602@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20602>
_______________________________________

From report at bugs.python.org  Mon Mar  9 09:34:11 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 09 Mar 2015 08:34:11 +0000
Subject: [issue20233] Re-enable buffer API slots for heap types
In-Reply-To: <1389584815.64.0.0171986621456.issue20233@psf.upfronthosting.co.za>
Message-ID: <1425890051.1.0.480405961357.issue20233@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I've updated the nosy list with the names from #10181 as that's referenced in msg208002.

----------
nosy: +BreamoreBoy, haypo, jcon, joshtriplett, kristjan.jonsson, loewis, mark.dickinson, petri.lehtinen, pitrou, pmoore, pv, python-dev, rupole, skrah, teoliphant

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20233>
_______________________________________

From report at bugs.python.org  Mon Mar  9 09:35:21 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Mar 2015 08:35:21 +0000
Subject: [issue12916] Add inspect.splitdoc
In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za>
Message-ID: <1425890121.91.0.324103652182.issue12916@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

My opposition against moving splitdoc() to the inspect module is not strict and I don't want to fight for it. In an case two-and-a-half votes are larger than one-and-a-half.

When you move splitdoc(), you should get rid of the use pydoc.splitdoc() in the stdlib and add DeprecatedWarning assertion to the test of pydoc.splitdoc(). The existence of pydoc.splitdoc() test is an argument to keep splitdoc() in the pydoc module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12916>
_______________________________________

From report at bugs.python.org  Mon Mar  9 09:37:26 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 09 Mar 2015 08:37:26 +0000
Subject: [issue20233] Re-enable buffer API slots for heap types
In-Reply-To: <1389584815.64.0.0171986621456.issue20233@psf.upfronthosting.co.za>
Message-ID: <1425890246.68.0.976993427467.issue20233@psf.upfronthosting.co.za>


Changes by Paul Moore <p.f.moore at gmail.com>:


----------
nosy:  -pmoore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20233>
_______________________________________

From report at bugs.python.org  Mon Mar  9 09:41:41 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Mar 2015 08:41:41 +0000
Subject: [issue20602] sys.flags and sys.float_info disappear at shutdown
In-Reply-To: <1392146521.44.0.544055558433.issue20602@psf.upfronthosting.co.za>
Message-ID: <1425890501.87.0.32626453704.issue20602@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I don't understand this bug report. Can you elaborate? What is the current behaviour? What is the expected behaviour?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20602>
_______________________________________

From report at bugs.python.org  Mon Mar  9 09:47:36 2015
From: report at bugs.python.org (Marien Zwart)
Date: Mon, 09 Mar 2015 08:47:36 +0000
Subject: [issue23309] Hang on interpreter shutdown if daemon thread prints to
 stdout
In-Reply-To: <1422107560.4.0.0145420431804.issue23309@psf.upfronthosting.co.za>
Message-ID: <1425890856.06.0.682486398419.issue23309@psf.upfronthosting.co.za>


Marien Zwart added the comment:

I'm afraid I don't have real-world code I can confirm is fixed, since I reported this on behalf of someone on irc in #python.

I think I'd prefer the Py_FatalError version of the patch. It's definitely possible to see writes to stdout/stderr at this time. If I read the first version right, it'll succeed the ENTER_BUFFERED without actually grabbing the lock, which seems problematic. But failing ENTER_BUFFERED is probably also more problematic, as it will probably lead to another exception that Python'll try to write to stderr, which fails the same way... If stdout/stderr are in a broken state during shutdown, Python is probably better off calling Py_FatalError rather than intermittently discarding messages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23309>
_______________________________________

From report at bugs.python.org  Mon Mar  9 09:56:11 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Mar 2015 08:56:11 +0000
Subject: [issue23617] Incorrect plural "includes" on Python Standard Library
 front page
In-Reply-To: <1425884195.77.0.695422727516.issue23617@psf.upfronthosting.co.za>
Message-ID: <20150309085608.1369.59863@psf.io>


Roundup Robot added the comment:

New changeset 17253605eca4 by Ned Deily in branch '2.7':
Issue #23617: Correct plurals typo noted by Kentrell Johnson.
https://hg.python.org/cpython/rev/17253605eca4

New changeset e623283e4dd6 by Ned Deily in branch '3.4':
Issue #23617: Correct plurals typo noted by Kentrell Johnson.
https://hg.python.org/cpython/rev/e623283e4dd6

New changeset 82df13f0ea9b by Ned Deily in branch 'default':
Issue #23617: Correct plurals typo noted by Kentrell Johnson.
https://hg.python.org/cpython/rev/82df13f0ea9b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23617>
_______________________________________

From report at bugs.python.org  Mon Mar  9 09:57:23 2015
From: report at bugs.python.org (Ned Deily)
Date: Mon, 09 Mar 2015 08:57:23 +0000
Subject: [issue23617] Incorrect plural "includes" on Python Standard Library
 front page
In-Reply-To: <1425884195.77.0.695422727516.issue23617@psf.upfronthosting.co.za>
Message-ID: <1425891443.04.0.242801660326.issue23617@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report!

----------
nosy: +ned.deily
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type: enhancement -> 
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23617>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:00:29 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 09 Mar 2015 09:00:29 +0000
Subject: [issue19909] Best practice docs for new SSL features
In-Reply-To: <1386335628.48.0.996074662164.issue19909@psf.upfronthosting.co.za>
Message-ID: <1425891629.61.0.931780669944.issue19909@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

check_hostname and create_default_context have been documented and there are a number of references to both of them so I'm assuming that this can be closed.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19909>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:08:33 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Mar 2015 09:08:33 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module
Message-ID: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The PEP 475 has been accepted and is partialy implemented. The socket module is not fully patched to handle EINTR. For example, socket.socket.connect() doesn't handle EINTR yet.

Attached patch fixes socket.connect() to handle EINTR. It should fix issue #11266 and #20611 in Python 3.5 (Python 2.7 and 3.4 will need to be patched to handle explicitly InterruptedError/OSError(EINTR) in Python).

By the way, some socket functions handle EINTR but don't recompute the timeout yet. _PyTime_monotonic() should be used.

----------
components: Extension Modules
files: connect_eintr.patch
keywords: patch
messages: 237609
nosy: haypo, neologix, serhiy.storchaka
priority: normal
severity: normal
status: open
title: PEP 475: handle EINTR in the socket module
versions: Python 3.5
Added file: http://bugs.python.org/file38402/connect_eintr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:10:48 2015
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 09 Mar 2015 09:10:48 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM12ks5aTQ-N-rhgEvdif_PNS+XNE6BrW_bQLGs8XgOXvQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

If EINTR is received during connect, the socket is unusable, that's why i
didn't implement it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:11:53 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Mar 2015 09:11:53 +0000
Subject: [issue23285] PEP 475 - EINTR handling
In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za>
Message-ID: <1425892313.71.0.247079152245.issue23285@psf.upfronthosting.co.za>


STINNER Victor added the comment:

test_setitimer.patch: hack unittest.TestCase.run() to inject signals every 1 ms, send the first signal in 100 ms.

This patch helped me to find that socket.connect() doesn't handle EINTR yet: see issue #23618 "PEP 475: handle EINTR in the socket module".

----------
Added file: http://bugs.python.org/file38403/setitimer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23285>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:15:17 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Mar 2015 09:15:17 +0000
Subject: [issue23285] PEP 475 - EINTR handling
In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za>
Message-ID: <1425892517.0.0.906471217776.issue23285@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

For the record, it seems test_eintr sometimes left zombie processes in my machine where I run reference leak tests every night. I didn't investigate and just disabled the tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23285>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:15:55 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Mar 2015 09:15:55 +0000
Subject: [issue23285] PEP 475 - EINTR handling
In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za>
Message-ID: <1425892555.52.0.260688053395.issue23285@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

(I'll add that that machine is hosted on an OpenVZ-based VPS, so perhaps there are issues with the old patched kernel and whatnot?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23285>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:17:23 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Mar 2015 09:17:23 +0000
Subject: [issue19909] Best practice docs for new SSL features
In-Reply-To: <1386335628.48.0.996074662164.issue19909@psf.upfronthosting.co.za>
Message-ID: <1425892643.1.0.771197741368.issue19909@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think so as well, but I'll let Christian decide.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19909>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:18:34 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Mar 2015 09:18:34 +0000
Subject: [issue23309] Hang on interpreter shutdown if daemon thread prints to
 stdout
In-Reply-To: <1422107560.4.0.0145420431804.issue23309@psf.upfronthosting.co.za>
Message-ID: <1425892714.59.0.779172011921.issue23309@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thank you for the feedback. Yes, I now also think the fatal error is the preferrable way. I'll see if I can add a reliable test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23309>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:20:02 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Mar 2015 09:20:02 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <1425892802.16.0.262196026845.issue23618@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> If EINTR is received during connect, the socket is unusable,
> that's why i didn't implement it.

Can you elaborate?

socket.connect() should be modified according to the PEP 475:
https://www.python.org/dev/peps/pep-0475/#modified-functions

What do you mean by "unusable"? Is it possible to retry connect()? Is it safe to call getsockopt(fd, SOL_SOCKET, SO_ERROR) until it returns EISCONN?

For high-level functions for socket.create_connection(), how should we handle InterruptedError?

See also this change in asyncio to handle InterruptedError in asyncio:
https://hg.python.org/cpython/rev/ad67f66a5f3c
(I wrote it and I didn't test my change, I didn't know how to test it.)
Tulip issue: https://code.google.com/p/tulip/issues/detail?id=205

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:20:55 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Mar 2015 09:20:55 +0000
Subject: [issue20602] sys.flags and sys.float_info disappear at shutdown
In-Reply-To: <1392146521.44.0.544055558433.issue20602@psf.upfronthosting.co.za>
Message-ID: <1425892855.36.0.967024777296.issue20602@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The behaviour is explained in the subject line and in the linked changeset: for some reason sys.flags and sys.float_info are explicitly wiped during shutdown. But those are simple immutable objects, there is no reason to wipe them.

The expected behaviour is, of course, that those objects keep their proper value during shutdown (e.g. when looked up from destructors).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20602>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:23:28 2015
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 09 Mar 2015 09:23:28 +0000
Subject: [issue23415] add-to-pydotorg does not support .exe installers for
 Windows
In-Reply-To: <1423433584.82.0.0803149544554.issue23415@psf.upfronthosting.co.za>
Message-ID: <1425893007.99.0.425570251993.issue23415@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Using it with 3.5.0a2, it still printed the "could not be processed" error message, but there's a new wrinkle: the one executable it processed, it added incorrectly.  The "-amd64-webinstall" exe was identified as "Windows x86 executable installer".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23415>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:29:31 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Mar 2015 09:29:31 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <1425893371.11.0.888938023136.issue23618@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

About EINTR and connect(), I've found the following insightful page:
http://www.madore.org/~david/computers/connect-intr.html

Official POSIX wording is this:

"""If connect() is interrupted by a signal that is caught while blocked waiting to establish a connection, connect() shall fail and set errno to [EINTR], but the connection request shall not be aborted, and the connection shall be established asynchronously."""

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:31:24 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Mar 2015 09:31:24 +0000
Subject: [issue20602] sys.flags and sys.float_info disappear at shutdown
In-Reply-To: <1392146521.44.0.544055558433.issue20602@psf.upfronthosting.co.za>
Message-ID: <1425893484.33.0.830211102111.issue20602@psf.upfronthosting.co.za>


STINNER Victor added the comment:

sys_at_exit.py: script to reproduce the issue.

The changeset 9639a73afa47 explicitly added sys.flags and sys.float_info to sys_deletes, list of symbols that must be cleared at exit.

So if I understand correctly the issue, the question is why the change was made. Antoine wants to keep these symbols alive during Python shutdown.

----------
Added file: http://bugs.python.org/file38404/sys_at_exit.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20602>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:32:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Mar 2015 09:32:05 +0000
Subject: [issue20602] sys.flags and sys.float_info disappear at shutdown
In-Reply-To: <1392146521.44.0.544055558433.issue20602@psf.upfronthosting.co.za>
Message-ID: <1425893525.38.0.337785540884.issue20602@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Antoine: Can you maybe propose a patch to fix this issue?

I see that you selected Python 3.4 & 3.5. Why Python 3.4 and not 2.7? (Maybe fixing Python 3.5 is enough?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20602>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:32:45 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 09 Mar 2015 09:32:45 +0000
Subject: [issue20602] sys.flags and sys.float_info disappear at shutdown
In-Reply-To: <1392146521.44.0.544055558433.issue20602@psf.upfronthosting.co.za>
Message-ID: <1425893565.09.0.00482604636521.issue20602@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I really don't care about 2.7 for minor fixes is the reason why :-)
(also, I don't know if the bug exists there in the first place)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20602>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:44:53 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 09 Mar 2015 09:44:53 +0000
Subject: [issue19547] HTTPS proxy support missing without warning
In-Reply-To: <1384119115.17.0.177090288449.issue19547@psf.upfronthosting.co.za>
Message-ID: <1425894293.07.0.445911556348.issue19547@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Should this be classifed as a security issue?

----------
nosy: +BreamoreBoy
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19547>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:52:18 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Mar 2015 09:52:18 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <1425894738.58.0.738863263547.issue22524@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It looks like test_os now pass on all buildbots, including OpenIndiana. I close the issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:53:33 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Mar 2015 09:53:33 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1425894813.63.0.294028321934.issue23605@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I reviewed your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:53:59 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 09 Mar 2015 09:53:59 +0000
Subject: [issue20454] platform.linux_distribution() returns empty value on
 Archlinux and python 2.7
In-Reply-To: <1391166165.52.0.4413803514.issue20454@psf.upfronthosting.co.za>
Message-ID: <1425894839.22.0.721904523467.issue20454@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Can Archlinux be added to _supported_dists as requested in msg209764, I've no understanding of the criteria involved here?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20454>
_______________________________________

From report at bugs.python.org  Mon Mar  9 10:57:03 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Mar 2015 09:57:03 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1425894738.58.0.738863263547.issue22524@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ4EmFzQ6i7xadn-yAV67J50vN0G-FTWdA-EsXj0eg-GQ@mail.gmail.com>


STINNER Victor added the comment:

FYI os.scandir() is part of Python 3.5 alpha 2 which is now available
(including installers for Windows):
https://www.python.org/downloads/release/python-350a2/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Mon Mar  9 11:14:02 2015
From: report at bugs.python.org (Tim Golden)
Date: Mon, 09 Mar 2015 10:14:02 +0000
Subject: [issue23604] Python 3.4 and 2.7 installation no Script folder and no
 pip installed
In-Reply-To: <1425761313.01.0.208884407276.issue23604@psf.upfronthosting.co.za>
Message-ID: <1425896042.57.0.63773890513.issue23604@psf.upfronthosting.co.za>


Tim Golden added the comment:

This is a duplicate of issue22028. 

Daiyue Weng: to move forward, can you apply the fix referred to in this post:

https://mail.python.org/pipermail/python-list/2015-January/696688.html

(ie the "removing corrupted keys" section from http://www.swarley.me.uk/blog/2014/04/23/python-pip-and-windows-registry-corruption/).

Steve: if you can, please commit your change from issue22028; I just don't have the time at the moment to run up a clone and test it, but it looks safe to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23604>
_______________________________________

From report at bugs.python.org  Mon Mar  9 11:15:59 2015
From: report at bugs.python.org (Tim Golden)
Date: Mon, 09 Mar 2015 10:15:59 +0000
Subject: [issue22028] Python 3.4.1 Installer ended prematurely (Windows msi)
In-Reply-To: <1405994666.12.0.143457311308.issue22028@psf.upfronthosting.co.za>
Message-ID: <1425896159.37.0.716600701335.issue22028@psf.upfronthosting.co.za>


Tim Golden added the comment:

This has come up again in issue23604. Steve, please apply your patch. I think it should go against 2.7, 3.4 & 3.5 especially since all those versions now ship with ensurepip.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22028>
_______________________________________

From report at bugs.python.org  Mon Mar  9 11:23:37 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 09 Mar 2015 10:23:37 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails
Message-ID: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>


New submission from Paul Moore:

I just tried to install the 64-bit "full installer" version, for
all users with the default options. This is on a PC that hasn't had
3.5 installed before, and doesn't have Visual Studio 2015 installed.
When it got to the step "precompiling standard library" I got an error window pop up saying "python.exe - system error. The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer. Try reinstalling the program to fix this problem." All there was was an "OK" button. Pressing that told me "Setup was successful" but then "py -3.5 -V" gives me nothing (no error, no version, just returns me to the command prompt). Same result if I do "& 'C:\Program Files\Python 3.5\python.exe' -V".

Python 3.5.0a2 (64-bit) is showing in my "Add/Remove Programs".

This is Windows 7, 64-bit.

----------
assignee: steve.dower
components: Installation, Windows
messages: 237630
nosy: pmoore, steve.dower, tim.golden, zach.ware
priority: critical
severity: normal
status: open
title: Python 3.5.0a2 installer fails
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 11:25:28 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 09 Mar 2015 10:25:28 +0000
Subject: [issue23604] Python 3.4 and 2.7 installation no Script folder and no
 pip installed
In-Reply-To: <1425761313.01.0.208884407276.issue23604@psf.upfronthosting.co.za>
Message-ID: <1425896728.01.0.673096222984.issue23604@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23604>
_______________________________________

From report at bugs.python.org  Mon Mar  9 11:32:19 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Mar 2015 10:32:19 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425897139.84.0.66585403419.issue23619@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"""
Two important notes for Windows users about Python 3.5.0a2:

* If you have previously installed Python 3.5.0a1, you must manually uninstall it before installing Python 3.5.0a2 (issue23612).
* If installing Python 3.5.0a2 as a non-privileged user, you may need to escalate to administrator privileges to install an update to your C runtime libraries.
"""

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 11:35:47 2015
From: report at bugs.python.org (David Vieira-Kurz)
Date: Mon, 09 Mar 2015 10:35:47 +0000
Subject: [issue23620] cross-type comparison is different in python minor
 versions
Message-ID: <1425897347.3.0.6338143252.issue23620@psf.upfronthosting.co.za>


New submission from David Vieira-Kurz:

Python internal compare function does not verify if a comparison of two objects is done by using object of the same type.

In this case python does not know how to compare DECIMAL and FLOATS and returns a FALSE instead of returning an Error.

Python should have strict rules to only allow comparison between objects is aware of but depending on the version of Python we have different behaviors:

# Output:
# Python 2.6.5 32bit -- WRONG: FLOAT seems comparable with DECIMAL (WRONG)
# Python 2.7.2 32bit -- WRONG: FLOAT seems comparable with DECIMAL (WRONG)
# Python 3.1.2 32bit -- CORRECT: FLOAT is NOT comparable with DECIMAL (CORRECT)
# Python 3.4.0 ([GCC 4.8.2] on linux) 32bit -- WRONG: FLOAT seems comparable with DECIMAL (WRONG)

A proof of concept code-snippet is attached.

----------
components: Interpreter Core
files: python-float-decimal-comparison.txt
messages: 237632
nosy: secalert
priority: normal
severity: normal
status: open
title: cross-type comparison is different in python minor versions
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file38405/python-float-decimal-comparison.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23620>
_______________________________________

From report at bugs.python.org  Mon Mar  9 11:43:16 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 09 Mar 2015 10:43:16 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425897796.4.0.270068178012.issue23619@psf.upfronthosting.co.za>


Paul Moore added the comment:

In this case as I said, no previous 3.50a1 installed. and I was doing an "all users" install (which prompted me for elevation, and I said OK)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 11:52:07 2015
From: report at bugs.python.org (Michael Clerx)
Date: Mon, 09 Mar 2015 10:52:07 +0000
Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++
 Compiler for Python
In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za>
Message-ID: <1425898327.81.0.229260981929.issue23246@psf.upfronthosting.co.za>


Michael Clerx added the comment:

Is there anyway to fix this without using setuptools? I'm using distutils to compile on the fly which has worked brilliantly for the last few years, not sure I want to destabilize everything by switching to setuptools.

----------
nosy: +Michael Clerx

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23246>
_______________________________________

From report at bugs.python.org  Mon Mar  9 12:00:43 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 09 Mar 2015 11:00:43 +0000
Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++
 Compiler for Python
In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za>
Message-ID: <1425898843.63.0.876312390341.issue23246@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Michael my very old work around here http://www.mail-archive.com/python-win32 at python.org/msg06755.html may help.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23246>
_______________________________________

From report at bugs.python.org  Mon Mar  9 12:04:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Mar 2015 11:04:05 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1425899045.25.0.340573753993.issue23605@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Note: glob.glob() might be faster with os.scandir() on very large directories. But on my benchmarks, listdir() was always faster than scandir() when only the name of directory entries i used. Maybe we need an option glob.glob(pattern, scandir=True) :-p

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Mon Mar  9 12:09:32 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Mar 2015 11:09:32 +0000
Subject: [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425899372.9.0.98559291605.issue23613@psf.upfronthosting.co.za>


R. David Murray added the comment:

Martin's solution is similar to the one I use except that I made an alias for it and I also exclude topics.py.  Which is a tracked file.  It seems that what one wants to ignore is a bit of a personal decision, and so it is probably best left up to the individual to craft a solution (even though I also find it annoying :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23613>
_______________________________________

From report at bugs.python.org  Mon Mar  9 12:47:38 2015
From: report at bugs.python.org (Daiyue Weng)
Date: Mon, 09 Mar 2015 11:47:38 +0000
Subject: [issue23604] Python 3.4 and 2.7 installation no Script folder and no
 pip installed
In-Reply-To: <1425761313.01.0.208884407276.issue23604@psf.upfronthosting.co.za>
Message-ID: <1425901658.11.0.587240088254.issue23604@psf.upfronthosting.co.za>


Daiyue Weng added the comment:

The fix that referred to another thread solved my issue completely.

thanks

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23604>
_______________________________________

From report at bugs.python.org  Mon Mar  9 13:05:38 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Mon, 09 Mar 2015 12:05:38 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425902738.11.0.486189627334.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

Ryan,
What version of Android and KBOX are you using? Are you cross-compiling?
If not could you post the output of printenv from within KBOX here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Mon Mar  9 13:20:12 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 09 Mar 2015 12:20:12 +0000
Subject: [issue23621] Uninstalling Python 3.5 removes a "py.exe" that was
 installed with Python 3.4
Message-ID: <1425903612.32.0.843947786812.issue23621@psf.upfronthosting.co.za>


New submission from Paul Moore:

When I installed Python 3.4, I included the py.exe launcher. I have just installed Python 3.5a0, then uninstalled it again, and the py.exe launcher has gone.

Either the 3.5 installer should notice that py.exe is already present and remember *not* to uninstall it, or it should warn the user when installing that continuing will take ownership of the launcher from a previous installation.

(I understand why having the same file owned by 2 installers causes problems, and that there's no easy fix, but the current behaviour is not at all friendly - I now have to reinstall Python 3.4 to fix it, or at least re-download the installer and try a repair, which might work I guess).

----------
assignee: steve.dower
components: Installation, Windows
messages: 237640
nosy: pmoore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Uninstalling Python 3.5 removes a "py.exe" that was installed with Python 3.4
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23621>
_______________________________________

From report at bugs.python.org  Mon Mar  9 13:25:08 2015
From: report at bugs.python.org (Ben Hoyt)
Date: Mon, 09 Mar 2015 12:25:08 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425903908.42.0.249747847559.issue23619@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

Same exact issue here. I didn't have a Python 3.5 alpha 1 previously installed, and I tried running the installer normally and also (after uninstalling) with right-click, "Run as administrator".

Both do the same thing for me: pop up a dialog box at the end of installation that says "The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer..."

I also get the same dialog box when I run "C:\Program Files\Python 3.5\python.exe"

----------
nosy: +benhoyt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 14:07:14 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 13:07:14 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425906434.81.0.598407438548.issue23619@psf.upfronthosting.co.za>


Steve Dower added the comment:

If you look in your AppData\Local\Temp directory then you should find a whole pile of log files. Zipping those up and posting them here or emailing them to me would be great.

It sounds like the CRT update didn't install, since it's supposed to include that file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 14:10:17 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 13:10:17 +0000
Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++
 Compiler for Python
In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za>
Message-ID: <1425906617.32.0.0680538416674.issue23246@psf.upfronthosting.co.za>


Steve Dower added the comment:

Setuptools just does a monkey patch of distutils, so importing it is sufficient. Or you can find the patching in the setuptools source and copy it into your setup.py file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23246>
_______________________________________

From report at bugs.python.org  Mon Mar  9 14:14:03 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Mar 2015 13:14:03 +0000
Subject: [issue23620] cross-type comparison is different in python minor
 versions
In-Reply-To: <1425897347.3.0.6338143252.issue23620@psf.upfronthosting.co.za>
Message-ID: <1425906843.7.0.285637374126.issue23620@psf.upfronthosting.co.za>


R. David Murray added the comment:

In Python2, all objects were comparable (except DateTime stuff...and maybe there was one other exception, I forget).  We did indeed decide this was a bug and fixed it in Python3.  Now objects of different types are comparable if only if at least one of them supports being compared with the other.  Python does, however, know how to compare Float and Decimal correctly, since Python 3.2 (see the What's New document for Python 3.2).

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23620>
_______________________________________

From report at bugs.python.org  Mon Mar  9 14:28:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Mar 2015 13:28:27 +0000
Subject: [issue23622] Deprecate unrecognized backslash+letter escapes
Message-ID: <1425907707.07.0.452600036872.issue23622@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Regular expressions use the backslash character for two functions:
1) to indicate special forms;
2) to allow special characters to be used without invoking their special meaning.

If backslash + character is not recognized as special form (1), it interpreted in meaning (2).

Usually new special forms have form backslash + ASCII letter, because unlike to other characters single ASCII letters do not have special meaning in any regular expression engine or programming language. This using the backslash with inner ASCII letter dangerous. Currently it means just this letter literally, but in future it can mean special form. For example \u and \U forms were added in 3.3 and this could break regular expression patters that use \u and \U before.

To avoid possible breaking it makes sense to reject unrecognized backslash + ASCII letter sequences. Proposed patch adds deprecation warnings when unknown escape of ASCII letter is used. The idea was proposed by Matthew Barnett [1].

[1] http://permalink.gmane.org/gmane.comp.python.devel/151657

----------
assignee: serhiy.storchaka
components: Library (Lib), Regular Expressions
files: re_deprecate_escaped_letters.patch
keywords: patch
messages: 237645
nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Deprecate unrecognized backslash+letter escapes
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38406/re_deprecate_escaped_letters.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23622>
_______________________________________

From report at bugs.python.org  Mon Mar  9 14:29:53 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 09 Mar 2015 13:29:53 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425907793.92.0.906794983876.issue23619@psf.upfronthosting.co.za>


Paul Moore added the comment:

Sent via private email as it's a work PC and I didn't check what's logged in there...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 14:36:19 2015
From: report at bugs.python.org (Michael Clerx)
Date: Mon, 09 Mar 2015 13:36:19 +0000
Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++
 Compiler for Python
In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za>
Message-ID: <1425908179.76.0.596262466443.issue23246@psf.upfronthosting.co.za>


Michael Clerx added the comment:

Thanks! However, importing setuptools causes a string of errors about PYTHONPATH and .pth files (even on a linux system)

In addition, a monkeypatched version of find_vcvarsall allowed things to run, but it seems finding plain C libraries with Visual C++ for python is very different from finding libraries in mingw

I think I'll just start telling my windows users to install MinGW instead

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23246>
_______________________________________

From report at bugs.python.org  Mon Mar  9 14:42:57 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 Mar 2015 13:42:57 +0000
Subject: [issue19610] setup.py does not allow a tuple for classifiers
In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za>
Message-ID: <1425908577.39.0.45375703377.issue19610@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I think classifiers and keywords are the only commonly used fields.  This issue could be limited to classifiers, or also include other list fields.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19610>
_______________________________________

From report at bugs.python.org  Mon Mar  9 14:46:46 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Mar 2015 13:46:46 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425908806.7.0.577612257423.issue23619@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Same error on my Windows 7 VM. I have VS 2008 & 2010 installed, but also Python 2.7, 3.3 and 3.4 (all installed twice: 32&64 bits). It's not a fresh Windows :-)

Here is a ZIP of Python 3.5* logs in my Temp directory. I cannot compress the whole directory, it's really huge :-) I have files which are 2 years old in this directory!?

Files:
Python 3.5.0a2 (64-bit)_20150309143635.log
Python 3.5.0a2 (64-bit)_20150309143635_001_...log
...
Python 3.5.0a2 (64-bit)_20150309143635_010_...log

Have fun!

----------
title: Python 3.5.0a2 installer fails -> Python 3.5.0a2 installer fails on Windows
Added file: http://bugs.python.org/file38407/Installer.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 15:14:27 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 09 Mar 2015 14:14:27 +0000
Subject: [issue23623] Python 3.5 docs need to clarify how to set PATH, etc
Message-ID: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>


New submission from Paul Moore:

With Python 3.5 on Windows defaulting (for all users installs) to the read-only "Program Files" directory, and with "Add Python to PATH" having problems adding the per-user "user scripts" directory to PATH, the Python 3.5 documentation needs to explain the recommended practice for running Python 3.5 from the command line on Windows. Issues that should be covered include:

- System installs with need to be run from an elevated prompt, are user installs now the recommended approach? (It's worth noting in that case that user installs re *not* recommended for older versions, as the user Scripts directory wasn't versioned until Python 3.5)
- How to add the correct directories to PATH (including the user scripts directory) - for both CMD and powershell users and in an existing shell as well as a new one (i.e, no "Python command prompt" shortcuts!)
- How to add the correct directories persistently, so they are available to all programs on startup.
- While the "py" launcher solves the problem of running Python, and some modules via -m (such as pip), many packages install console scripts which do not have an equivalent -m invocation, so "use the launcher" is not a complete solution.

The documentation should clarify where (or if) 3rd party documentation needs to comment on Windows path difficulties. For example, the pip documentation has for a long time said that the way to run pip is via the "pip" command, and until Python included the "Add to PATH" option in the installer, we regularly had to deal with user queries because the "pip" command didn't work out of the box - it would be unfortunate if Python 3.5 left 3rd parties back in that situation again.

----------
assignee: docs at python
components: Documentation, Windows
messages: 237650
nosy: docs at python, pmoore, steve.dower, tim.golden, zach.ware
priority: release blocker
severity: normal
status: open
title: Python 3.5 docs need to clarify how to set PATH, etc
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23623>
_______________________________________

From report at bugs.python.org  Mon Mar  9 15:15:57 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 14:15:57 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425910557.86.0.0384257946265.issue23619@psf.upfronthosting.co.za>


Steve Dower added the comment:

I definitely don't want the whole directory, especially from Windows 7 :) (Later versions are better at cleaning up unused files)

I'll take a look once I get to work. Thanks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 15:26:57 2015
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 09 Mar 2015 14:26:57 +0000
Subject: [issue23138] cookiejar parses cookie value as int with empty
 name-value pair and Expires
In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za>
Message-ID: <1425911217.86.0.0806050117068.issue23138@psf.upfronthosting.co.za>


Demian Brecht added the comment:

I agree that the current implementation doesn't conform to standards, but do you think those cases are worth fixing as they can potentially break backwards compatibility? I think that the reported case makes sense to fix as the name/value pair are entirely unexpected. However, the current behaviour is logical for the cases that you've pointed out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23138>
_______________________________________

From report at bugs.python.org  Mon Mar  9 15:40:57 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Mon, 09 Mar 2015 14:40:57 +0000
Subject: [issue21271] reset_mock needs parameters to also reset return_value
 and side_effect
In-Reply-To: <1397681504.34.0.196484984277.issue21271@psf.upfronthosting.co.za>
Message-ID: <1425912057.46.0.619768114683.issue21271@psf.upfronthosting.co.za>


Changes by Claudiu Popa <pcmanticore at gmail.com>:


----------
nosy: +Claudiu.Popa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21271>
_______________________________________

From report at bugs.python.org  Mon Mar  9 15:43:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Mar 2015 14:43:42 +0000
Subject: [issue23138] cookiejar parses cookie value as int with empty
 name-value pair and Expires
In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za>
Message-ID: <1425912222.72.0.846444063156.issue23138@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think that for consistency either parse empty name-value pair as key="", value=None, or ignore all non-conformed cases. For backward compatibility I prefer first way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23138>
_______________________________________

From report at bugs.python.org  Mon Mar  9 15:44:35 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Mon, 09 Mar 2015 14:44:35 +0000
Subject: [issue21478] mock calls don't propagate to parent (autospec)
In-Reply-To: <1399899394.81.0.714942512868.issue21478@psf.upfronthosting.co.za>
Message-ID: <1425912275.15.0.913627856197.issue21478@psf.upfronthosting.co.za>


Changes by Claudiu Popa <pcmanticore at gmail.com>:


----------
nosy: +Claudiu.Popa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21478>
_______________________________________

From report at bugs.python.org  Mon Mar  9 15:45:42 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 Mar 2015 14:45:42 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425912342.08.0.250720167941.issue23496@psf.upfronthosting.co.za>


Stefan Krah added the comment:

> ImportError: cannot import name 'module_from_spec'

The command line uses the system python3, which is "too old"
and does not have 'module_from_spec' yet.

Try running ...

   python3 -S -m sysconfig --generate-posix-vars

... and then continue with `make`.


We should open an issue for that, it's annoying.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Mon Mar  9 15:46:03 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Mon, 09 Mar 2015 14:46:03 +0000
Subject: [issue21385] in debug mode,
 compile(ast) fails with an assertion error if an AST node has no line
 number information
In-Reply-To: <1398762010.89.0.992252148712.issue21385@psf.upfronthosting.co.za>
Message-ID: <1425912363.85.0.137150900226.issue21385@psf.upfronthosting.co.za>


Changes by Claudiu Popa <pcmanticore at gmail.com>:


----------
nosy: +Claudiu.Popa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21385>
_______________________________________

From report at bugs.python.org  Mon Mar  9 15:55:30 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Mon, 09 Mar 2015 14:55:30 +0000
Subject: [issue22189] collections.UserString missing some str methods
In-Reply-To: <1407908952.77.0.872981126645.issue22189@psf.upfronthosting.co.za>
Message-ID: <1425912930.02.0.037704187415.issue22189@psf.upfronthosting.co.za>


Changes by Claudiu Popa <pcmanticore at gmail.com>:


----------
nosy: +Claudiu.Popa
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22189>
_______________________________________

From report at bugs.python.org  Mon Mar  9 15:59:15 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Mon, 09 Mar 2015 14:59:15 +0000
Subject: [issue22964] dbm.open(..., "x")
In-Reply-To: <1417214551.97.0.349316203885.issue22964@psf.upfronthosting.co.za>
Message-ID: <1425913155.09.0.107124790207.issue22964@psf.upfronthosting.co.za>


Changes by Claudiu Popa <pcmanticore at gmail.com>:


----------
nosy: +Claudiu.Popa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22964>
_______________________________________

From report at bugs.python.org  Mon Mar  9 16:01:37 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 09 Mar 2015 15:01:37 +0000
Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++
 Compiler for Python
In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za>
Message-ID: <1425913297.24.0.141844751118.issue23246@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Michael in case you are not aware Python does not support MINGW.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23246>
_______________________________________

From report at bugs.python.org  Mon Mar  9 16:05:38 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Mar 2015 15:05:38 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <1425913538.43.0.813840364662.issue23618@psf.upfronthosting.co.za>


STINNER Victor added the comment:

connect_eintr.py: script calling socket.connect() in a loop and sending SIGARLM signal every millisecond.

----------
Added file: http://bugs.python.org/file38408/connect_eintr.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Mon Mar  9 16:08:37 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Mar 2015 15:08:37 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <1425913717.7.0.899771020619.issue23618@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oops, connect_eintr.py noticed me (thanks to my recent change of the issue #23571 !) that connect_eintr.patch is wrong: socket.connect() returned None with an exception sent, send connect() was interrupted by SIGINT (CTRL+c).

Fixed patch.

----------
Added file: http://bugs.python.org/file38409/connect_eintr-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Mon Mar  9 16:12:36 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Mon, 09 Mar 2015 15:12:36 +0000
Subject: [issue21159] configparser.InterpolationMissingOptionError is not very
 intuitive
In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>
Message-ID: <1425913956.61.0.941738955719.issue21159@psf.upfronthosting.co.za>


Claudiu Popa added the comment:

I find the new error messages clear and straight to the point. It would be nice if this would get into 3.5.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21159>
_______________________________________

From report at bugs.python.org  Mon Mar  9 16:14:24 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 15:14:24 +0000
Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++
 Compiler for Python
In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za>
Message-ID: <1425914064.26.0.33338065681.issue23246@psf.upfronthosting.co.za>


Steve Dower added the comment:

Python does not support being built with MinGW, but we have "support" to build extensions with MinGW. It isn't great support, and we're open to patches/contributions (none of our core Windows devs use MinGW AFAIK).

And yes, VC is different from MinGW because MinGW is trying to copy a different operating system. Where possible, Python generally tries to follow the conventions of the underlying operating system, which is why we build with VC and not gcc on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23246>
_______________________________________

From report at bugs.python.org  Mon Mar  9 16:15:28 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 15:15:28 +0000
Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++
 Compiler for Python
In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za>
Message-ID: <1425914128.61.0.846369116722.issue23246@psf.upfronthosting.co.za>


Steve Dower added the comment:

You could also distribute wheels for your Windows users, which they will appreciate much more than being told to install MinGW. (If you do go the latter route, WinPython is a pretty good distribution that sets that stuff up fairly transparently.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23246>
_______________________________________

From report at bugs.python.org  Mon Mar  9 16:15:34 2015
From: report at bugs.python.org (Michael Clerx)
Date: Mon, 09 Mar 2015 15:15:34 +0000
Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++
 Compiler for Python
In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za>
Message-ID: <1425914134.56.0.456682240162.issue23246@psf.upfronthosting.co.za>


Michael Clerx added the comment:

@Mark I don't quite understand what you're saying. Distutils supports it, provided you add a line to distutils.cfg. I've been using the PythonXY versions of Python with MinGW (everything before 2.7.9.0) to happily compile for nearly 4 years now.

Regarding your earlier suggestion about distutils and Visual C++ for Python, I hacked something together to do it dynamically in the script using distutils. Very ugly :-)

import platform
if platform.system() == 'Windows':
    vcpath = os.environ['ProgramFiles']
    vcpath = os.path.join(vcpath, 'Common Files', 'Microsoft',
        'Visual C++ for Python', '9.0', 'vcvarsall.bat')
    if os.path.isfile(vcpath):
        import distutils.msvc9compiler
        old_find = distutils.msvc9compiler.find_vcvarsall
        def new_find(version):
            path = old_find(version)
            if path is None:
                return vcpath
        distutils.msvc9compiler.find_vcvarsall = new_find

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23246>
_______________________________________

From report at bugs.python.org  Mon Mar  9 16:18:10 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 15:18:10 +0000
Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++
 Compiler for Python
In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za>
Message-ID: <1425914290.55.0.369791225238.issue23246@psf.upfronthosting.co.za>


Steve Dower added the comment:

> Very ugly :-)

And also incorrect on 64-bit interpreters (but not 32-bit interpreters on 64-bit machines, oddly enough), and machines where the user has installed the compiler just for themselves.

I'd seriously suggest copying the monkey patch from https://bitbucket.org/pypa/setuptools/src/18eceee63709bc70c06b51a609f3dbd2eab07ef4/setuptools/msvc9_support.py?at=default

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23246>
_______________________________________

From report at bugs.python.org  Mon Mar  9 16:21:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Mar 2015 15:21:30 +0000
Subject: [issue22189] collections.UserString missing some str methods
In-Reply-To: <1407908952.77.0.872981126645.issue22189@psf.upfronthosting.co.za>
Message-ID: <1425914490.92.0.265435438507.issue22189@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22189>
_______________________________________

From report at bugs.python.org  Mon Mar  9 16:37:51 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Mon, 09 Mar 2015 15:37:51 +0000
Subject: [issue21574] Port image types detections from PIL to the imghdr module
In-Reply-To: <1401010621.11.0.919611847501.issue21574@psf.upfronthosting.co.za>
Message-ID: <1425915471.57.0.112135070093.issue21574@psf.upfronthosting.co.za>


Claudiu Popa added the comment:

In general, the patch looks good, I left a couple of comments on Rietvld. It should be applied to 3.5 only. Also, there are some image test files which aren't included in this patch, could you update it to include them? Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21574>
_______________________________________

From report at bugs.python.org  Mon Mar  9 16:38:59 2015
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 09 Mar 2015 15:38:59 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1425915539.63.0.094696585344.issue2211@psf.upfronthosting.co.za>


Demian Brecht added the comment:

New patch addresses most review comments. Thanks for the review Serhiy.

----------
Added file: http://bugs.python.org/file38410/issue2211_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Mon Mar  9 16:40:12 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 09 Mar 2015 15:40:12 +0000
Subject: [issue12916] Add inspect.splitdoc
In-Reply-To: <1315326747.38.0.43030903994.issue12916@psf.upfronthosting.co.za>
Message-ID: <1425915612.84.0.671660275548.issue12916@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Berker, I agree. Let's wait till 3.6.

I still don't like having this function in the inspect module, and I still don't understand why it should be there.

----------
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12916>
_______________________________________

From report at bugs.python.org  Mon Mar  9 16:43:24 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Mar 2015 15:43:24 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <1425915804.92.0.124670076416.issue23618@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> http://www.madore.org/~david/computers/connect-intr.html

This article contains a program connect_test.c to test how connect() behaves on EINTR. Since it's in the public domain, I attached a copy.

The program contains the comment: "All systems function as expected when TEST_TWO is set."

If TEST_TWO is defined, poll() is used to wait until the socket is writable, and then getsockopt(SO_ERROR) is used to check if the error is now zero, when connect() fails with EINTR.

----------
Added file: http://bugs.python.org/file38411/connect_test.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Mon Mar  9 16:52:13 2015
From: report at bugs.python.org (Michael Clerx)
Date: Mon, 09 Mar 2015 15:52:13 +0000
Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++
 Compiler for Python
In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za>
Message-ID: <1425916333.02.0.130664159777.issue23246@psf.upfronthosting.co.za>


Michael Clerx added the comment:

Thanks!

If I do copy this patch, do I need to add anything to my license text other than a reference in the file itself?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23246>
_______________________________________

From report at bugs.python.org  Mon Mar  9 16:54:58 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 09 Mar 2015 15:54:58 +0000
Subject: [issue12916] Add inspect.splitdoc
In-Reply-To: <1425915612.84.0.671660275548.issue12916@psf.upfronthosting.co.za>
Message-ID: <938296BE-2135-4D8F-A62B-2FC2C5F63B1D@wirtel.be>


St?phane Wirtel added the comment:

Ok, so in this case, you are right to move this issue to the Python 3.6 
version, and it's too late for 3.5

Thank you for your help and feedbacks.

Stephane

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12916>
_______________________________________

From report at bugs.python.org  Mon Mar  9 16:59:27 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 09 Mar 2015 15:59:27 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <1425916767.86.0.364350065831.issue23618@psf.upfronthosting.co.za>


STINNER Victor added the comment:

connect_eintr-3.patch: Different patch, don't retry connect() if it returns EINTR, but poll using poll/select. The patch changes also the asyncio module.

----------
Added file: http://bugs.python.org/file38412/connect_eintr-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Mon Mar  9 17:02:08 2015
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 09 Mar 2015 16:02:08 +0000
Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes
 returned from ast.parse
In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za>
Message-ID: <1425916928.15.0.91519494717.issue21295@psf.upfronthosting.co.za>


Mark Shannon added the comment:

The column offset has always been the offset of the start of the expression. Therefore the expression `x.y` should have the same offset as the sub-expresssion `x`.
Likewise for calls, `f(args)` should have the same offset as the `f` sub expression.

Our static analysis tool is a real-world use case:
http://semmle.com/2014/06/semmle-analysis-now-includes-python/

Presumably the submitter of this issue also had a real would use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21295>
_______________________________________

From report at bugs.python.org  Mon Mar  9 17:09:33 2015
From: report at bugs.python.org (Aivar Annamaa)
Date: Mon, 09 Mar 2015 16:09:33 +0000
Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes
 returned from ast.parse
In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za>
Message-ID: <1425917373.29.0.151349975648.issue21295@psf.upfronthosting.co.za>


Aivar Annamaa added the comment:

Yes, I also need col_offset to work as advertised because of a real world use case: Thonny (http://thonny.cs.ut.ee/) is a visual Python debugger which highlights the (sub)expression about to be evaluated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21295>
_______________________________________

From report at bugs.python.org  Mon Mar  9 17:15:55 2015
From: report at bugs.python.org (Sven Brauch)
Date: Mon, 09 Mar 2015 16:15:55 +0000
Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes
 returned from ast.parse
In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za>
Message-ID: <1425917755.52.0.128013495258.issue21295@psf.upfronthosting.co.za>


Sven Brauch added the comment:

But if you need the start of the full expression, can't you just go up in the "parent" chain until the parent is not an expression any more?

Could additional API be introduced which provides the value I am looking for as well as the one you need?

I was not on the nosy list by the way, I just put myself there after I commented. And that was after 3.4.3, after I noticed my software was suddenly broken by a patch release of python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21295>
_______________________________________

From report at bugs.python.org  Mon Mar  9 17:19:18 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 16:19:18 +0000
Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++
 Compiler for Python
In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za>
Message-ID: <1425917958.32.0.988198723781.issue23246@psf.upfronthosting.co.za>


Steve Dower added the comment:

Hard to be sure. It was my contribution originally, and I'm okay to remain unattributed, but I've nosied Jason so he can answer authoritatively (especially since he rewrote most of my original contribution to make it work better :) ).

----------
nosy: +jason.coombs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23246>
_______________________________________

From report at bugs.python.org  Mon Mar  9 17:36:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Mar 2015 16:36:36 +0000
Subject: [issue12916] Add inspect.splitdoc
In-Reply-To: <938296BE-2135-4D8F-A62B-2FC2C5F63B1D@wirtel.be>
Message-ID: <237654755.jWpFgrHCNS@raxxla>


Serhiy Storchaka added the comment:

It's not too late for 3.5. Just there is no consensus.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12916>
_______________________________________

From report at bugs.python.org  Mon Mar  9 17:41:34 2015
From: report at bugs.python.org (David Linke)
Date: Mon, 09 Mar 2015 16:41:34 +0000
Subject: [issue23623] Python 3.5 docs need to clarify how to set PATH, etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1425919294.54.0.56915922677.issue23623@psf.upfronthosting.co.za>


Changes by David Linke <dr.david.linke at gmail.com>:


----------
nosy: +dalito

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23623>
_______________________________________

From report at bugs.python.org  Mon Mar  9 17:44:40 2015
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 09 Mar 2015 16:44:40 +0000
Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes
 returned from ast.parse
In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za>
Message-ID: <1425919479.99.0.768840074874.issue21295@psf.upfronthosting.co.za>


Mark Shannon added the comment:

How do I get the start of `(x+y).bit_length()` in 
`total += (x+y).bit_length()`?
With your change, I can't get it from `x`, `x+y`, or from the whole statement.

The primary purpose of the locations are for tracebacks, not for static tools.
Also, most tools need to support earlier versions of Python and consistency between versions is the most important thing.

A third-party parser that supported full, accurate locations would be great, but I don't think the builtin parser is the place for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21295>
_______________________________________

From report at bugs.python.org  Mon Mar  9 17:49:53 2015
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 09 Mar 2015 16:49:53 +0000
Subject: [issue23623] Python 3.5 docs need to clarify how to set PATH, etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1425919792.99.0.633328374334.issue23623@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23623>
_______________________________________

From report at bugs.python.org  Mon Mar  9 18:06:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Mar 2015 17:06:18 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <20150309170615.16657.84562@psf.io>


Roundup Robot added the comment:

New changeset 0469af231d22 by Steve Dower in branch 'default':
Issue #23619: Ensure C variable is initialized before using it.
https://hg.python.org/cpython/rev/0469af231d22

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 18:07:09 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 17:07:09 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425920829.64.0.765792745013.issue23619@psf.upfronthosting.co.za>


Steve Dower added the comment:

Well that was embarrassing, but it's fixed now :)

Larry, would you like me to rebuild the installer with the fix in it?

----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 18:13:48 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 17:13:48 +0000
Subject: [issue23623] Python 3.5 docs need to clarify how to set PATH, etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1425921228.8.0.51564466591.issue23623@psf.upfronthosting.co.za>


Steve Dower added the comment:

FYI, the docs in the Python 3.5.0a2 CHM are newer than what's on docs.p.o, specifically the "Using Python on Windows" section. (Apparently I need to do something other than commit changes to get the website updated?)

https://hg.python.org/cpython/file/tip/Doc/using/windows.rst

The section on setting environment variables has been updated since 3.4, but it could be extended further.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23623>
_______________________________________

From report at bugs.python.org  Mon Mar  9 18:24:39 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 09 Mar 2015 17:24:39 +0000
Subject: [issue23623] Python 3.5 docs need to clarify how to set PATH, etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1425921879.12.0.669562166538.issue23623@psf.upfronthosting.co.za>


Paul Moore added the comment:

At a minimum, the example should show adding setting the 2 script directories to PATH, and not just sys.prefix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23623>
_______________________________________

From report at bugs.python.org  Mon Mar  9 18:28:36 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Mon, 09 Mar 2015 17:28:36 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425922116.34.0.06006995552.issue23496@psf.upfronthosting.co.za>


Ryan Gonzalez added the comment:

Python really needs some way of separating the host C compiler and the target C compiler.

I'm giving up cross-compiling from my computer and am going to install KBOX on an Android virtual device. It worked for Cyd, it'll work for me. Beats compiling two separate versions of Python (one just to get host version of pgen and _freeze_importlib), passing 20+ arguments to configure segregated in flags and environment variables, etc.

Please bear with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Mon Mar  9 18:38:05 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 Mar 2015 17:38:05 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425922685.68.0.0955055279556.issue23496@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Cross compiling worked for a while in 3.4. It broke again
because we don't have a buildbot for that.

You should not need 20 args for ./configure. At least on
Ubuntu the script from #5404 generally works, but indeed
pgen, importlib and the above issue are currently broken
(again).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Mon Mar  9 18:42:30 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Mon, 09 Mar 2015 17:42:30 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425922950.79.0.322131813008.issue23496@psf.upfronthosting.co.za>


Ryan Gonzalez added the comment:

This is what I'm using:

PYTHON_FOR_BUILD=`realpath ../cpython/python` CC=arm-linux-androideabi-clang CXX=arm-linux-androideabi-clang++ ./configure --host=arm-linux-androideabi --build=x86_64 --disable-ipv6 ac_cv_file__dev_ptmx=no ac_cv_file__dev_ptc=no ac_cv_have_long_long_format=yes

I know I could use config.site, but I just popped all this in a shell script.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Mon Mar  9 18:52:19 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 Mar 2015 17:52:19 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425923539.95.0.390026957502.issue23496@psf.upfronthosting.co.za>


Stefan Krah added the comment:

On Ubuntu, when I uploaded the script to #5404, I only needed:

  ./configure --prefix=/tmp/arm-install --without-ensurepip --host=arm-linux-gnueabi --build=x86_64 --disable-ipv6


(And config.site of course.)


We just have to fix the pgen etc. issues and someone has to provide
a buildbot, otherwise it's guaranteed to break again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Mon Mar  9 18:56:05 2015
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 09 Mar 2015 17:56:05 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425923765.95.0.744482188494.issue23496@psf.upfronthosting.co.za>


Ethan Furman added the comment:

This would be a build-bot for cross-compiling?  As opposed to an android build-bot (which we'll also need) ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Mon Mar  9 19:07:37 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 09 Mar 2015 18:07:37 +0000
Subject: [issue11726] linecache becomes specific to Python scripts in Python 3
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <1425924457.73.0.45422142325.issue11726@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Someone on reddit ran into this, expecting that linecache can be used for an arbitrary text file:
http://www.reddit.com/r/Python/comments/2yetxc/utf8_encoding_problems/

I was quite surprised that the docs say "allows one to get any line from any file." I've always understood that linecache is specifically for Python files, and the use of tokenize.open() means that it will only work for files that are UTF-8 or have the #coding: magic comment in the first two lines.

I think the docs should at least mention this; I'm happy to work on a patch for it at some point if people agree.

----------
nosy: +takluyver

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11726>
_______________________________________

From report at bugs.python.org  Mon Mar  9 19:18:09 2015
From: report at bugs.python.org (required field)
Date: Mon, 09 Mar 2015 18:18:09 +0000
Subject: [issue16318] FTP_TLS in ftplib not supporting prot_p storlines in
 FTP7.5
In-Reply-To: <1351120164.32.0.969400884781.issue16318@psf.upfronthosting.co.za>
Message-ID: <1425925089.45.0.126269317184.issue16318@psf.upfronthosting.co.za>


Changes by required field <requiredfield256 at gmail.com>:


----------
nosy: +required field

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16318>
_______________________________________

From report at bugs.python.org  Mon Mar  9 19:20:09 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Mar 2015 18:20:09 +0000
Subject: [issue11726] clarify that linecache only works on files that can be
 decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <1425925209.3.0.605853206467.issue11726@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sure, clarifying the docs seems sensible.  "Any file" is slightly different from the reality.

----------
nosy: +r.david.murray
resolution: rejected -> 
stage:  -> needs patch
status: closed -> open
title: linecache becomes specific to Python scripts in Python 3 -> clarify that linecache only works on files that can be decoded successfully
type:  -> behavior
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11726>
_______________________________________

From report at bugs.python.org  Mon Mar  9 19:29:57 2015
From: report at bugs.python.org (eryksun)
Date: Mon, 09 Mar 2015 18:29:57 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <1425925797.71.0.562278285984.issue23606@psf.upfronthosting.co.za>


eryksun added the comment:

The api-ms-win-crt-* DLLs forward their exports to ucrtbase.dll, which currently uses named exports. When is it planned to remove the named exports?

    >>> crt = CDLL('ucrtbase')
    >>> filesystem = CDLL('api-ms-win-crt-filesystem-l1-1-0')  
    >>> math = CDLL('api-ms-win-crt-math-l1-1-0')

    >>> c_void_p.from_buffer(crt._stat64)
    c_void_p(8791677890384)
    >>> c_void_p.from_buffer(filesystem._stat64)
    c_void_p(8791677890384)

    >>> c_void_p.from_buffer(crt.fabs)          
    c_void_p(8791678417616)
    >>> c_void_p.from_buffer(math.fabs)
    c_void_p(8791678417616)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23606>
_______________________________________

From report at bugs.python.org  Mon Mar  9 19:29:59 2015
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 09 Mar 2015 18:29:59 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1425925799.01.0.965013723183.issue2292@psf.upfronthosting.co.za>


Ethan Furman added the comment:

All tests pass on my ubuntu 13.04 system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Mon Mar  9 19:30:29 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Mar 2015 18:30:29 +0000
Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains
In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za>
Message-ID: <1425925829.85.0.921204924221.issue15582@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15582>
_______________________________________

From report at bugs.python.org  Mon Mar  9 19:39:03 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 18:39:03 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <1425926343.76.0.378808341416.issue23606@psf.upfronthosting.co.za>


Steve Dower added the comment:

AIUI, by the time Windows 10 or Visual Studio 2015 releases (since it's now a Windows component, it's technically on a different schedule, even though the main developer is still working against Visual Studio's schedule) and probably sooner (VS 2015 RC is most likely).

It's always possible that they'll decide not to remove them, but the current plan is that loading ucrtbase.dll directly will not be helpful, since it would prevent Windows from making breaking changes to the API that the api-*.dll files would mask.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23606>
_______________________________________

From report at bugs.python.org  Mon Mar  9 19:45:40 2015
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 09 Mar 2015 18:45:40 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425926740.09.0.88489955454.issue23619@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Yup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 19:56:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Mar 2015 18:56:53 +0000
Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains
In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za>
Message-ID: <1425927413.67.0.927029343722.issue15582@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch adds support only for unbound methods and requires additional parameter for this. It is not what should be done in this issue at all.

I'm interested in this issue so I'll write a patch. It should be easier to write it myself than describe it.

----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15582>
_______________________________________

From report at bugs.python.org  Mon Mar  9 20:01:07 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 19:01:07 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425927667.17.0.586076459218.issue23619@psf.upfronthosting.co.za>


Steve Dower added the comment:

Done, though I may have corrupted alpha 1 in the process :(

New MD5s and sizes:
python-3.5.0a2.exe                  9683ecb837ffa2dd321d564042a90d64    28,762,032
python-3.5.0a2-webinstall.exe       b717713c58d0fcabf69c4fdc67a2e581    885,256
python-3.5.0a2-amd64.exe            5eb089c6c45913480434388341d3ed4a    29,669,240
python-3.5.0a2-amd64-webinstall.exe 93b883552869c3f936cf6799a6212f04    910,840
python350a2.chm                     68007011a878c5cf5f498a3290085066    7,525,910

Any idea how long until the CDN picks up the update?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 20:01:26 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 09 Mar 2015 19:01:26 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425927686.96.0.679881605227.issue23496@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Technically we could use the Android buildbot to test both
(cross-compiling and Android breakage), but it would be nice
to have a separate buildbot that just tests cross-compiling
with an easier target (e.g. arm-linux-gnueabi).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Mon Mar  9 20:06:56 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Mon, 09 Mar 2015 19:06:56 +0000
Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains
In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za>
Message-ID: <1425928016.47.0.4957499449.issue15582@psf.upfronthosting.co.za>


Claudiu Popa added the comment:

> The patch adds support only for unbound methods and requires additional parameter for this.

Just curios, which part works only for unbound methods?

> It is not what should be done in this issue at all.
> It should be easier to write it myself than describe it.

Well, some hints for the right way to do this would have been appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15582>
_______________________________________

From report at bugs.python.org  Mon Mar  9 20:13:58 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 19:13:58 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425928438.35.0.54004694019.issue23619@psf.upfronthosting.co.za>


Steve Dower added the comment:

Scratch that, I screwed up the hg dance (multiple times...). Newer bits coming

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 20:29:54 2015
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 09 Mar 2015 19:29:54 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425929394.96.0.71580919276.issue23619@psf.upfronthosting.co.za>


Larry Hastings added the comment:

> Any idea how long until the CDN picks up the update?

curl -X PURGE https://www.python.org/ftp/python/2.7.5/Python-2.7.5.tar.xz

will explicitly tell the CDN to pick up the new binaries.  Not sure if that works from anywhere or just from dl-files.iad1.psf.io .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 20:30:23 2015
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 09 Mar 2015 19:30:23 +0000
Subject: [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425929423.93.0.741899831975.issue23613@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Most important reason to close this: this is not something to change in Python, but would have to be changed in Sphinx.

----------
resolution:  -> third party
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23613>
_______________________________________

From report at bugs.python.org  Mon Mar  9 20:31:30 2015
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 09 Mar 2015 19:31:30 +0000
Subject: [issue23415] add-to-pydotorg does not support .exe installers for
 Windows
In-Reply-To: <1423433584.82.0.0803149544554.issue23415@psf.upfronthosting.co.za>
Message-ID: <1425929490.31.0.103152283412.issue23415@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Well, it's not a complicated script.  You're welcome to try and debug it, but if the bug is in the depths of new pydotorg, I don't know how easy it is to find.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23415>
_______________________________________

From report at bugs.python.org  Mon Mar  9 20:41:24 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 19:41:24 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425930084.94.0.0419742718259.issue23619@psf.upfronthosting.co.za>


Steve Dower added the comment:

Looks like there'll be some installation errors until the CDN catches up, but the full installer will be fine

MD5s/sizes:

python-3.5.0a2.exe                  807a898a6b61696ab9c4257152a939c5    28,762,312
python-3.5.0a2-webinstall.exe       dc2cebbb402f117f0590c7d11f662129    885,208
python-3.5.0a2-amd64.exe            91771bce1d8993071b5d766920321ca8    29,669,336
python-3.5.0a2-amd64-webinstall.exe 7b057970b302106304e943da2ccc1ead    910,792
python350a2.chm                     68007011a878c5cf5f498a3290085066    7,525,910

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 20:46:18 2015
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 09 Mar 2015 19:46:18 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425930378.56.0.879386881356.issue23619@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Okay, I refreshed the MD5 sums and sizes on the web site, and purged the old files from the CDN.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 21:01:31 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Mar 2015 20:01:31 +0000
Subject: [issue23616] Idle: conflict between loop execution and undo shortcut.
In-Reply-To: <1425881906.7.0.913975027091.issue23616@psf.upfronthosting.co.za>
Message-ID: <1425931291.8.0.113152471616.issue23616@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I believe you are reporting the following behavior, which I believe I have seen before but which seems not to be the subject of a tracker issue.  If I run

import time
for i in range(20):
	print(i)
	time.sleep(.5)

either in Shell at >>> or from the editor, and hold Undo (^Z for me on Windows), output is deleted back to the previous >>>.  When the statements are enter in Shell, that means erasing the visible 'for' statement.  A bit to my surprise, <<Prev>> (alt-P for me) still reloads the 'for' statement.

While this behavior is entirely avoidable by users (don't hit Undo after Enter), I agree that it is not desirable.  At minimum, it should be possible to clear the undo buffer when code is submitted for execution, just as it is when >>> is printed.  That should prevent removal of the entered statement.

I believe Undo is left active during execution so it will be active during user entry in response to input('prompt').  Also, one can start entering input before 'prompt' is printed. So avoiding adding output to Undo would be trickier.

--
Please don't fiddle with the Versions: settings.  This is not a security issue, any change will be applied to 3.5.

----------
versions: +Python 3.5 -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23616>
_______________________________________

From report at bugs.python.org  Mon Mar  9 21:43:20 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 09 Mar 2015 20:43:20 +0000
Subject: [issue20659] Want to make a class method a property by combining
 decorators
In-Reply-To: <1392644637.44.0.107261446205.issue20659@psf.upfronthosting.co.za>
Message-ID: <1425933800.26.0.709553640625.issue20659@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@"the mulhern" sorry that this slipped under our radar.

@Nick I've put you on the nosy list as you actioned #16267 which is referenced in msg211416.

----------
nosy: +BreamoreBoy, ncoghlan
versions: +Python 3.5 -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/issue20659>
_______________________________________

From report at bugs.python.org  Mon Mar  9 21:45:45 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 09 Mar 2015 20:45:45 +0000
Subject: [issue21018] [patch] added missing documentation about escaping
 characters for configparser
In-Reply-To: <1395464420.76.0.68706986346.issue21018@psf.upfronthosting.co.za>
Message-ID: <1425933945.92.0.425554297804.issue21018@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

LGTM so can we have a formal patch review please, thanks.

----------
nosy: +BreamoreBoy
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21018>
_______________________________________

From report at bugs.python.org  Mon Mar  9 21:53:44 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 09 Mar 2015 20:53:44 +0000
Subject: [issue19547] HTTPS proxy support missing without warning
In-Reply-To: <1384119115.17.0.177090288449.issue19547@psf.upfronthosting.co.za>
Message-ID: <1425934423.99.0.00413027405044.issue19547@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19547>
_______________________________________

From report at bugs.python.org  Mon Mar  9 22:00:02 2015
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 09 Mar 2015 21:00:02 +0000
Subject: [issue19547] HTTPS proxy support missing without warning
In-Reply-To: <1384119115.17.0.177090288449.issue19547@psf.upfronthosting.co.za>
Message-ID: <1425934802.11.0.063513291371.issue19547@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +demian.brecht

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19547>
_______________________________________

From report at bugs.python.org  Mon Mar  9 22:14:57 2015
From: report at bugs.python.org (mattip)
Date: Mon, 09 Mar 2015 21:14:57 +0000
Subject: [issue21610] load_module not closing opened files
In-Reply-To: <1401397842.84.0.0447434593999.issue21610@psf.upfronthosting.co.za>
Message-ID: <1425935697.5.0.154311443542.issue21610@psf.upfronthosting.co.za>


mattip added the comment:

ping

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21610>
_______________________________________

From report at bugs.python.org  Mon Mar  9 22:16:21 2015
From: report at bugs.python.org (mattip)
Date: Mon, 09 Mar 2015 21:16:21 +0000
Subject: [issue22308] add {implementation} to sysconfig.py
In-Reply-To: <1409424576.55.0.363891426892.issue22308@psf.upfronthosting.co.za>
Message-ID: <1425935781.17.0.43805228762.issue22308@psf.upfronthosting.co.za>


mattip added the comment:

any traction on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22308>
_______________________________________

From report at bugs.python.org  Mon Mar  9 22:19:05 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Mar 2015 21:19:05 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1425935945.52.0.996279790661.issue23546@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

At one time, there would not have been any point.  https://docs.python.org/3/library/__main__.html#module-__main__ contains this sentence "For a package, the same effect can be achieved by including a __main__.py module, the contents of which will be executed when the module is run with -m.", which was new for 3.0.  The .../2/... doc does not as this is a new-in-3.0 feature.  Thus, I am surprised by
C:\Users\Terry>py -m idlelib
C:\Programs\Python27\python.exe: No module named idlelib.__main__; 'idlelib' is a package and cannot be directly executed
AFAIK, 2.7 should not even be looking for .__main__.

After I copied idlelib/__main__.py to my 2.7 install and repeated the command line, Idle tried to start, but imports of submodules failed, subprocess connection failed, and the editor was opened for blank numbered files like 'C:/programs/python27/50343'.  After that, normal ways of starting Idle also failed similarly.  Reinstalling 2.7 (with remnamts of the old idlelib left) did not fix things.  The only way I found to restore Idle was to delete 2.7 idlelib/ completely and run Programs and Features (win 7) repair, which restores a fresh copy that works again.  I tried again with same results, so I am done experimenting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Mon Mar  9 22:20:14 2015
From: report at bugs.python.org (Ned Deily)
Date: Mon, 09 Mar 2015 21:20:14 +0000
Subject: [issue23623] Python 3.5 docs need to clarify how to set PATH, etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1425936014.16.0.284062641028.issue23623@psf.upfronthosting.co.za>


Ned Deily added the comment:

Steve, how does https://docs.python.org/dev/using/windows.html look now?  (There may have been an update lag.)

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23623>
_______________________________________

From report at bugs.python.org  Mon Mar  9 22:25:36 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 21:25:36 +0000
Subject: [issue23623] Python 3.5 docs need to clarify how to set PATH, etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1425936336.72.0.781580750555.issue23623@psf.upfronthosting.co.za>


Steve Dower added the comment:

Looks good, thanks Ned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23623>
_______________________________________

From report at bugs.python.org  Mon Mar  9 22:27:12 2015
From: report at bugs.python.org (Ned Deily)
Date: Mon, 09 Mar 2015 21:27:12 +0000
Subject: [issue23623] Python 3.5 docs need to clarify how to set PATH, etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1425936432.66.0.641162799068.issue23623@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy:  -ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23623>
_______________________________________

From report at bugs.python.org  Mon Mar  9 22:37:59 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 09 Mar 2015 21:37:59 +0000
Subject: [issue20751] Misleading examples in the descriptor protocol
 documentation
In-Reply-To: <1393193636.36.0.125202538555.issue20751@psf.upfronthosting.co.za>
Message-ID: <1425937079.46.0.587483046646.issue20751@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Who is best placed to comment on the suggested docs changes given in msg212035?

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20751>
_______________________________________

From report at bugs.python.org  Mon Mar  9 22:43:45 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Mar 2015 21:43:45 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425937425.79.0.976341769084.issue23619@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I downloaded .exe from python.org an hour after Steve said 'done' and install went smoothly -- too smoothly as there was not options dialog as to install location or anything.  Fortunately, it did not grab 'python'.  New crt was first thing installed.

Start menu/3.5 is missing 'uninstall' and 'doc server' icons.

Tests fail for text_ctypes (multiple), test_distutils (multiple), test_compileall, test_tcl (line 237, in testLoadWithUNC), test_tools, test_zipfile, and test_multiprocessing_spawn froze Command Prompt so I has to close with red [  X  ] button.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 22:45:30 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 09 Mar 2015 21:45:30 +0000
Subject: [issue20741] Documentation archives should be available also in
 tar.xz format
In-Reply-To: <1393142720.31.0.255845110134.issue20741@psf.upfronthosting.co.za>
Message-ID: <1425937530.05.0.328549563353.issue20741@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Do we need documentation archives in tar.xz format?

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20741>
_______________________________________

From report at bugs.python.org  Mon Mar  9 22:55:48 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 21:55:48 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425938148.58.0.206367858486.issue23619@psf.upfronthosting.co.za>


Steve Dower added the comment:

Thanks for the details Terry.

"Customize" is there for all the options, though I too keep being surprised by just how quickly it gets going when you click one of the other two buttons.

The uninstall icon is probably not going to come back :( I spent some time trying to come up with an approach that would work, but there seems to be no way to know what the command should be. (That said, I just had an idea where we could install the installer and then include a link to that, which would allow it to be uninstalled... hmm...)

I think the ctypes and distutils test failures are expected right now (especially if you don't also have VS 2015 CTP 6 installed), but the others sound new. Do you have the output logged you could post and I'll create issues for them?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 23:01:57 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 09 Mar 2015 22:01:57 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425938517.52.0.460690539119.issue23619@psf.upfronthosting.co.za>


Paul Moore added the comment:

Please don't install the installer somewhere, just to add an uninstall icon on the start menu. It's possible to uninstall via "Add/Remove Programs". That should be sufficient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 23:18:06 2015
From: report at bugs.python.org (Tuomas Suutari)
Date: Mon, 09 Mar 2015 22:18:06 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425857021.1.0.762265375186.issue23602@psf.upfronthosting.co.za>
Message-ID: <CAPXCX8BOyzPP+pC-6W=Td0gPfborZe-2FbEYeeNeQ3RhgrtynQ@mail.gmail.com>


Tuomas Suutari added the comment:

Martin Panter wrote:
> Regarding sharing fractions._parse_format_specifier(), perhaps have a look at _pydecimal._parse_format_specifier()

I did find that, but since it was a private function in private
module, I was unsure if I can use it here. The _pydecimal one parser
also does more stuff that I need.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Mon Mar  9 23:23:51 2015
From: report at bugs.python.org (Tuomas Suutari)
Date: Mon, 09 Mar 2015 22:23:51 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1425939831.67.0.0822431135803.issue23602@psf.upfronthosting.co.za>


Tuomas Suutari added the comment:

Version 3 of the patch. Changes to v2:
 * Use raw-strings for the regexps.
 * Make the specifier regexp more robust with \A, \Z and re.DOTALL.
 * Add more test cases; especially g and e formats and negative fractions.

----------
Added file: http://bugs.python.org/file38413/issue23602v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Mon Mar  9 23:24:34 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Mar 2015 22:24:34 +0000
Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains
In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za>
Message-ID: <1425939874.14.0.929742328769.issue15582@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that supports classes, bound and unbound methods, class methods, properties, method and class descriptors.

----------
Added file: http://bugs.python.org/file38414/inspect_getdoc_inherited.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15582>
_______________________________________

From report at bugs.python.org  Mon Mar  9 23:26:15 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 Mar 2015 22:26:15 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425939975.65.0.455736993668.issue23619@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

If there was a *customize* option in addition to *all users* and *me only*, I did not see it.  I will look harder for a3.  Attached is file with 4 failure messages.

----------
Added file: http://bugs.python.org/file38415/35a2-failures.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 23:30:57 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 Mar 2015 22:30:57 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1425940257.56.0.671621681324.issue23602@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Mon Mar  9 23:40:12 2015
From: report at bugs.python.org (Ned Deily)
Date: Mon, 09 Mar 2015 22:40:12 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1425940812.04.0.649316666534.issue23546@psf.upfronthosting.co.za>


Ned Deily added the comment:

Perhaps I misunderstand what you meant but "python -m module_name" is a documented Python 2 feature:

https://docs.python.org/2/using/cmdline.html#cmdoption-m

I think the failure to initialize when using -m idlelib after copying over __main__.py from Python 3 is caused by IDLE2's reliance on buggy import behavior fixed by Issue7902.  In any case, applying 556b9bafdee8 from Python 3 seems to fix it.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Mon Mar  9 23:44:41 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 22:44:41 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425941081.2.0.456234578202.issue23619@psf.upfronthosting.co.za>


Steve Dower added the comment:

Should have been right there with those two options, looking basically the same. Though it's possible that something about your machine is messing with the sizing - high DPI on Windows 7 is notorious for that, and there are sure to be other potential causes too. Whenever you get a chance to try it again, a screenshot would be nice if it's not there.

There's also some chatter about maybe hiding the all users install behind the Customize button, since it really doesn't gain anything for most people. Then there'd only be two buttons on the front screen, which will make it less likely to be missed.

Thanks for the log. Looks mostly like issues I'd expect when you don't have write permissions for the install directory. Not sure that we have any precedent for dealing with tests that require admin privileges when installed but not in the source tree?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Mon Mar  9 23:55:16 2015
From: report at bugs.python.org (Ned Deily)
Date: Mon, 09 Mar 2015 22:55:16 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425941716.16.0.34922921101.issue23619@psf.upfronthosting.co.za>


Ned Deily added the comment:

"Not sure that we have any precedent for dealing with tests that require admin privileges when installed but not in the source tree?"

I think we do.  With the OS X installer (and, in theory, other Posix-style installs), we have a similar situation where tests are installed without a source tree and I believe they should be expected to be runnable by the user without admin privileges, where necessary, skipping those few test cases that *might* actually need elevated privs.  Granted, we currently don't do a lot of systematic testing of tests from installed locations.  I do as part of the OS X installer building and testing.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Tue Mar 10 00:08:43 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 23:08:43 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425942523.06.0.27685062421.issue23619@psf.upfronthosting.co.za>


Steve Dower added the comment:

Do those assume that no-admin privs will cause a failure? This is more an issue of "do I have write permissions for the install directory" (which I guess could be its own skip condition...).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Tue Mar 10 00:22:42 2015
From: report at bugs.python.org (Ned Deily)
Date: Mon, 09 Mar 2015 23:22:42 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1425943362.61.0.89931590065.issue23546@psf.upfronthosting.co.za>


Ned Deily added the comment:

Sorry, my apologies: I was testing incorrectly. Applying 556b9bafdee8 from Python 3 is not sufficient; there are still some other path import issues with extensions and icon files.  But it shouldn't be hard to track those down and fix them, assuming supporting '-m idlelib' on 2.7 was deemed desirable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Tue Mar 10 00:24:39 2015
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 09 Mar 2015 23:24:39 +0000
Subject: [issue23138] cookiejar parses cookie value as int with empty
 name-value pair and Expires
In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za>
Message-ID: <1425943479.68.0.152958806951.issue23138@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


Removed file: http://bugs.python.org/file38261/issue23138_34.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23138>
_______________________________________

From report at bugs.python.org  Tue Mar 10 00:24:46 2015
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 09 Mar 2015 23:24:46 +0000
Subject: [issue23138] cookiejar parses cookie value as int with empty
 name-value pair and Expires
In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za>
Message-ID: <1425943486.96.0.830338978791.issue23138@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


Removed file: http://bugs.python.org/file38262/issue23138_27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23138>
_______________________________________

From report at bugs.python.org  Tue Mar 10 00:35:20 2015
From: report at bugs.python.org (Ned Deily)
Date: Mon, 09 Mar 2015 23:35:20 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1425944120.6.0.0333598057805.issue23619@psf.upfronthosting.co.za>


Ned Deily added the comment:

Regarding tests trying to write into the install directory tree, I'm pretty sure that there have been fixes added for those but I can't recall off the top of my head specific examples.  I think the best approach is to use a temporary, writable directory instead; if that's not practical, then the test case should be skipped.  I support fixing any tests that still currently fail due to this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Tue Mar 10 00:50:56 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Mon, 09 Mar 2015 23:50:56 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425945056.88.0.039715675854.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

Ryan,
There are utilities you'll need in the KBOX environment, some of which may not be available at the KBOX download site.  

You'll need to download the make, gcc 4.8.0 and gawk packages from the download site, and vim and/or nano depending on your preference. 

If you get an 'undefined reference to dlopen' error during the build, you'll need the updated libfakechroot; update this ticket and I'll figure out a way to get it to you (I'm not sure if the currently available KBOX includes it or not).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Tue Mar 10 01:02:34 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Tue, 10 Mar 2015 00:02:34 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1425945754.69.0.0125121563021.issue23496@psf.upfronthosting.co.za>


Ryan Gonzalez added the comment:

Ugh...

I'll just cross my fingers and hope that the libfakechroot KBOX2 comes with is new enough.

As for a text editor, I'll just probably use something external.

*crosses fingers*

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Tue Mar 10 03:57:24 2015
From: report at bugs.python.org (Scott Dial)
Date: Tue, 10 Mar 2015 02:57:24 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1425956244.38.0.823690217539.issue23605@psf.upfronthosting.co.za>


Scott Dial added the comment:

I cloned https://github.com/benhoyt/scandir @ 494f34d784 and ran benchmark.py on a couple systems that are Linux backed by a couple different NFS servers of various quality.

First, a Linux VM backed by a Mac OS X NFS server backed by a SSD:

$ python benchmark.py
Using slower ctypes version of scandir
Comparing against builtin version of os.walk()
Priming the system's cache...
Benchmarking walks on benchtree, repeat 1/3...
Benchmarking walks on benchtree, repeat 2/3...
Benchmarking walks on benchtree, repeat 3/3...
os.walk took 0.088s, scandir.walk took 0.084s -- 1.1x as fast
$ python benchmark.py -s
Using slower ctypes version of scandir
Comparing against builtin version of os.walk()
Priming the system's cache...
Benchmarking walks on benchtree, repeat 1/3...
Benchmarking walks on benchtree, repeat 2/3...
Benchmarking walks on benchtree, repeat 3/3...
os.walk size 23400, scandir.walk size 23400 -- equal
os.walk took 0.142s, scandir.walk took 0.145s -- 1.0x as fast

Second, a Linux VM backed by a Linux NFS server backed by a NAS with big, slow drives:

$ python benchmark.py
Using slower ctypes version of scandir
Comparing against builtin version of os.walk()
Priming the system's cache...
Benchmarking walks on benchtree, repeat 1/3...
Benchmarking walks on benchtree, repeat 2/3...
Benchmarking walks on benchtree, repeat 3/3...
os.walk took 0.071s, scandir.walk took 0.063s -- 1.1x as fast
$ python benchmark.py -s
Using slower ctypes version of scandir
Comparing against builtin version of os.walk()
Priming the system's cache...
Benchmarking walks on benchtree, repeat 1/3...
Benchmarking walks on benchtree, repeat 2/3...
Benchmarking walks on benchtree, repeat 3/3...
os.walk size 23400, scandir.walk size 23400 -- equal
os.walk took 0.118s, scandir.walk took 0.141s -- 0.8x as fast

Finally, a linux VM backed by a Linux NFS server backed by a NAS with small, fast SAS drives:

$ python benchmark.py
Using slower ctypes version of scandir
Comparing against builtin version of os.walk()
Priming the system's cache...
Benchmarking walks on benchtree, repeat 1/3...
Benchmarking walks on benchtree, repeat 2/3...
Benchmarking walks on benchtree, repeat 3/3...
os.walk took 0.159s, scandir.walk took 0.119s -- 1.3x as fast
$ python benchmark.py -s
Using slower ctypes version of scandir
Comparing against builtin version of os.walk()
Priming the system's cache...
Benchmarking walks on benchtree, repeat 1/3...
Benchmarking walks on benchtree, repeat 2/3...
Benchmarking walks on benchtree, repeat 3/3...
os.walk size 23400, scandir.walk size 23400 -- equal
os.walk took 0.229s, scandir.walk took 0.232s -- 1.0x as fast

A major factor that is not addressed above is that the performance is dramatically different if the metadata cache for the NFS mount is disabled, which is not the default. In the above data, the first system is normally configured in such a manner in order to ensure that the filesystem is coherent. The results of that test is much more dramatic:

$ python benchmark.py
Using slower ctypes version of scandir
Comparing against builtin version of os.walk()
Priming the system's cache...
Benchmarking walks on benchtree, repeat 1/3...
Benchmarking walks on benchtree, repeat 2/3...
Benchmarking walks on benchtree, repeat 3/3...
os.walk took 4.835s, scandir.walk took 0.097s -- 49.9x as fast
$ python benchmark.py -s
Using slower ctypes version of scandir
Comparing against builtin version of os.walk()
Priming the system's cache...
Benchmarking walks on benchtree, repeat 1/3...
Benchmarking walks on benchtree, repeat 2/3...
Benchmarking walks on benchtree, repeat 3/3...
os.walk size 23400, scandir.walk size 23400 -- equal
os.walk took 9.945s, scandir.walk took 5.373s -- 1.9x as fast

----------
nosy: +scott.dial

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Tue Mar 10 04:36:02 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 10 Mar 2015 03:36:02 +0000
Subject: [issue19547] HTTPS proxy support missing without warning
In-Reply-To: <1384119115.17.0.177090288449.issue19547@psf.upfronthosting.co.za>
Message-ID: <1425958562.0.0.913212774977.issue19547@psf.upfronthosting.co.za>


Demian Brecht added the comment:

It very well could be. I'd like to be able to repro it first though. I'll try to get some time to look into it, but if someone else can confirm this behavior and attach a test case, that would be great.

----------
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19547>
_______________________________________

From report at bugs.python.org  Tue Mar 10 06:41:34 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 10 Mar 2015 05:41:34 +0000
Subject: [issue23138] cookiejar parses cookie value as int with empty
 name-value pair and Expires
In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za>
Message-ID: <1425966094.78.0.339669565284.issue23138@psf.upfronthosting.co.za>


Demian Brecht added the comment:

> I think that for consistency either parse empty name-value pair as key="", value=None

There is already a test present (https://hg.python.org/cpython/file/0469af231d22/Lib/test/test_http_cookiejar.py#l1084) that ensures an unset name/value pair is ignored altogether, so I don't think that makes sense from a backwards compatibility standpoint. For consistency, I kept the functionality where nameless cookies are ignored (i.e. "=foo"). I think that while it may be breaking backwards compatibility for buggy edge cases, it's more consistent with existing functionality and actually conforms to the RFC. That said, I'm not going to argue over it heatedly, so if you'd still rather see those cases permitted, let me know and I'll change it.

Valueless cookies are still permitted to keep backwards compatible as there are existing tests for that.

----------
Added file: http://bugs.python.org/file38416/issue23138_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23138>
_______________________________________

From report at bugs.python.org  Tue Mar 10 06:53:55 2015
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Tue, 10 Mar 2015 05:53:55 +0000
Subject: [issue23624] str.center inconsistent with format "^"
Message-ID: <1425966835.2.0.36838695627.issue23624@psf.upfronthosting.co.za>


New submission from Vedran ?a?i?:

Look at this:

    >>> format("ab", "^3"), "ab".center(3)
    ('ab ', ' ab')
    >>> format("abc", "^4"), "abc".center(4)
    ('abc ', 'abc ')

I'm sure you agree this is inconsistent. As far as I can see, format relies on // (flooring) behaviour when dividing remaining space by 2, while .center relies on round (ROUND_HALF_EVEN) behaviour. One of them should be changed to match the other.

As far as I can see, documentation (in neither case) says nothing about how _exactly_ strings are centered when there is an odd number of fill characters, so I would interpret this as: we can change either. (My preference is for .center to be changed, but this is not so important. Consistency is important.)

----------
messages: 237729
nosy: Vedran.?a?i?
priority: normal
severity: normal
status: open
title: str.center inconsistent with format "^"
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23624>
_______________________________________

From report at bugs.python.org  Tue Mar 10 07:01:13 2015
From: report at bugs.python.org (Wei Wu)
Date: Tue, 10 Mar 2015 06:01:13 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>
Message-ID: <1425967273.95.0.0328449034437.issue23566@psf.upfronthosting.co.za>


Wei Wu added the comment:

Attached a patch to this issue. Made some changes to faulthandler_get_fileno to accept integer as fd. If a fd is provided, the file member of fatal_error struct is set NULL.

An new test case is added and some common testing code is also changed in order to be reused.

----------
keywords: +patch
nosy: +kilowu
Added file: http://bugs.python.org/file38417/issue23566.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23566>
_______________________________________

From report at bugs.python.org  Tue Mar 10 07:53:02 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 10 Mar 2015 06:53:02 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <1425970382.91.0.0918714508049.issue23606@psf.upfronthosting.co.za>


eryksun added the comment:

Will manual forwarding eventually be replaced by the loader's ApiSetMap (in the process PEB), i.e. will ucrtbase join ntdll, sechost, kernelbase, and kernel32 in apisetschema.dll? In this case will the CRT API sets only exist in winsxs, i.e. will they no longer be hard linked in System32? 

What about debug builds? python35_d.dll links directly to ucrtbased.dll:

    C:\Program Files\Python35>dumpbin /dependents python35_d.dll | find /i ".dll"
    Dump of file python35_d.dll
        WS2_32.dll
        KERNEL32.dll
        ADVAPI32.dll
        VCRUNTIME140D.dll
        ucrtbased.dll

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23606>
_______________________________________

From report at bugs.python.org  Tue Mar 10 08:04:06 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 10 Mar 2015 07:04:06 +0000
Subject: [issue23624] str.center inconsistent with format "^"
In-Reply-To: <1425966835.2.0.36838695627.issue23624@psf.upfronthosting.co.za>
Message-ID: <1425971046.79.0.395546300034.issue23624@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23624>
_______________________________________

From report at bugs.python.org  Tue Mar 10 08:07:20 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 10 Mar 2015 07:07:20 +0000
Subject: [issue23624] str.center inconsistent with format "^"
In-Reply-To: <1425966835.2.0.36838695627.issue23624@psf.upfronthosting.co.za>
Message-ID: <1425971240.74.0.456937657261.issue23624@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, I prefer the approach which always puts the odd pad character on the right.  I believe this is what most typists would do.  Ideally, the behavior should be the same as in Python 2 (before ROOUND-HALF-EVEN) so that templates don't change their appearance when moving to Python 3.

----------
nosy: +rhettinger
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23624>
_______________________________________

From report at bugs.python.org  Tue Mar 10 08:34:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 07:34:20 +0000
Subject: [issue23138] cookiejar parses cookie value as int with empty
 name-value pair and Expires
In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za>
Message-ID: <1425972860.07.0.422650867038.issue23138@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This looks reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23138>
_______________________________________

From report at bugs.python.org  Tue Mar 10 08:51:14 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 10 Mar 2015 07:51:14 +0000
Subject: [issue21610] load_module not closing opened files
In-Reply-To: <1401397842.84.0.0447434593999.issue21610@psf.upfronthosting.co.za>
Message-ID: <1425973874.0.0.468210092695.issue21610@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21610>
_______________________________________

From report at bugs.python.org  Tue Mar 10 09:16:26 2015
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Tue, 10 Mar 2015 08:16:26 +0000
Subject: [issue23624] str.center inconsistent with format "^"
In-Reply-To: <1425966835.2.0.36838695627.issue23624@psf.upfronthosting.co.za>
Message-ID: <1425975386.81.0.249067171608.issue23624@psf.upfronthosting.co.za>


Vedran ?a?i? added the comment:

If I see right, it seems that that (putting odd pad character on the right) is exactly what format does (I don't have Py2 here to check how exactly it behaves). So, the current proposition to change the .center to match format stays.

(I think I can see how the implementor of .center reasoned: same as people who invented banker's rounding, they wanted to "balance out" odd padding chars among the lines, so that the ammortized number of them on the left and right is the same. But I think consistency matters more here. Noone is summing the spaces on both sides and balancing these numbers, center is primarily for visual purposes, not arithmetical.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23624>
_______________________________________

From report at bugs.python.org  Tue Mar 10 09:38:35 2015
From: report at bugs.python.org (Arnaud Fontaine)
Date: Tue, 10 Mar 2015 08:38:35 +0000
Subject: [issue20613] Wrong line information in bytecode generated by compiler
 module
In-Reply-To: <1392261429.58.0.605484301904.issue20613@psf.upfronthosting.co.za>
Message-ID: <1425976715.4.0.0597213871143.issue20613@psf.upfronthosting.co.za>


Arnaud Fontaine added the comment:

compiler module being deprecated does not mean that it's not used. For example, it is used by RestrictedPython as part of Zope2.

As I could not figure out a way to fix this bug properly, I reverted the following commit and have not had any problem so far (nor my colleagues):
https://hg.python.org/cpython/raw-rev/42faa8054c3d

I have attached the reverted patch to this bug report in case of.

----------
keywords: +patch
Added file: http://bugs.python.org/file38418/fix_compiler_module_issue_20613.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20613>
_______________________________________

From report at bugs.python.org  Tue Mar 10 10:42:45 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 10 Mar 2015 09:42:45 +0000
Subject: [issue23624] str.center inconsistent with format "^"
In-Reply-To: <1425966835.2.0.36838695627.issue23624@psf.upfronthosting.co.za>
Message-ID: <1425980565.43.0.0947150285042.issue23624@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I agree it would be nice to be consistent, and that str.__format__'s approach is likely the desirable one.

But is it worth the breakage? Surely someone cares about the current behavior. Does this cause any practical, real-world problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23624>
_______________________________________

From report at bugs.python.org  Tue Mar 10 10:44:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 09:44:23 +0000
Subject: [issue16200] Setting .posix=True for shlex object causes infinite
 loop in __next__
In-Reply-To: <1349982570.12.0.849029926696.issue16200@psf.upfronthosting.co.za>
Message-ID: <1425980663.72.0.256423945015.issue16200@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are 18 public writable attributes in shlex object, and unthinking setting some of them can make shlex to produce incorrect results or create an infinite loop. For example there is nothing to prevent your from setting the eof attribute. Only 14 of 18 attributes is documented and posix is not in this set.

One of solutions is just does nothing. We are all consenting adults here.

More protective solution is to make undocumented attributes (filestack, posix, pushback, state) private. For backward compatibility we can temporary add properties that will emit deprecation warnings.

----------
nosy: +serhiy.storchaka
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16200>
_______________________________________

From report at bugs.python.org  Tue Mar 10 10:52:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 09:52:02 +0000
Subject: [issue23624] str.center inconsistent with format "^"
In-Reply-To: <1425966835.2.0.36838695627.issue23624@psf.upfronthosting.co.za>
Message-ID: <1425981122.56.0.641174194288.issue23624@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The behavior of Python 2.7 is the same as Python 3.x.

str.center() is very old method and changing it will change formatted reports generated by third-party software in all world. At least this will break many tests. And this will add yet one incompatibility between Python 2 and Python 3.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23624>
_______________________________________

From report at bugs.python.org  Tue Mar 10 10:59:38 2015
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Tue, 10 Mar 2015 09:59:38 +0000
Subject: [issue23624] str.center inconsistent with format "^"
In-Reply-To: <1425966835.2.0.36838695627.issue23624@psf.upfronthosting.co.za>
Message-ID: <1425981578.5.0.353639374789.issue23624@psf.upfronthosting.co.za>


Vedran ?a?i? added the comment:

By that line of reasoning, we would probably never change anything. :-( I searched the documentation, and the exact behaviour isn't documented anywhere. In fact all examples are of the kind where there is an even number of fill chars. I thought it was ok to "break" undocumented things.

As for a practical problem, here is how I encountered it. I had a format that centered something inside a constant-width column. format("^79", title) it was, I think. Then, as it usually happens, things were generalized and the width was customizable. Of course, I could have used "{:^{}}".format(title, width), but title.center(width) really seemed like a better option.

Imagine my horror when a test failed. At first I thought, ok, format puts extra space on one side, .center at the other, no big deal. But then I changed it, and it failed again. Many time and lost nerves later (not something I usually associate with Python), I realized that those two use different _methods_ of calculating the distribution of spaces.

At that moment, I really thought it must be a bug. But I went to the docs, and they never said anything about where an extra fill char is put. So yes, it is _theoretically_ possible that this is exactly the intended behaviour. But I really think it's not the case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23624>
_______________________________________

From report at bugs.python.org  Tue Mar 10 11:07:42 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 10 Mar 2015 10:07:42 +0000
Subject: [issue23491] PEP 441 - Improving Python Zip Application Support
In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za>
Message-ID: <1425982062.44.0.253587410501.issue23491@psf.upfronthosting.co.za>


Paul Moore added the comment:

There's a problem with the latest patch, it's lost the MSI updates somehow. I'll add them back in this evening, please don't commit before a v6 patch is available,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23491>
_______________________________________

From report at bugs.python.org  Tue Mar 10 11:27:16 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 10 Mar 2015 10:27:16 +0000
Subject: [issue23491] PEP 441 - Improving Python Zip Application Support
In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za>
Message-ID: <1425983236.86.0.306236878793.issue23491@psf.upfronthosting.co.za>


Paul Moore added the comment:

Steve Dower - could you please review the updated patch here. The WiX changes specifically are intended to register the .pyz extension with the launcher, but I can see no code that does this for a per-user install. I've copied the same code for the .py extension so I don't think I've missed anything, but I can't see how this would work in practice.

----------
Added file: http://bugs.python.org/file38419/pep-441.v6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23491>
_______________________________________

From report at bugs.python.org  Tue Mar 10 11:44:41 2015
From: report at bugs.python.org (Michael Goldish)
Date: Tue, 10 Mar 2015 10:44:41 +0000
Subject: [issue23187] Segmentation fault, possibly asyncio related
In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za>
Message-ID: <1425984281.21.0.301737870171.issue23187@psf.upfronthosting.co.za>


Michael Goldish added the comment:

I'm not sure where to post this as the issue is closed:

I've encountered the same problem. I don't have a stack trace to share at the moment but I know it's almost (or entirely) identical.

My context:
- Windows
- Happens with Python 3.4.2 and 3.4.3 (and possibly earlier versions)
- Pure Python (no external binary modules whatsoever)
- Pure asyncio (no Tornado)
- Not using json/ujson
- Plenty of memory available

The crash seems to occur at random, with anything between 1 and 20 days separating consecutive crashes.

I have core dumps if you're interested but am not sure where to upload them.

----------
nosy: +michaelg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23187>
_______________________________________

From report at bugs.python.org  Tue Mar 10 11:47:52 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 10 Mar 2015 10:47:52 +0000
Subject: [issue23088] Document that PyUnicode_AsUTF8() returns a
 null-terminated string
In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>
Message-ID: <1425984472.33.0.659798636612.issue23088@psf.upfronthosting.co.za>


Martin Panter added the comment:

Posting a new patch that says that the NUL is always appended for both Unicode and Bytes, and explicitly says that internal NULs are allowed.

----------
Added file: http://bugs.python.org/file38420/utf8-null.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23088>
_______________________________________

From report at bugs.python.org  Tue Mar 10 11:52:45 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 10:52:45 +0000
Subject: [issue9731] Add ABCMeta.has_methods and tests that use it
In-Reply-To: <1283346153.7.0.611629242062.issue9731@psf.upfronthosting.co.za>
Message-ID: <1425984765.58.0.0504881524166.issue9731@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What if abstract class contains not only abstract methods, but default implementation of some methods? Should the predicate test if tested class contain these methods?

For example, the Sequence ABC contains default implementation of __iter__. Should the predicate test that concrete sequence class implements __iter__?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9731>
_______________________________________

From report at bugs.python.org  Tue Mar 10 12:05:18 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Mar 2015 11:05:18 +0000
Subject: [issue23187] Segmentation fault, possibly asyncio related
In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za>
Message-ID: <1425985518.53.0.667499569888.issue23187@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I'm not sure where to post this as the issue is closed:

Please open a new issue.

> I've encountered the same problem.

Why do you consider that it's the same issue?

> The crash seems to occur at random, with anything between 1 and 20 days separating consecutive crashes.

Outch. I hate such random bugs.

> I have core dumps if you're interested but am not sure where to upload them.

I don't know how to analyze a Windows core dump.

Sorry, but without more information, it will be almost impossible to fix your issue. You can try to use faulthandler to write the traceback of all Python threads where the crash occurred:
https://docs.python.org/dev/library/faulthandler.html#faulthandler.enable

Write the ouput into a file. The output is text.


Brian Curtin wrote a similar tool but more specific to Windows:
https://bitbucket.org/briancurtin/minidumper/

"minidumper writes "minidumps" for post-mortem analysis of crashes in Python or its extensions."

Problem: I don't know how to use such dump!? I guess that Visual Studio can load such minidump files.
https://msdn.microsoft.com/en-us/library/windows/desktop/ee416349%28v=vs.85%29.aspx#analyzing_a_minidump


Did you see some errors or warnings when running your application with asyncio in debug mode?
https://docs.python.org/dev/library/asyncio-dev.html

Please use at least Python 3.4.3 which embeds a recent version of asyncio, it enables more checks in debug mode.


Can you maybe send me the source code of your application?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23187>
_______________________________________

From report at bugs.python.org  Tue Mar 10 12:14:46 2015
From: report at bugs.python.org (=?utf-8?q?Thomas_G=C3=BCttler?=)
Date: Tue, 10 Mar 2015 11:14:46 +0000
Subject: [issue23625] load_module() docs: zipped eggs are not loaded.
Message-ID: <1425986086.94.0.227506635369.issue23625@psf.upfronthosting.co.za>


New submission from Thomas G?ttler:

Please update the docs of imp.find_module()

https://docs.python.org/2/library/imp.html#imp.find_module

zipped egg files in sys.path are not found.

Please provide a link how to find modules in sys.path like the interpreter does (with support of zipped egg files).

----------
messages: 237746
nosy: Thomas G?ttler
priority: normal
severity: normal
status: open
title: load_module() docs: zipped eggs are not loaded.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23625>
_______________________________________

From report at bugs.python.org  Tue Mar 10 12:16:40 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 11:16:40 +0000
Subject: [issue23088] Document that PyUnicode_AsUTF8() returns a
 null-terminated string
In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>
Message-ID: <1425986200.75.0.967310631185.issue23088@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are other functions that returns null terminated data: PyByteArray_AsString(), PyBytes_AsStringAndSize(), PyUnicode_AS_UNICODE(), PyUnicode_AsUCS4Copy() PyUnicode_AsUnicode(), PyUnicode_AsUnicodeAndSize(), PyUnicode_AsWideCharString() and may be more. See also examples of notes about embedded null characters.

And for consistency with all other documentation this should be written as "null byte/character", not NUL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23088>
_______________________________________

From report at bugs.python.org  Tue Mar 10 12:21:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 11:21:08 +0000
Subject: [issue23624] str.center inconsistent with format "^"
In-Reply-To: <1425981578.5.0.353639374789.issue23624@psf.upfronthosting.co.za>
Message-ID: <2374279.vzRVkX0ZhS@raxxla>


Serhiy Storchaka added the comment:

The problem is that it is not *obvious* what method is more correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23624>
_______________________________________

From report at bugs.python.org  Tue Mar 10 12:26:40 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Mar 2015 11:26:40 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>
Message-ID: <1425986800.45.0.0960302420854.issue23566@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@kilowu: Thanks, I reviewed your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23566>
_______________________________________

From report at bugs.python.org  Tue Mar 10 12:27:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Mar 2015 11:27:57 +0000
Subject: [issue23088] Document that PyUnicode_AsUTF8() returns a
 null-terminated string
In-Reply-To: <1425986200.75.0.967310631185.issue23088@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa9PyepEKH-vUDTd9WUkSQ_aDg27PbnZsLACdO5SNvbAw@mail.gmail.com>


STINNER Victor added the comment:

Serhiy Storchaka added the comment:
> And for consistency with all other documentation this should be written as "null byte/character", not NUL.

Agreed!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23088>
_______________________________________

From report at bugs.python.org  Tue Mar 10 12:29:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 11:29:31 +0000
Subject: [issue23088] Document that PyUnicode_AsUTF8() returns a
 null-terminated string
In-Reply-To: <CAMpsgwa9PyepEKH-vUDTd9WUkSQ_aDg27PbnZsLACdO5SNvbAw@mail.gmail.com>
Message-ID: <1868065.xC6uC5Mtcv@raxxla>


Serhiy Storchaka added the comment:

Yes, and for agreement with Victor. ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23088>
_______________________________________

From report at bugs.python.org  Tue Mar 10 12:32:35 2015
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Tue, 10 Mar 2015 11:32:35 +0000
Subject: [issue23624] str.center inconsistent with format "^"
In-Reply-To: <1425966835.2.0.36838695627.issue23624@psf.upfronthosting.co.za>
Message-ID: <1425987155.87.0.360697003694.issue23624@psf.upfronthosting.co.za>


Vedran ?a?i? added the comment:

We can make a poll, I think it is quite obvious. But that's not really the point.

I would accept the solution enabling _both_ methods of rounding with _both_ methods of formatting (it isn't even very hard to do: .center can take additional argument, mandatory keyword if necessary, and format can use "=" for .center centering, or if you're worried about confusion with numeric types, invent another symbol - or even use "^" with alternative format "#").

But I can't accept that "there is no obviously correct method" be a reason for .center and format doing it in two different ways. I'm convinced nobody switches from format to .center _because_ they want another method of distributing fills. They switch, like I did, because a constand-width field has become variable-width, and nested formats are ugly - and then have to deal with things breaking, writing 4 lines where previously there was only 1, checking remainders by 2 here and there, and having a hard time generally. And never being sure if it's correct, since the real behaviour is undocumented. :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23624>
_______________________________________

From report at bugs.python.org  Tue Mar 10 12:36:49 2015
From: report at bugs.python.org (Ben Hoyt)
Date: Tue, 10 Mar 2015 11:36:49 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <1425987409.52.0.962767719106.issue22524@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

Hi Victor. I'm attaching a patch to the What's New doc. I know it's a minor thing, but I really read the What's New in Python x.y page whenever it comes out, so making this as specific as possible is good. The changes are:

1. Be more specific and flesh it out slightly: for example, instead of just saying "PEP 471 adds a new directory iteration function", say very briefly why it was added (to speed up os.walk) and what it achieves.
2. Move "PEP and implementation by..." under correct correct PEP -- it's currently under PEP 475.
3. Be more specific (as per point 1) under os.scandir(), and link to issue
4. Add a note about the os.walk() performance improvement under Optimizations. I realize the changes to os.walk() haven't been committed yet, but hopefully they will be quite soon.

Any feedback? Are you happy to commit these changes?

I intend to do some review of the scandir/DirEntry docs as well. I'll send those in the next few days.

----------
Added file: http://bugs.python.org/file38421/whatsnew.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Tue Mar 10 13:07:54 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Mar 2015 12:07:54 +0000
Subject: [issue20659] Want to make a class method a property by combining
 decorators
In-Reply-To: <1392644637.44.0.107261446205.issue20659@psf.upfronthosting.co.za>
Message-ID: <1425989274.41.0.584161822622.issue20659@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

To get the behaviour you're requesting, you need to use a custom metaclass and define the property there. The reason is that the descriptor machinery is bypassed entirely when setting or deleting an attribute on the class itself:

>>> class Example:
...     @property
...     def p(self):
...         return 1
... 
>>> Example.p
<property object at 0x7f0901d7d548>
>>> Example().p
1
>>> Example().p = 2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: can't set attribute
>>> Example.p = 2
>>> Example.p
2
>>> Example().p
2
>>> Example().p = 3

Hence, the only way to get a "class property" is to use the normal @property descriptor in a custom metaclass (i.e. the class-of-the-class)

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20659>
_______________________________________

From report at bugs.python.org  Tue Mar 10 13:25:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Mar 2015 12:25:32 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <20150310122529.9688.92352@psf.io>


Roundup Robot added the comment:

New changeset 52c7017fdcdd by Victor Stinner in branch 'default':
Issue #23571: Oops, fix #ifdef assert()
https://hg.python.org/cpython/rev/52c7017fdcdd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Tue Mar 10 13:25:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Mar 2015 12:25:32 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <20150310122529.9688.86175@psf.io>


Roundup Robot added the comment:

New changeset f805fdacdfe0 by Victor Stinner in branch 'default':
Issue #23605: os.walk() now calls os.scandir() instead of os.listdir().
https://hg.python.org/cpython/rev/f805fdacdfe0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Tue Mar 10 13:26:55 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Mar 2015 12:26:55 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1425990415.13.0.447937017487.issue23605@psf.upfronthosting.co.za>


STINNER Victor added the comment:

My suggestion to add a new walk_dirs list is wrong: os.walk() documentation explicitly says that the dirs list can be modified to delete some directories:
https://docs.python.org/dev/library/os.html#os.walk
"""
When topdown is True, the caller can modify the dirnames list in-place (perhaps using del or slice assignment), and walk() will only recurse into the subdirectories whose names remain in dirnames; this can be used to prune the search, impose a specific order of visiting, or even to inform walk() about directories the caller creates or renames before it resumes walk() again.
"""

os_walk_1.patch is inefficient: it also calls entry.is_symlink() for file entries.

I reworked your patch to only call is_symlink() for directories.

Thanks for the patch Ben. I think that we are now done with the PEP 471 no? Maybe some doc changes (I'm now reviewing your doc change in issue #22524).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Tue Mar 10 13:29:53 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Mar 2015 12:29:53 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <20150310122950.16643.77201@psf.io>


Roundup Robot added the comment:

New changeset 8d76dabd40f6 by Victor Stinner in branch 'default':
Issue #22524: Rephrase scandir addition in What's New in Python 3.5
https://hg.python.org/cpython/rev/8d76dabd40f6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Tue Mar 10 13:32:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Mar 2015 12:32:07 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <20150310123205.1178.59912@psf.io>


Roundup Robot added the comment:

New changeset 50e32059a404 by Victor Stinner in branch '3.4':
Issue #23605: os.walk() doc now mentions shutil.rmtree() in the last example
https://hg.python.org/cpython/rev/50e32059a404

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Tue Mar 10 13:37:09 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 Mar 2015 12:37:09 +0000
Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains
In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za>
Message-ID: <1425991029.21.0.178488484783.issue15582@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Serhiy's patch looks good to me.

I'd completely missed that __qualname__ could be used to avoid needing a second argument even when handling objects other than bound methods. That's very cool, and I can see why you figured it was easier to just write the patch than explain what you had in mind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15582>
_______________________________________

From report at bugs.python.org  Tue Mar 10 13:40:11 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Mar 2015 12:40:11 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1425987409.52.0.962767719106.issue22524@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaBSvOMReOEKLw9sax0AngSLU5xmjH43YijV7O=oFD0xw@mail.gmail.com>


STINNER Victor added the comment:

2015-03-10 12:36 GMT+01:00 Ben Hoyt <report at bugs.python.org>:
> I intend to do some review of the scandir/DirEntry docs as well. I'll send those in the next few days.

Open maybe a new issue if you want to enhance the doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Tue Mar 10 13:46:51 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Mar 2015 12:46:51 +0000
Subject: [issue23432] Duplicate content in SystemExit documentation
In-Reply-To: <1423571355.15.0.388380550498.issue23432@psf.upfronthosting.co.za>
Message-ID: <20150310124647.16649.64982@psf.io>


Roundup Robot added the comment:

New changeset 64c0b4aead0f by Berker Peksag in branch '3.4':
Issue #23432: Remove duplicate content from SystemExit docs.
https://hg.python.org/cpython/rev/64c0b4aead0f

New changeset 5163fb8dc61f by Berker Peksag in branch 'default':
Issue #23432: Remove duplicate content from SystemExit docs.
https://hg.python.org/cpython/rev/5163fb8dc61f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23432>
_______________________________________

From report at bugs.python.org  Tue Mar 10 13:47:58 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 10 Mar 2015 12:47:58 +0000
Subject: [issue23432] Duplicate content in SystemExit documentation
In-Reply-To: <1423571355.15.0.388380550498.issue23432@psf.upfronthosting.co.za>
Message-ID: <1425991678.78.0.596547464013.issue23432@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the review, Martin.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23432>
_______________________________________

From report at bugs.python.org  Tue Mar 10 14:06:38 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 10 Mar 2015 13:06:38 +0000
Subject: [issue23491] PEP 441 - Improving Python Zip Application Support
In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za>
Message-ID: <1425992798.56.0.400370847833.issue23491@psf.upfronthosting.co.za>


Steve Dower added the comment:

The whole installer is run with a different global flag depending on the type of install. So it's automatic, though sometimes you can't do both per-user and all-user changes at the same time (not that you should anyway).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23491>
_______________________________________

From report at bugs.python.org  Tue Mar 10 14:24:41 2015
From: report at bugs.python.org (Ben Hoyt)
Date: Tue, 10 Mar 2015 13:24:41 +0000
Subject: [issue22524] PEP 471 implementation: os.scandir() directory scanning
 function
In-Reply-To: <1412088162.24.0.84630531931.issue22524@psf.upfronthosting.co.za>
Message-ID: <1425993881.41.0.936343560378.issue22524@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

Thanks. Will do!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22524>
_______________________________________

From report at bugs.python.org  Tue Mar 10 14:28:02 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 10 Mar 2015 13:28:02 +0000
Subject: [issue23491] PEP 441 - Improving Python Zip Application Support
In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za>
Message-ID: <1425994082.35.0.621999057999.issue23491@psf.upfronthosting.co.za>


Paul Moore added the comment:

OK, so if the installer changes look good to you, then this PR is once again ready to go. Sorry to anyone watching for the glitch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23491>
_______________________________________

From report at bugs.python.org  Tue Mar 10 14:38:37 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 10 Mar 2015 13:38:37 +0000
Subject: [issue23626] Windows per-user install of 3.5a2 doesn't associate .py
 files with the new launcher
Message-ID: <1425994717.16.0.260924440644.issue23626@psf.upfronthosting.co.za>


New submission from Paul Moore:

Installing Python 3.5a2 with the 64-bit Windows installer using a user-level install doesn't associate .py files with the new (3.5) version of the launcher.

I encountered this when there was an existing system install of Python 3.4, so .py files remained associated with that. I presume in the absence of a previous install there would have been no association at all (but I haven't tested that).

----------
assignee: steve.dower
components: Installation, Windows
messages: 237767
nosy: pmoore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows per-user install of 3.5a2 doesn't associate .py files with the new launcher
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23626>
_______________________________________

From report at bugs.python.org  Tue Mar 10 15:16:49 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 10 Mar 2015 14:16:49 +0000
Subject: [issue23138] cookiejar parses cookie value as int with empty
 name-value pair and Expires
In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za>
Message-ID: <1425997009.3.0.0659921798053.issue23138@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23138>
_______________________________________

From report at bugs.python.org  Tue Mar 10 15:17:53 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 10 Mar 2015 14:17:53 +0000
Subject: [issue20613] Wrong line information in bytecode generated by compiler
 module
In-Reply-To: <1392261429.58.0.605484301904.issue20613@psf.upfronthosting.co.za>
Message-ID: <1425997073.41.0.13133253666.issue20613@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20613>
_______________________________________

From report at bugs.python.org  Tue Mar 10 15:20:43 2015
From: report at bugs.python.org (Andriy Sokolovskiy)
Date: Tue, 10 Mar 2015 14:20:43 +0000
Subject: [issue21574] Port image types detections from PIL to the imghdr module
In-Reply-To: <1401010621.11.0.919611847501.issue21574@psf.upfronthosting.co.za>
Message-ID: <1425997243.92.0.434441170694.issue21574@psf.upfronthosting.co.za>


Andriy Sokolovskiy added the comment:

@Claudiu Popa, IIRC I did not add 1-2 test images because I not found how to make image or how to convert image to this format.
So, if there will no chance to add them, should we remove these formats from the patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21574>
_______________________________________

From report at bugs.python.org  Tue Mar 10 15:26:26 2015
From: report at bugs.python.org (pushpendre rastogi)
Date: Tue, 10 Mar 2015 14:26:26 +0000
Subject: [issue23627] Incorrect string formatting of float values in Python 2.7
Message-ID: <1425997586.58.0.418147847293.issue23627@psf.upfronthosting.co.za>


New submission from pushpendre rastogi:

Hi, The string formatting module in python 2.7 incorrectly formats floating point values. The following code shows the problem

>>> print "%.10s"%(-7.7176718e-05)
-7.7176718
>> print "%.10s"%(-0.0000771767)
-7.71767e-

Ideally the code should have thrown an exception (first preference)
or it should have printed  -0.0000771767 (second preference) or -7.7176718e-05 (third preference)

----------
components: Library (Lib)
messages: 237769
nosy: pushpendre rastogi
priority: normal
severity: normal
status: open
title: Incorrect string formatting of float values in Python 2.7
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23627>
_______________________________________

From report at bugs.python.org  Tue Mar 10 15:40:13 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 10 Mar 2015 14:40:13 +0000
Subject: [issue7803] setup hangs on disk space requirements
In-Reply-To: <1264761765.74.0.819824298395.issue7803@psf.upfronthosting.co.za>
Message-ID: <1425998413.69.0.381314457205.issue7803@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Steve can you close this please.

----------
nosy: +BreamoreBoy, steve.dower
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7803>
_______________________________________

From report at bugs.python.org  Tue Mar 10 15:41:42 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 10 Mar 2015 14:41:42 +0000
Subject: [issue23628] See if os.scandir() could help speed up importlib
Message-ID: <1425998502.08.0.152155367822.issue23628@psf.upfronthosting.co.za>


New submission from Brett Cannon:

With os.scandir() now committed and implemented in C, it would be interesting to see if os.scandir() could provide any performance benefit to importlib. If finders can pass the DirEntry to loaders then some stat calls could potentially be saved at the expense of stale file metadata.

Even if the performance is flat and the sharing of cached information is deemed not worth it, os.scandir() might still be beneficial by ditching some custom code in importlib that exists purely to replicate Python code from os.py, like _path_isfile().

----------
assignee: brett.cannon
components: Interpreter Core
messages: 237771
nosy: brett.cannon
priority: low
severity: normal
stage: needs patch
status: open
title: See if os.scandir() could help speed up importlib
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23628>
_______________________________________

From report at bugs.python.org  Tue Mar 10 16:01:09 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 10 Mar 2015 15:01:09 +0000
Subject: [issue23627] Incorrect string formatting of float values in Python 2.7
In-Reply-To: <1425997586.58.0.418147847293.issue23627@psf.upfronthosting.co.za>
Message-ID: <1425999669.37.0.287094295348.issue23627@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

By using %s, you're asking the formatting code to first convert the parameter to a string. Then, by using .10, you're asking it to truncate the value.

It's essentially equivalent to:

>>> str(-7.7176718e-05)
'-7.7176718e-05'
>>> str(-7.7176718e-05)[:10]
'-7.7176718'

and:

>>> str(-0.0000771767)
'-7.71767e-05'
>>> str(-0.0000771767)[:10]
'-7.71767e-'

This isn't a bug. If you want more control over the formatting, use %f, %e, or %g:

>>> '%.10f' % -7.7176718e-05
'-0.0000771767'

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23627>
_______________________________________

From report at bugs.python.org  Tue Mar 10 16:26:15 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 10 Mar 2015 15:26:15 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <1426001175.01.0.273810371265.issue23606@psf.upfronthosting.co.za>


Steve Dower added the comment:

Good question, I'm not sure. Right now, the api-* DLLs use forwarding rather than apisetschema, but that could change. Since they support back to XP though, I suspect it probably won't the api-* DLLs will stay as they are with ucrtbase exporting ordinals rather than names.

ucrtbased is probably going to stay as it is. When you install a debug runtime you're voluntarily giving up well-defined versioning. You'll only have that file installed if you have VS 2015 or later though - it won't be part of the updates for everyone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23606>
_______________________________________

From report at bugs.python.org  Tue Mar 10 16:29:26 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Tue, 10 Mar 2015 15:29:26 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1426001366.77.0.617022467752.issue23496@psf.upfronthosting.co.za>


Ryan Gonzalez added the comment:

Ok, please bear with me. I'm going to be REALLY busy for a bit; I have a BIG test/exam coming up next week, a music recital shortly afterwards, and lots of stuff/studying in between.

Sorry for any delays!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Tue Mar 10 16:33:15 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 10 Mar 2015 15:33:15 +0000
Subject: [issue7803] setup hangs on disk space requirements
In-Reply-To: <1264761765.74.0.819824298395.issue7803@psf.upfronthosting.co.za>
Message-ID: <1426001595.47.0.249756609098.issue7803@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at microsoft.com>:


----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7803>
_______________________________________

From report at bugs.python.org  Tue Mar 10 16:34:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 15:34:09 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1426001649.86.0.41117081211.issue23605@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

When followlinks is true, symlinks is not needed.

But I this commit breaks a code like following:

def unsymlink(top):
    for root, dirs, files in os.walk(top):
        for name in dirs:
            path = os.path.join(root, name)
            if os.path.islink(path):
                target = os.path.join(root, os.readlink(path))
                os.unlink(path)
                shutil.copytree(target, path)
        for name in files:
            path = os.path.join(root, name)
            if os.path.islink(path):
                target = os.path.join(root, os.readlink(path))
                os.unlink(path)
                shutil.copy2(target, path)

----------
nosy: +serhiy.storchaka
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Tue Mar 10 16:44:19 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Mar 2015 15:44:19 +0000
Subject: [issue23629] Default __sizeof__ is wrong for var-sized objects
Message-ID: <1426002259.25.0.401694391435.issue23629@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

In the stdlib, this only appears with the memoryview object, but third-party types can be affected. Attaching patch.

----------
components: Interpreter Core
messages: 237776
nosy: pitrou, serhiy.storchaka, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Default __sizeof__ is wrong for var-sized objects
type: behavior
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23629>
_______________________________________

From report at bugs.python.org  Tue Mar 10 16:44:31 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Mar 2015 15:44:31 +0000
Subject: [issue23629] Default __sizeof__ is wrong for var-sized objects
In-Reply-To: <1426002259.25.0.401694391435.issue23629@psf.upfronthosting.co.za>
Message-ID: <1426002271.19.0.044513011247.issue23629@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
keywords: +patch
Added file: http://bugs.python.org/file38422/sizeof_var_obj.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23629>
_______________________________________

From report at bugs.python.org  Tue Mar 10 16:48:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Mar 2015 15:48:15 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1426001649.86.0.41117081211.issue23605@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ9E5bp-gqiv5ZfOndSLJwT5tGeA=tKOt31EDDb9yoLAA@mail.gmail.com>


STINNER Victor added the comment:

Serhiy Storchaka added the comment:
> When followlinks is true, symlinks is not needed.

Hum, it's not easy to understand your code. I guess that the problem
is that a symlink to a directory can become something else (not a
directory or a symlink to a directory).

I noticed this race condition in the new implementation of os.walk(),
but I don't think that the issue is really new. The old implementation
of os.walk() already uses a list of directories. The caller can remove
a directory or replace a directory with something else.

Since the bug is not documented in os.walk(), I chose to not document
it neither. But it would be better to warn users to not do that :-)

@Serhiy: I agree that the new implementation changes the behaviour,
but I don't consider it as as bug. Do you think that it's a bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Tue Mar 10 17:37:50 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Mar 2015 16:37:50 +0000
Subject: [issue23595] Split the math module into _math (C) + math (py)
In-Reply-To: <1425596251.36.0.618519082533.issue23595@psf.upfronthosting.co.za>
Message-ID: <1426005470.51.0.307685622474.issue23595@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ok, fair enough, I abandon my change.

I agree that a partial implementation of math.py (only a few functions) is not useful. To implement more math functions, struct and ctypes modules are probably needed. But it sounds overkill, since CPython already has a full implementation of math written in C.

It's quite easy to implement the math module for other Python implementations (Jython, IronPython, PyPy, etc.). So I agree that math.py is useless. We all want a super fast (optimized) math module ;-)

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23595>
_______________________________________

From report at bugs.python.org  Tue Mar 10 17:39:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 16:39:22 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <CAMpsgwZ9E5bp-gqiv5ZfOndSLJwT5tGeA=tKOt31EDDb9yoLAA@mail.gmail.com>
Message-ID: <1753439.yBh0jdpc8m@raxxla>


Serhiy Storchaka added the comment:

My first note was about efficiency of the implementation. When followlinks is 
true, you can avoid testing entry.is_link() and creating the symlinks set.

The new implementation of os.walk() changes a behavior. The problem is that a 
symlink to a directory can become a directory. It is documented that the 
caller can remove or add a directory to directory list and for sure this 
feature is used in third-party code. In my example a directory list is even 
not changed, but file system is changed.

I think that majority of uses of os.walk() will be not affected by this change, 
but for sure there is a code that will be broken and we can receive bug 
reports after releasing 3.6.

New behavior also is not consistent with os.fwalk().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Tue Mar 10 17:57:50 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Mar 2015 16:57:50 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <20150310165745.117194.99636@psf.io>


Roundup Robot added the comment:

New changeset 86c9ef950288 by Steve Dower in branch 'default':
Issue #23606: Disable ctypes.util.find_library("c") on Windows so tests are skipped while we figure out how best to approach the CRT change
https://hg.python.org/cpython/rev/86c9ef950288

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23606>
_______________________________________

From report at bugs.python.org  Tue Mar 10 18:01:06 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 10 Mar 2015 17:01:06 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <1426006866.43.0.0599559926579.issue23606@psf.upfronthosting.co.za>


Steve Dower added the comment:

That change should get the buildbots passing again, as it will now skip those tests. The "appcrt%d" return value was blatantly incorrect anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23606>
_______________________________________

From report at bugs.python.org  Tue Mar 10 18:11:33 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 10 Mar 2015 17:11:33 +0000
Subject: [issue23615] Reloading tokenize breaks tokenize.open()
In-Reply-To: <1425864069.02.0.403381374988.issue23615@psf.upfronthosting.co.za>
Message-ID: <1426007493.17.0.58913026908.issue23615@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Patch attached to fix this.

----------
keywords: +patch
Added file: http://bugs.python.org/file38423/tokenize-reloadable.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23615>
_______________________________________

From report at bugs.python.org  Tue Mar 10 18:28:44 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 17:28:44 +0000
Subject: [issue23629] Default __sizeof__ is wrong for var-sized objects
In-Reply-To: <1426002259.25.0.401694391435.issue23629@psf.upfronthosting.co.za>
Message-ID: <1426008524.53.0.331827063872.issue23629@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Good catch! How it worked before?

Now we can remove __sizeof__ implementations for tuples and bytes.

Could you please add sizeof test for PyStructSequence types?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23629>
_______________________________________

From report at bugs.python.org  Tue Mar 10 18:41:41 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Mar 2015 17:41:41 +0000
Subject: [issue23629] Default __sizeof__ is wrong for var-sized objects
In-Reply-To: <1426002259.25.0.401694391435.issue23629@psf.upfronthosting.co.za>
Message-ID: <1426009301.74.0.421661464118.issue23629@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23629>
_______________________________________

From report at bugs.python.org  Tue Mar 10 18:41:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 17:41:59 +0000
Subject: [issue23615] Reloading tokenize breaks tokenize.open()
In-Reply-To: <1425864069.02.0.403381374988.issue23615@psf.upfronthosting.co.za>
Message-ID: <1426009319.84.0.47662620948.issue23615@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The same issue exists in Lib/bz2.py, Lib/tarfile.py, Tools/freeze/bkfile.py.

May be write a code as

from builtins import open as _builtin_open

?

----------
nosy: +brett.cannon, eric.snow, ncoghlan, serhiy.storchaka
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23615>
_______________________________________

From report at bugs.python.org  Tue Mar 10 18:45:29 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Tue, 10 Mar 2015 17:45:29 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1426009529.24.0.0200658084804.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

Dog just died unexpectedly, behind on photograph project, need to start on Python tutorial, have a chat in a different language on Sunday I need to prep for and its patch day tomorrow.

So yeah. Completely understand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Tue Mar 10 18:45:48 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 10 Mar 2015 17:45:48 +0000
Subject: [issue11726] clarify that linecache only works on files that can be
 decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <1426009548.1.0.83647855899.issue11726@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

First attempt at describing this attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file38424/linecache-encoding-doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11726>
_______________________________________

From report at bugs.python.org  Tue Mar 10 18:51:57 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 10 Mar 2015 17:51:57 +0000
Subject: [issue23615] Reloading tokenize breaks tokenize.open()
In-Reply-To: <1425864069.02.0.403381374988.issue23615@psf.upfronthosting.co.za>
Message-ID: <1426009917.88.0.253027684676.issue23615@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

-B.patch as Serhiy suggests, for tokenize only for the time being.

----------
Added file: http://bugs.python.org/file38425/tokenize-reloadable-B.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23615>
_______________________________________

From report at bugs.python.org  Tue Mar 10 18:56:20 2015
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 10 Mar 2015 17:56:20 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1426010180.93.0.15554924252.issue23496@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan at bytereef.org>:


----------
nosy:  -skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Tue Mar 10 18:57:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 17:57:31 +0000
Subject: [issue23615] Reloading tokenize breaks tokenize.open()
In-Reply-To: <1425864069.02.0.403381374988.issue23615@psf.upfronthosting.co.za>
Message-ID: <1426010251.34.0.948539937639.issue23615@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. Do you want to write a patch for other cases Thomas?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23615>
_______________________________________

From report at bugs.python.org  Tue Mar 10 19:07:48 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 18:07:48 +0000
Subject: [issue19610] setup.py does not allow a tuple for classifiers
In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za>
Message-ID: <1426010868.74.0.925941571438.issue19610@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think it should include other list fields if we don't want to open separate issues for every list field.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19610>
_______________________________________

From report at bugs.python.org  Tue Mar 10 19:14:33 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 10 Mar 2015 18:14:33 +0000
Subject: [issue23615] Reloading tokenize breaks tokenize.open()
In-Reply-To: <1425864069.02.0.403381374988.issue23615@psf.upfronthosting.co.za>
Message-ID: <1426011273.66.0.499045361332.issue23615@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Fixed the other three cases you pointed out (-B2.patch).

----------
Added file: http://bugs.python.org/file38426/tokenize-reloadable-B2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23615>
_______________________________________

From report at bugs.python.org  Tue Mar 10 19:17:01 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Tue, 10 Mar 2015 18:17:01 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <1426011421.0.0.411382271751.issue15443@psf.upfronthosting.co.za>


Changes by Anand B Pillai <abpillai at gmail.com>:


----------
nosy: +pythonhacker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Tue Mar 10 19:18:41 2015
From: report at bugs.python.org (Sebastien Bourdeauducq)
Date: Tue, 10 Mar 2015 18:18:41 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
Message-ID: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>


New submission from Sebastien Bourdeauducq:

I would like to be able to bind asyncio TCP servers to an arbitrary list of hosts, not just either one host or all interfaces.

I propose that the host parameter of create_server and start_server can be a list of strings that describes each host. Sockets are created for the set of all addresses of all specified hosts. The list may also contain None, or the empty string, in which case all interfaces are assumed.

If a string or None is passed directly, the behavior is unchanged - so this should not break compatibility.

I can submit a patch if this feature is approved.

----------
components: asyncio
messages: 237791
nosy: gvanrossum, haypo, sebastien.bourdeauducq, yselivanov
priority: normal
severity: normal
status: open
title: support multiple hosts in create_server/start_server
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Tue Mar 10 19:19:26 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Tue, 10 Mar 2015 18:19:26 +0000
Subject: [issue21574] Port image types detections from PIL to the imghdr module
In-Reply-To: <1401010621.11.0.919611847501.issue21574@psf.upfronthosting.co.za>
Message-ID: <1426011566.77.0.728336221341.issue21574@psf.upfronthosting.co.za>


Changes by Anand B Pillai <abpillai at gmail.com>:


----------
nosy: +pythonhacker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21574>
_______________________________________

From report at bugs.python.org  Tue Mar 10 19:27:09 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 10 Mar 2015 18:27:09 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1426012029.04.0.242841937287.issue23630@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

This makes some sense, but it's easy to work around -- just call create_server() multiple times, once for each host. Why does that not work for you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Tue Mar 10 19:35:31 2015
From: report at bugs.python.org (Davin Potts)
Date: Tue, 10 Mar 2015 18:35:31 +0000
Subject: [issue21779] test_multiprocessing_spawn fails when ran with -Werror
In-Reply-To: <1402932904.12.0.0907209632693.issue21779@psf.upfronthosting.co.za>
Message-ID: <1426012531.99.0.493113240462.issue21779@psf.upfronthosting.co.za>


Davin Potts added the comment:

Attaching patch for both 3.4 and default/3.5 (single file works for both) which fixes the test to properly adjust for running under -Werror.


Whether -Werror is set or otherwise the equivalent of 'warnings.simplefilter("error", Warning)' has been set, any warnings will trigger messages being sent to stderr (that's good).  This problematic test, in particular, reassigns sys.stderr to point at a file in an attempt to capture exit codes from a Process into that file (that's okay); but any warning messages sent to stderr may also end up being captured inside that same file depending upon the timings of the threads involved (that's bad).  To support the established behavior inside multiprocessing for capturing non-int exit codes (see issue13854), the test has been made more robust to detect when it is being run with -Werror (or similar) and allow for extra messages potentially appearing on stderr, otherwise it will continue to use the existing test to validate the output seen on stderr (captured in that file).

In the suite of tests for multiprocessing, test_multiprocessing_spawn currently triggers a bunch of warnings due to differences in how spawn works versus fork -- one example of this common pattern:

    test_abort (test.test_multiprocessing_spawn.WithProcessesTestBarrier) ... Exception ignored in: <_io.FileIO name='/dev/null' mode='rb' closefd=True>
    ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='r' encoding='UTF-8'>

How to better handle the triggering of these warnings in the first place is left as a topic for consideration in the future.


This patch's updated test has been tested with and without "-Werror" against 3.4 and default/3.5 on OS X 10.10.

----------
keywords: +patch
Added file: http://bugs.python.org/file38427/issue_21779_py34_and_py35.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21779>
_______________________________________

From report at bugs.python.org  Tue Mar 10 19:37:45 2015
From: report at bugs.python.org (Davin Potts)
Date: Tue, 10 Mar 2015 18:37:45 +0000
Subject: [issue21779] test_multiprocessing_spawn fails when ran with -Werror
In-Reply-To: <1402932904.12.0.0907209632693.issue21779@psf.upfronthosting.co.za>
Message-ID: <1426012665.41.0.711809287838.issue21779@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21779>
_______________________________________

From report at bugs.python.org  Tue Mar 10 19:45:02 2015
From: report at bugs.python.org (Sebastien Bourdeauducq)
Date: Tue, 10 Mar 2015 18:45:02 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1426013102.2.0.617599457198.issue23630@psf.upfronthosting.co.za>


Sebastien Bourdeauducq added the comment:

That could work, but I would have to manually resolve and filter the lists of hostnames so that the program does not attempt to bind the same address twice - something that is better implemented in create_server, which already does the hostname resolution. Additionally, the asyncio Server internally supports listening on multiple sockets, and that would be the right feature to use for implementing this instead of creating and managing multiple servers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Tue Mar 10 19:46:55 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 10 Mar 2015 18:46:55 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1426013215.43.0.0466808385973.issue23630@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

So it sounds like you already have a patch in mind... Can you work on it and upload it? (It's open source -- you get to make it yourself. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Tue Mar 10 19:54:18 2015
From: report at bugs.python.org (Davin Potts)
Date: Tue, 10 Mar 2015 18:54:18 +0000
Subject: [issue7503] multiprocessing AuthenticationError "digest sent was
 rejected" when pickling proxy
In-Reply-To: <1260777234.55.0.247151929734.issue7503@psf.upfronthosting.co.za>
Message-ID: <1426013658.0.0.0244805729442.issue7503@psf.upfronthosting.co.za>


Davin Potts added the comment:

Per Richard's post from 1 year ago where he offers both explanation and an example, ultimately concluding that things are working as intended, and because there have been no objections or requests for clarification in the past year, closing this and marking it as not a bug.

----------
nosy: +davin
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7503>
_______________________________________

From report at bugs.python.org  Tue Mar 10 20:05:45 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 19:05:45 +0000
Subject: [issue21779] test_multiprocessing_spawn fails when ran with -Werror
In-Reply-To: <1402932904.12.0.0907209632693.issue21779@psf.upfronthosting.co.za>
Message-ID: <1426014345.54.0.212798411871.issue21779@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Wouldn't the test fail with -Werror::ResourceWarning or like?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21779>
_______________________________________

From report at bugs.python.org  Tue Mar 10 20:08:33 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 19:08:33 +0000
Subject: [issue23615] Reloading tokenize breaks tokenize.open()
In-Reply-To: <1425864069.02.0.403381374988.issue23615@psf.upfronthosting.co.za>
Message-ID: <1426014513.17.0.929559165524.issue23615@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23615>
_______________________________________

From report at bugs.python.org  Tue Mar 10 20:11:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 19:11:47 +0000
Subject: [issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal)
In-Reply-To: <1425810901.79.0.570490913636.issue23607@psf.upfronthosting.co.za>
Message-ID: <1426014707.94.0.733242934981.issue23607@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23607>
_______________________________________

From report at bugs.python.org  Tue Mar 10 20:18:39 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 19:18:39 +0000
Subject: [issue23629] Default __sizeof__ is wrong for var-sized objects
In-Reply-To: <1426002259.25.0.401694391435.issue23629@psf.upfronthosting.co.za>
Message-ID: <1426015119.32.0.568381597065.issue23629@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, tests for PyStructSequence types already exist (tests for sys.flags and sys.float_info).

The patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23629>
_______________________________________

From report at bugs.python.org  Tue Mar 10 20:20:57 2015
From: report at bugs.python.org (Sebastien Bourdeauducq)
Date: Tue, 10 Mar 2015 19:20:57 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1426015257.0.0.386717765877.issue23630@psf.upfronthosting.co.za>


Sebastien Bourdeauducq added the comment:

See attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file38428/asyncio_multibind.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Tue Mar 10 20:24:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 19:24:00 +0000
Subject: [issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal)
In-Reply-To: <1425810901.79.0.570490913636.issue23607@psf.upfronthosting.co.za>
Message-ID: <1426015440.85.0.771626248149.issue23607@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The fix for Python implementation LGTM, but a fix for C implementation is needed too.

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23607>
_______________________________________

From report at bugs.python.org  Tue Mar 10 20:26:57 2015
From: report at bugs.python.org (Davin Potts)
Date: Tue, 10 Mar 2015 19:26:57 +0000
Subject: [issue21779] test_multiprocessing_spawn fails when ran with -Werror
In-Reply-To: <1402932904.12.0.0907209632693.issue21779@psf.upfronthosting.co.za>
Message-ID: <1426015617.67.0.99980158514.issue21779@psf.upfronthosting.co.za>


Davin Potts added the comment:

Yes, setting -Werror::ResourceWarning would indeed cause the test to fail again.

A couple of options we could potentially adopt:
1. Decide to ignore anything extra in the file anytime any kind of "error" filterwarning is present.
2. Decide to ignore anything extra in the file anytime "-Werror" is used because that is arguably the dominant, most common scenario where this issue comes up.
3. Decide that certain kinds of -Werror::SomeParticularWarning are worth paying attention to and others are not.
4. Decide that the ResourceWarning from _io itself needs to be properly dealt with.

Of those options, I do not like #1 and I think #3 is a slippery slope to step onto -- this patch pragmatically offers us #2 with the potential to pursue #4 (which is ultimately where I think we want this to go).  I kind of like the thought of someone specifying -Werror::ResourceWarning and getting to see this test fail.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21779>
_______________________________________

From report at bugs.python.org  Tue Mar 10 20:28:35 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 10 Mar 2015 19:28:35 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426015257.0.0.386717765877.issue23630@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJNyQoH5azxhSC3-g5Ptkg_MuM_XhtnEo22ZZDQBxoH8g@mail.gmail.com>


Guido van Rossum added the comment:

Could use a test. Hopefully Victor can do a thorough review.

On Tue, Mar 10, 2015 at 12:20 PM, Sebastien Bourdeauducq <
report at bugs.python.org> wrote:

>
> Sebastien Bourdeauducq added the comment:
>
> See attached.
>
> ----------
> keywords: +patch
> Added file: http://bugs.python.org/file38428/asyncio_multibind.diff
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue23630>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Tue Mar 10 20:38:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 19:38:55 +0000
Subject: [issue23192] Generator return value ignored in lambda function
In-Reply-To: <1420728125.93.0.910147391239.issue23192@psf.upfronthosting.co.za>
Message-ID: <1426016335.88.0.0410426449546.issue23192@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please add a test based on Chris's example? And it would be good to add a test for a lambda with "yield from".

----------
assignee:  -> serhiy.storchaka
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23192>
_______________________________________

From report at bugs.python.org  Tue Mar 10 21:20:46 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Mar 2015 20:20:46 +0000
Subject: [issue22028] Python 3.4.1 Installer ended prematurely (Windows msi)
In-Reply-To: <1405994666.12.0.143457311308.issue22028@psf.upfronthosting.co.za>
Message-ID: <20150310202041.1318.53313@psf.io>


Roundup Robot added the comment:

New changeset 7c4c4e43c452 by Steve Dower in branch '2.7':
Issue #22028: Ensure mimetypes will not open registry keys with embedded nulls
https://hg.python.org/cpython/rev/7c4c4e43c452

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22028>
_______________________________________

From report at bugs.python.org  Tue Mar 10 21:21:00 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Mar 2015 20:21:00 +0000
Subject: [issue22028] Python 3.4.1 Installer ended prematurely (Windows msi)
In-Reply-To: <1405994666.12.0.143457311308.issue22028@psf.upfronthosting.co.za>
Message-ID: <20150310202059.1773.17093@psf.io>


Roundup Robot added the comment:

New changeset bf2016a1911f by Steve Dower in branch '3.4':
Issue #22028: Ensure mimetypes will not open registry keys with embedded nulls
https://hg.python.org/cpython/rev/bf2016a1911f

New changeset 6ccade563bf7 by Steve Dower in branch 'default':
Issue #22028: Ensure mimetypes will not open registry keys with embedded nulls
https://hg.python.org/cpython/rev/6ccade563bf7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22028>
_______________________________________

From report at bugs.python.org  Tue Mar 10 21:24:05 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 20:24:05 +0000
Subject: [issue18620] multiprocessing page leaves out important part of Pool
 example
In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za>
Message-ID: <1426019045.97.0.512232790017.issue18620@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +jnoller, sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18620>
_______________________________________

From report at bugs.python.org  Tue Mar 10 21:35:02 2015
From: report at bugs.python.org (mdcb)
Date: Tue, 10 Mar 2015 20:35:02 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <1426019702.92.0.739017865777.issue15443@psf.upfronthosting.co.za>


mdcb added the comment:

Intention of the patch was to keep it simple and limited to nanoseconds (per the report).

Throwing in Decimal would work (and possibly bring further precision) but consider:

datetime.fromnanoseconds(ns)

vs

datetime.fromtimestamp(Decimal(ts))

I find the former cleaner - sure, it adds a new class method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Tue Mar 10 22:05:29 2015
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 10 Mar 2015 21:05:29 +0000
Subject: [issue19909] Best practice docs for new SSL features
In-Reply-To: <1386335628.48.0.996074662164.issue19909@psf.upfronthosting.co.za>
Message-ID: <1426021529.72.0.0813882850934.issue19909@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I'm closing the reminder ticket. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19909>
_______________________________________

From report at bugs.python.org  Tue Mar 10 22:14:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 21:14:14 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <1426022054.46.0.696648947505.issue15443@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Pickling is not backward compatible. I.e. older versions of Python couldn't unpickle datetime pickled in new Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Tue Mar 10 22:25:28 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 Mar 2015 21:25:28 +0000
Subject: [issue23631] 3.5 (a2) traceback regression snarls Idle
Message-ID: <1426022728.67.0.0261421184633.issue23631@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

3.5.0a2, my Win 7 and Guido's new Win laptop: error tracebacks are mangled in a way that makes Idle severely less functional, hence 'release blocker'.  First, the normal behavior.

Python 3.5.0a2 (v3.5.0a2:0337bd7ebcb6+, Mar  9 2015, 10:29:45) [MSC v.1900 64 bi
t (AMD64)] on win32
>>> 1/0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: division by zero

Idle 3.4.3 and previous give same, with the helpful addition of the code line ('1/0'), as in batch mode tracebacks, since it uses the traceback module.  But Idle 3.5.0a2 started from the installed icon gives

>>> 1/0
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 353, in runcode
    exec(code, self.locals)
  File "<pyshell#1>", line 1, in <module>
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 126, in main
    ret = method(*args, **kwargs)
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 365, in runcode
    print_exception()
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 216, in print_exception
    print_exc(typ, val, tb)
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 211, in print_exc
    traceback.print_list(tbe, file=efile)
  File "C:\Program Files\Python 3.5\lib\traceback.py", line 22, in print_list
    for item in StackSummary.from_list(extracted_list).format():
  File "C:\Program Files\Python 3.5\lib\traceback.py", line 370, in format
    frame.filename, frame.lineno, frame.name))
AttributeError: 'tuple' object has no attribute 'filename'

>>> ================================ RESTART ================================
>>> 


run.py (as should be more or less everything in idlelib) is identical in 3.4 and 3.5.  Idle started from a command line (py -3 -m idlelib) gives an even worse result.  The Idle Shell just shows

>>> 1/0
Traceback (most recent call last):
Traceback (most recent call last):

>>> ================================ RESTART ================================
>>> 


while the following appears in the command window (Command Prompt or PowerShell).

Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 353, in runcode
    exec(code, self.locals)
  File "<pyshell#0>", line 1, in <module>
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 126, in main
    ret = method(*args, **kwargs)
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 365, in runcode
    print_exception()
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 216, in print_exception
    print_exc(typ, val, tb)
  File "C:\Program Files\Python 3.5\lib\idlelib\run.py", line 211, in print_exc
    traceback.print_list(tbe, file=efile)
  File "C:\Program Files\Python 3.5\lib\traceback.py", line 22, in print_list
    for item in StackSummary.from_list(extracted_list).format():
  File "C:\Program Files\Python 3.5\lib\traceback.py", line 370, in format
    frame.filename, frame.lineno, frame.name))
AttributeError: 'tuple' object has no attribute 'filename'
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\idlelib\rpc.py", line 359, in pollpacket
    s = self.sock.recv(BUFSIZE)
ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the r

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\idlelib\rpc.py", line 432, in pollresponse
    message = self.pollmessage(wait)
  File "C:\Program Files\Python 3.5\lib\idlelib\rpc.py", line 384, in pollmessage
    packet = self.pollpacket(wait)
  File "C:\Program Files\Python 3.5\lib\idlelib\rpc.py", line 361, in pollpacket
    raise EOFError
EOFError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\idlelib\PyShell.py", line 565, in poll_subprocess
    response = clt.pollresponse(self.active_seq, wait=0.05)
  File "C:\Program Files\Python 3.5\lib\idlelib\rpc.py", line 436, in pollresponse
    self.handle_EOF()
  File "C:\Program Files\Python 3.5\lib\idlelib\PyShell.py", line 383, in handle_EOF
    raise EOFError
EOFError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
ValueError: invalid literal for int() with base 10: '??'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Program Files\Python 3.5\lib\tkinter\__init__.py", line 1534, in __call__
    args = self.subst(*args)
  File "C:\Program Files\Python 3.5\lib\tkinter\__init__.py", line 1252, in _substitute
    e.num = getint_event(b)
  File "C:\Program Files\Python 3.5\lib\tkinter\__init__.py", line 1231, in getint_event
    return int(s)
SystemError: result with error in PyObject_Call


This needs to be checked on another OS, but the traceback problem does not strike me as Windows-specific.

----------
keywords: 3.3regression
messages: 237810
nosy: georg.brandl, larry, ncoghlan, terry.reedy
priority: release blocker
severity: normal
stage: needs patch
status: open
title: 3.5 (a2) traceback regression snarls Idle
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23631>
_______________________________________

From report at bugs.python.org  Tue Mar 10 22:37:43 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Mar 2015 21:37:43 +0000
Subject: [issue23629] Default __sizeof__ is wrong for var-sized objects
In-Reply-To: <1426002259.25.0.401694391435.issue23629@psf.upfronthosting.co.za>
Message-ID: <20150310213739.1178.21231@psf.io>


Roundup Robot added the comment:

New changeset f9afa4f87570 by Antoine Pitrou in branch '3.4':
Issue #23629: Fix the default __sizeof__ implementation for variable-sized objects.
https://hg.python.org/cpython/rev/f9afa4f87570

New changeset 9994e0172a0c by Antoine Pitrou in branch 'default':
Issue #23629: Fix the default __sizeof__ implementation for variable-sized objects.
https://hg.python.org/cpython/rev/9994e0172a0c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23629>
_______________________________________

From report at bugs.python.org  Tue Mar 10 22:38:24 2015
From: report at bugs.python.org (Neil Girdhar)
Date: Tue, 10 Mar 2015 21:38:24 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1426023504.11.0.618165268919.issue2292@psf.upfronthosting.co.za>


Changes by Neil Girdhar <mistersheik at gmail.com>:


Added file: http://bugs.python.org/file38429/starunpack37.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Tue Mar 10 22:41:30 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Mar 2015 21:41:30 +0000
Subject: [issue23629] Default __sizeof__ is wrong for var-sized objects
In-Reply-To: <1426002259.25.0.401694391435.issue23629@psf.upfronthosting.co.za>
Message-ID: <20150310214127.7565.6428@psf.io>


Roundup Robot added the comment:

New changeset dbd48b22b477 by Antoine Pitrou in branch '2.7':
Issue #23629: Fix the default __sizeof__ implementation for variable-sized objects.
https://hg.python.org/cpython/rev/dbd48b22b477

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23629>
_______________________________________

From report at bugs.python.org  Tue Mar 10 22:41:45 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Mar 2015 21:41:45 +0000
Subject: [issue23629] Default __sizeof__ is wrong for var-sized objects
In-Reply-To: <1426002259.25.0.401694391435.issue23629@psf.upfronthosting.co.za>
Message-ID: <1426023705.27.0.0988707889969.issue23629@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Good, committed.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23629>
_______________________________________

From report at bugs.python.org  Tue Mar 10 22:46:41 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Mar 2015 21:46:41 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
Message-ID: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

It is a bit of pity. A least non-sliced indexing should be able to work:

>>> import numpy as np
>>> a = np.arange(10)
>>> memoryview(a)[0]
0
>>> a = np.arange(10).reshape((2,5))
>>> a[0,1]
1
>>> memoryview(a)[0,1]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: memoryview: invalid slice key

----------
messages: 237814
nosy: pitrou, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: memoryview doesn't allow tuple-indexing
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Tue Mar 10 23:04:54 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 10 Mar 2015 22:04:54 +0000
Subject: [issue23486] Enum member lookup is 20x slower than normal class
 attribute lookup
In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za>
Message-ID: <1426025094.91.0.769262252535.issue23486@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Larry, I have a very small patch (~4 lines) that does change user behavior or the API, but does have a significant performance boost.

I'm still learning what is/is not okay to add to maintenance releases, so wanted to run this by you.

----------
assignee:  -> ethan.furman
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23486>
_______________________________________

From report at bugs.python.org  Tue Mar 10 23:06:10 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 10 Mar 2015 22:06:10 +0000
Subject: [issue23486] Enum member lookup is 20x slower than normal class
 attribute lookup
In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za>
Message-ID: <1426025170.81.0.725746148118.issue23486@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Larry, I have a very small patch (~4 lines) that does change user behavior or the API, but does have a significant performance boost.

I'm still learning what is/is not okay to add to maintenance releases, so wanted to run this by you.

----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23486>
_______________________________________

From report at bugs.python.org  Tue Mar 10 23:07:02 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 10 Mar 2015 22:07:02 +0000
Subject: [issue23486] Enum member lookup is 20x slower than normal class
 attribute lookup
In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za>
Message-ID: <1426025222.09.0.0998935553027.issue23486@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
Removed message: http://bugs.python.org/msg237815

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23486>
_______________________________________

From report at bugs.python.org  Tue Mar 10 23:31:54 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 Mar 2015 22:31:54 +0000
Subject: [issue23633] Improve py launcher help, index, and doc
Message-ID: <1426026714.29.0.122233634927.issue23633@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

This issue is about making coordinated changes to the py launcher doc and binary.

1. The py launcher doc is https://docs.python.org/3/using/windows.html#python-launcher-for-windows.  If one does not know where to look, it is hard to find.  Add an index entry 'py launcher' pointing here.

2. py -h lists 'launcher arguments' but does not explain the default if none is given and how to change the default.  There is way too much to say in a -h response, so I suggest just adding a reference to the doc plus the directories searched for .ini files 

See https://docs.python.org/3/using/windows.html#python-launcher-for-windows for information on the default version and how to change it with a py.ini file.  This executable looks for py.ini in <user app directory> and <py.exe install directory>. 

3. 3.4.4.1. Customization via INI files starts "Two .ini files will be searched by the launcher - py.ini in the current user?s ?application data? directory (i.e. the directory returned by calling the Windows function SHGetFolderPath with CSIDL_LOCAL_APPDATA) and py.ini in the same directory as the launcher."  Add "These directories are listed as part of the output of 'py -h'.  Also add "Adding or editing a file in an all-users install directory requires logging in with an administrator account."

4. In my experience, a new install of py.exe wipes out an existing py.ini along with the py(w).exe files.  'del py.*'?  If this is intended, it should be documented.  If not (and it is a nuisance having the default reverted back to py 2), it should not happen (separate issue?).


Nick, I don't know who currently maintains py.exe, but presume you do.

----------
messages: 237817
nosy: ncoghlan, steve.dower, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Improve py launcher help, index, and doc
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23633>
_______________________________________

From report at bugs.python.org  Tue Mar 10 23:34:20 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 10 Mar 2015 22:34:20 +0000
Subject: [issue23631] 3.5 (a2) traceback regression snarls Idle
In-Reply-To: <1426022728.67.0.0261421184633.issue23631@psf.upfronthosting.co.za>
Message-ID: <1426026860.74.0.890019551612.issue23631@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23631>
_______________________________________

From report at bugs.python.org  Tue Mar 10 23:41:49 2015
From: report at bugs.python.org (mattip)
Date: Tue, 10 Mar 2015 22:41:49 +0000
Subject: [issue23634] os.fdopen reopening a read-only fd on windows
Message-ID: <1426027309.83.0.475753794617.issue23634@psf.upfronthosting.co.za>


New submission from mattip:

If I have a read-only fd, and I try to open it as 'w' with 

os.fdopen(fd, 'w'), 

the operation raises on linux but succeeds on windows. Python relies on the underlying clib's fdopen to return an error, which glibc does, but MSVC happily closes the original fd and returns with no error.

Would a patch to fix this be welcomed? A test demonstrating the issue is attached. The fix would be to check that the mode requested matches the mode of the argument fd.

Related issues #22259 and #21191 did not consider this case

----------
components: Windows
files: test_openfd.py
messages: 237818
nosy: mattip, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.fdopen reopening a read-only fd on windows
Added file: http://bugs.python.org/file38430/test_openfd.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23634>
_______________________________________

From report at bugs.python.org  Tue Mar 10 23:43:20 2015
From: report at bugs.python.org (mdcb)
Date: Tue, 10 Mar 2015 22:43:20 +0000
Subject: [issue15443] datetime module has no support for nanoseconds
In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za>
Message-ID: <1426027400.88.0.392562213408.issue15443@psf.upfronthosting.co.za>


mdcb added the comment:

backward compatibility is implemented as 'new python can load old pickle'. isn't it what backward compatible means?

The payload changed from 10 to 12 bytes to accomodate the nanoseconds, I don't know how to handle reverse-backward compatibility or if it's really needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15443>
_______________________________________

From report at bugs.python.org  Tue Mar 10 23:43:29 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 10 Mar 2015 22:43:29 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <1426027409.95.0.874897548389.issue23632@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file38431/memoryview_tuple_indexing.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Tue Mar 10 23:44:01 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 Mar 2015 22:44:01 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1426027441.83.0.522598884295.issue23546@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thanks for the link to where the doc *was* updated for 2.7.  Currently, -m idlelib.idle works, so copying idle.py to __main__.py should make -m idlelib work.  I will try this later, and see if the exact contents of idle.py are needed.  Having '-m idlelib' work uniformly would be nice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Tue Mar 10 23:55:33 2015
From: report at bugs.python.org (David Linke)
Date: Tue, 10 Mar 2015 22:55:33 +0000
Subject: [issue23623] Python 3.5 docs need to clarify how to set PATH, etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1426028133.23.0.68349101026.issue23623@psf.upfronthosting.co.za>


David Linke added the comment:

Besides clarifying documentation, it may be helpful to provide a script that (temporarily) sets the path to pythonX and pythonX/scripts. A batch cmd script that does that and also changes the default Python for the launcher is here: https://gist.github.com/dalito/8356483ac2ffb2b8b468
The Python version is specified just like for the launcher: "pypath -3.4" temporarily sets the path for Python34 and Python34/scripts and "pypath" restores the previous state. The script uses the launcher to get the location of the specified Python version.

I think some of the problem above could be mitigated by including such cmd/powershell script(s).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23623>
_______________________________________

From report at bugs.python.org  Wed Mar 11 00:02:02 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 10 Mar 2015 23:02:02 +0000
Subject: [issue23623] Python 3.5 docs need to clarify how to set PATH, etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1426028522.34.0.927580612003.issue23623@psf.upfronthosting.co.za>


Paul Moore added the comment:

Steve has something like that planned, I believe. It's been discussed a couple of times on python-dev

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23623>
_______________________________________

From report at bugs.python.org  Wed Mar 11 00:24:30 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 10 Mar 2015 23:24:30 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426029870.0.0.310243076808.issue2211@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Latest patch should address all comments.

----------
Added file: http://bugs.python.org/file38432/issue2211_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Wed Mar 11 00:35:40 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 10 Mar 2015 23:35:40 +0000
Subject: [issue23634] os.fdopen reopening a read-only fd on windows
In-Reply-To: <1426027309.83.0.475753794617.issue23634@psf.upfronthosting.co.za>
Message-ID: <1426030540.01.0.328991557447.issue23634@psf.upfronthosting.co.za>


Martin Panter added the comment:

I guess you were mainly testing with Python 2. Python 3 on Linux does not raise any error either:

wrote 3 to a read-only file
should raise, opening a ro descriptor for writing
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

BTW in your test script you close the underlying file descriptor ?fd? before giving the file object ?fd2? a chance to flush or close, which is probably why you see no error. Though in Wine I see this, probably because file.write() does not return a value in Python 2:

properly raised TypeError('%d format: a number is required, not NoneType',)

What would be the reason for doing a mode check in fdopen()? Just to detect programmer errors if the wrong mode or file descriptor is given?

----------
components: +IO
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23634>
_______________________________________

From report at bugs.python.org  Wed Mar 11 01:07:02 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Mar 2015 00:07:02 +0000
Subject: [issue21610] load_module not closing opened files
In-Reply-To: <1401397842.84.0.0447434593999.issue21610@psf.upfronthosting.co.za>
Message-ID: <20150311000658.11193.5208@psf.io>


Roundup Robot added the comment:

New changeset 5a5d4073d46a by Benjamin Peterson in branch '2.7':
close files explicit (closes #21610)
https://hg.python.org/cpython/rev/5a5d4073d46a

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21610>
_______________________________________

From report at bugs.python.org  Wed Mar 11 01:15:00 2015
From: report at bugs.python.org (Alex Zhang)
Date: Wed, 11 Mar 2015 00:15:00 +0000
Subject: [issue23635] Python won't install correctly.
Message-ID: <1426032900.09.0.644989151138.issue23635@psf.upfronthosting.co.za>


New submission from Alex Zhang:

Currently can't install 343 on my computer. I had 342 installed, and wanted to uninstall that for 343. Afterwards, being the idiot that I was, I deleted the files in the Python34 folder. Uninstalling gives me an error.  

There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support or package vendor.

I currently have python 342 on my computer which I am unable to uninstall since it is missing the files.

----------
components: Installation, Windows
messages: 237827
nosy: Player72, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python won't install correctly.
type: crash
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23635>
_______________________________________

From report at bugs.python.org  Wed Mar 11 01:23:54 2015
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 11 Mar 2015 00:23:54 +0000
Subject: [issue22928] HTTP header injection in
 urrlib2/urllib/httplib/http.client
In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za>
Message-ID: <1426033434.93.0.538753890977.issue22928@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Latest patch should now address all comments.

----------
Added file: http://bugs.python.org/file38433/issue22928_5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22928>
_______________________________________

From report at bugs.python.org  Wed Mar 11 01:37:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 11 Mar 2015 00:37:55 +0000
Subject: [issue19771] runpy should check ImportError.name before wrapping it
In-Reply-To: <1385383187.11.0.803942496087.issue19771@psf.upfronthosting.co.za>
Message-ID: <1426034275.95.0.944656620976.issue19771@psf.upfronthosting.co.za>


Martin Panter added the comment:

Closely related: Issue 14285, where an ImportError and various other exceptions caused by code in __init__.py are also incorrectly caught, trigger unexpected error messages, with no traceback being reported.

Not sure if checking the ?name? attribute will help in even all of the most common cases, but it should be better than nothing. Another idea I had was checking if a module was inserted into sys.modules.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19771>
_______________________________________

From report at bugs.python.org  Wed Mar 11 01:40:01 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 11 Mar 2015 00:40:01 +0000
Subject: [issue14285] Traceback wrong on ImportError while executing a package
In-Reply-To: <1331621436.28.0.000669565075438.issue14285@psf.upfronthosting.co.za>
Message-ID: <1426034401.38.0.137809231987.issue14285@psf.upfronthosting.co.za>


Martin Panter added the comment:

Closely related: Issue 19771, which seems to be complaining about a the error message when __main__.py generates an ImportError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14285>
_______________________________________

From report at bugs.python.org  Wed Mar 11 01:49:52 2015
From: report at bugs.python.org (Anthony Ryan)
Date: Wed, 11 Mar 2015 00:49:52 +0000
Subject: [issue23636] Add scgi to urllib.parse.uses_netloc
Message-ID: <1426034992.56.0.954148874592.issue23636@psf.upfronthosting.co.za>


New submission from Anthony Ryan:

The scgi protocol is not included in urllib.parse.uses_netloc list, while other less common protocols are (such as gopher).

I would like to see scgi get added to this list.

----------
components: Library (Lib)
files: py3bug
messages: 237831
nosy: Anthony Ryan
priority: normal
severity: normal
status: open
title: Add scgi to urllib.parse.uses_netloc
type: behavior
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file38434/py3bug

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23636>
_______________________________________

From report at bugs.python.org  Wed Mar 11 01:50:18 2015
From: report at bugs.python.org (Anthony Ryan)
Date: Wed, 11 Mar 2015 00:50:18 +0000
Subject: [issue23636] Add scgi to urllib.parse.uses_netloc
In-Reply-To: <1426034992.56.0.954148874592.issue23636@psf.upfronthosting.co.za>
Message-ID: <1426035018.31.0.250529509969.issue23636@psf.upfronthosting.co.za>


Changes by Anthony Ryan <anthonyryan1 at gmail.com>:


Added file: http://bugs.python.org/file38435/py2bug

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23636>
_______________________________________

From report at bugs.python.org  Wed Mar 11 02:05:25 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 11 Mar 2015 01:05:25 +0000
Subject: [issue22928] HTTP header injection in
 urrlib2/urllib/httplib/http.client
In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za>
Message-ID: <1426035925.9.0.64094325553.issue22928@psf.upfronthosting.co.za>


Martin Panter added the comment:

I much prefer the new patch with better compatibility and flexibility :)

If you want to strengthen the tests to reflect some of the decisions made here you could add the following tests:

Positive tests:
* putheader('C1-Control', b'next\x85line')
* putheader('Embedded-Fold', 'is\r\n\tallowed')

Negative tests:
* putheader(' Leading-Space', 'value')
* putheader('Embedded: colon', 'extra value')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22928>
_______________________________________

From report at bugs.python.org  Wed Mar 11 02:46:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 11 Mar 2015 01:46:49 +0000
Subject: [issue1722348] urlparse.urlunparse forms file urls incorrectly
Message-ID: <1426038409.63.0.340248599579.issue1722348@psf.upfronthosting.co.za>


Martin Panter added the comment:

I believe this was closed incorrectly. The original test case includes four slashes, not three, and still fails in 3.5. However Issue 23505 has been opened in the mean time which should cover this.

----------
nosy: +vadmium
resolution: works for me -> duplicate
superseder:  -> Urlparse insufficient validation leads to open redirect

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722348>
_______________________________________

From report at bugs.python.org  Wed Mar 11 03:02:09 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 11 Mar 2015 02:02:09 +0000
Subject: [issue23635] Python won't install correctly.
In-Reply-To: <1426032900.09.0.644989151138.issue23635@psf.upfronthosting.co.za>
Message-ID: <1426039329.29.0.678523278858.issue23635@psf.upfronthosting.co.za>


Steve Dower added the comment:

(This doesn't affect 3.5)

My guess is the missing ensurepip module is the problem. See if you can Repair the original install and then remove it.

----------
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23635>
_______________________________________

From report at bugs.python.org  Wed Mar 11 03:03:19 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 11 Mar 2015 02:03:19 +0000
Subject: [issue23623] Python 3.5 docs need to clarify how to set PATH, etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1426039399.6.0.538086282313.issue23623@psf.upfronthosting.co.za>


Steve Dower added the comment:

"Planned" is a bit strong - in need of some simultaneous time and motivation :) Thanks for the upvote.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23623>
_______________________________________

From report at bugs.python.org  Wed Mar 11 03:05:26 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 11 Mar 2015 02:05:26 +0000
Subject: [issue23631] 3.5 (a2) traceback regression snarls Idle
In-Reply-To: <1426022728.67.0.0261421184633.issue23631@psf.upfronthosting.co.za>
Message-ID: <1426039526.6.0.298310940913.issue23631@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Yeah, the stack track makes me suspect http://bugs.python.org/issue17911

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23631>
_______________________________________

From report at bugs.python.org  Wed Mar 11 03:12:44 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 11 Mar 2015 02:12:44 +0000
Subject: [issue23636] Add scgi to urllib.parse.uses_netloc
In-Reply-To: <1426034992.56.0.954148874592.issue23636@psf.upfronthosting.co.za>
Message-ID: <1426039964.72.0.489132088656.issue23636@psf.upfronthosting.co.za>


Martin Panter added the comment:

See also Issue 16134 for adding RTMP schemes to the registry. However, I wonder if it is time for a more general fix, rather than having an arms race with whatever URL scheme someone dreams up next.

According to Issue 7904, urlsplit() etc intentially support parsing the //netloc part for arbitrary URL schemes. However when putting it back together, the urlunsplit() etc functions currently cannot assume it is okay to insert an empty netloc ?//?, probably because it would break URLs like tel:+1234 or mailto:somebody at example.net.

There are a bunch of URL-parsing issues floating around which may be able to come together to solve each other:

* Issue 8339: Round trip stripping empty netloc, apparently closed because the URLs were thought to be invalid (thought I disagree)
* Issue 15009: Round trip strips empty netloc for yelp:///foo
* Issue 23505: Round trip stripping netloc considered a security issue
* Issue 5843: Round trip stripping empty query and fragment strings
* Issue 22852: Round trip strips empty fragment

In Issue 22852, I proposed adding a series of has_netloc/query/fragment flags to the SplitResult etc classes. If that was implemented, we would not have to worry about whitelisting ?scgi:? or other schemes in ?uses_netloc?. Instead, urlsplit() would automatically set SplitResult(has_netloc=True), and urlunsplit() would know to restore the empty ?//? netloc string.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23636>
_______________________________________

From report at bugs.python.org  Wed Mar 11 03:29:43 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 11 Mar 2015 02:29:43 +0000
Subject: [issue23633] Improve py launcher help, index, and doc
In-Reply-To: <1426026714.29.0.122233634927.issue23633@psf.upfronthosting.co.za>
Message-ID: <1426040983.5.0.887977062067.issue23633@psf.upfronthosting.co.za>


Steve Dower added the comment:

For point 4, there's no code in either the 3.5 or the 3.4 (AFAIK) installer that would remove a py.ini file. From 3.5 onwards the py(w).exe files will be properly refcounted so the latest version is always installed regardless of order (i.e. 3.6 will update 3.5's but 3.5 won't downgrade 3.6). It isn't possible to make this backwards compatible with 3.4 at this stage, though we *might* be able to make it backwards compatible with 3.4.4.

I think I'm the only one who's made changes to launcher.c recently (apart from Paul Moore's patch, which I reviewed and applied). Not that I want to be nominated as a maintainer for it :)

"py.exe -h" never seems that useful to me, but that's mainly because the help from python.exe takes up a full screen and hides the rest. I'm not sure that providing the ini paths here would help, since that doesn't tell you what you can set, but having a link to the docs would be fine.

I have no problems at all with adding more details to the docs. When I refreshed the rest of that page I didn't really touch the launcher section IIRC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23633>
_______________________________________

From report at bugs.python.org  Wed Mar 11 04:46:54 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 Mar 2015 03:46:54 +0000
Subject: [issue23633] Improve py launcher help, index, and doc
In-Reply-To: <1426026714.29.0.122233634927.issue23633@psf.upfronthosting.co.za>
Message-ID: <1426045614.48.0.0306291398209.issue23633@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The faulty patch for #17911 is a possible, perhaps probably cause (Guido, email).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23633>
_______________________________________

From report at bugs.python.org  Wed Mar 11 04:57:20 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 Mar 2015 03:57:20 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1426046240.42.0.127559657754.issue17911@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Idle is partially disabled in a2 (#23633), with symptoms similar to that of the first example in msg237230.  Trivial test: open Idle Shell, enter '1/0'.  If this is not fixed before .a3, I think it should be reverted until it is.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17911>
_______________________________________

From report at bugs.python.org  Wed Mar 11 04:59:14 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 Mar 2015 03:59:14 +0000
Subject: [issue23633] Improve py launcher help, index, and doc
In-Reply-To: <1426026714.29.0.122233634927.issue23633@psf.upfronthosting.co.za>
Message-ID: <1426046354.26.0.396099655256.issue23633@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: http://bugs.python.org/msg237839

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23633>
_______________________________________

From report at bugs.python.org  Wed Mar 11 05:09:03 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 Mar 2015 04:09:03 +0000
Subject: [issue23633] Improve py launcher help, index, and doc
In-Reply-To: <1426026714.29.0.122233634927.issue23633@psf.upfronthosting.co.za>
Message-ID: <1426046943.49.0.894179183776.issue23633@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

(Whoops, unlinked misplaced message.)

I will add py.ini *again* and watch more carefully before and after further installs.

The problem with the doc is that it does not say where the py.ini file should go, and it inherently cannot because the locations are not independent of the user, install type, and windows version.  (For user installs, my understanding is that the install is in a hidden file that most users will not even know how to access.)  To me, the reference to the windows internal function is worse than useless and should perhaps be removed.

I use py -h to remind whether I need -3.5 or -35.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23633>
_______________________________________

From report at bugs.python.org  Wed Mar 11 05:10:45 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 Mar 2015 04:10:45 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1426047045.71.0.82155835144.issue17911@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: http://bugs.python.org/msg237840

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17911>
_______________________________________

From report at bugs.python.org  Wed Mar 11 05:11:37 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 Mar 2015 04:11:37 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1426047097.93.0.656272337239.issue17911@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

(correct new issue #) Idle is partially disabled in a2 (#23631), with symptoms similar to that of the first example in msg237230.  Trivial test: open Idle Shell, enter '1/0'.  If this is not fixed before .a3, I think it should be reverted until it is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17911>
_______________________________________

From report at bugs.python.org  Wed Mar 11 05:16:12 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 11 Mar 2015 04:16:12 +0000
Subject: [issue23636] Add scgi to urllib.parse.uses_netloc
In-Reply-To: <1426034992.56.0.954148874592.issue23636@psf.upfronthosting.co.za>
Message-ID: <1426047372.34.0.104178795495.issue23636@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23636>
_______________________________________

From report at bugs.python.org  Wed Mar 11 05:19:48 2015
From: report at bugs.python.org (Wei Wu)
Date: Wed, 11 Mar 2015 04:19:48 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>
Message-ID: <1426047588.9.0.904781004667.issue23566@psf.upfronthosting.co.za>


Wei Wu added the comment:

@haypo: Thank you for your review. I attached an updated patch addressing the review comments. In addition, I also added a change note in Misc/NEWS.

----------
Added file: http://bugs.python.org/file38436/issue23566_update.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23566>
_______________________________________

From report at bugs.python.org  Wed Mar 11 06:35:00 2015
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 11 Mar 2015 05:35:00 +0000
Subject: [issue23486] Enum member lookup is 20x slower than normal class
 attribute lookup
In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za>
Message-ID: <1426052100.6.0.526428675878.issue23486@psf.upfronthosting.co.za>


Larry Hastings added the comment:

My inclination is 3.5 only.  Barry, do you want to argue for this going into 3.4?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23486>
_______________________________________

From report at bugs.python.org  Wed Mar 11 07:13:01 2015
From: report at bugs.python.org (eryksun)
Date: Wed, 11 Mar 2015 06:13:01 +0000
Subject: [issue23634] os.fdopen reopening a read-only fd on windows
In-Reply-To: <1426027309.83.0.475753794617.issue23634@psf.upfronthosting.co.za>
Message-ID: <1426054381.19.0.15089806881.issue23634@psf.upfronthosting.co.za>


eryksun added the comment:

> I guess you were mainly testing with Python 2. Python 3 on Linux 
> does not raise any error either

In Python 3 os.fdopen delegates to io.open, which calls io.FileIO to create the raw file object. This doesn't verify a compatible mode on the file descriptor. Similarly, in Windows Python 2 os.fdopen calls VC++ _fdopen, which also doesn't verify a compatible mode. 

The POSIX spec (IEEE Std 1003.1, 2013 Edition) for fdopen says that "the *application* shall ensure that the mode of the stream as expressed by the mode argument is allowed by the file access mode of the open file description to which fildes refers" [1] (emphasis mine).  It happens that glibc in Linux opts to do this check for you.

If instead of closing the underlying file descriptor the program opts to close the Python file object or C FILE stream, this will attempt to write the buffered string "bbb" to the read-only fd, which should raise an EBADF error. 

[1]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/fdopen.html

---

The way test_openfd.py directly closes the underlying file descriptor does highlight an annoying problem in Python 2 on Windows. This should get its own issue in case someone feels like addressing it. The problem is open() and os.fdopen() create the file object with fclose as the FILE stream closer. It'd be nicer to instead use a closer on Windows that first calls _PyVerify_fd to check for a valid file descriptor. Otherwise the CRT asserts and terminates the process. For example:

    import os
    f = open('@test')
    os.close(f.fileno())

Functions in posixmodule.c are good about first verifying the file descriptor:

    >>> os.lseek(f.fileno(), 0, os.SEEK_CUR) # calls _PyVerify_fd
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OSError: [Errno 9] Bad file descriptor

OTOH, closing the file object doesn't verify the file descriptor:

    >>> f.close() # Goodbye cruel world... :'(

Stack trace:

    0:000> k 8
    Child-SP          RetAddr           Call Site
    00000000`0021f3a8 00000000`68e25200 kernel32!TerminateProcessStub
    00000000`0021f3b0 00000000`68e252d4 MSVCR90!invoke_watson+0x11c
    00000000`0021f9a0 00000000`68e1de7e MSVCR90!invalid_parameter+0x70
    00000000`0021f9e0 00000000`68ddf904 MSVCR90!close+0x9e
    00000000`0021fa30 00000000`68ddf997 MSVCR90!fclose_nolock+0x5c
    00000000`0021fa70 00000000`1e0ac2e5 MSVCR90!fclose+0x5f
    00000000`0021fab0 00000000`1e0ac7b2 python27!close_the_file+0xa5
    00000000`0021fae0 00000000`1e114427 python27!file_close+0x12

The problem doesn't exist in Python 3, for which io.FileIO's internal_close function is gated by _PyVerify_fd.

----------
nosy: +eryksun
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23634>
_______________________________________

From report at bugs.python.org  Wed Mar 11 07:17:24 2015
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 11 Mar 2015 06:17:24 +0000
Subject: [issue23486] Enum member lookup is 20x slower than normal class
 attribute lookup
In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za>
Message-ID: <1426054644.28.0.997543037403.issue23486@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Argh, sorry -- that was supposed to be *does not* change user behavior nor the API, it's *just* a performance increase.

Does that change your inclination?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23486>
_______________________________________

From report at bugs.python.org  Wed Mar 11 08:30:02 2015
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 11 Mar 2015 07:30:02 +0000
Subject: [issue23486] Enum member lookup is 20x slower than normal class
 attribute lookup
In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za>
Message-ID: <1426059002.49.0.753025201611.issue23486@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Oh, I read the code.  But it's a performance hack, and the rules say we only accept security fixes and bug fixes at this stage of the release, and they're the rules for good reasons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23486>
_______________________________________

From report at bugs.python.org  Wed Mar 11 09:13:02 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 11 Mar 2015 08:13:02 +0000
Subject: [issue19771] runpy should check ImportError.name before wrapping it
In-Reply-To: <1385383187.11.0.803942496087.issue19771@psf.upfronthosting.co.za>
Message-ID: <1426061582.32.0.380862106193.issue19771@psf.upfronthosting.co.za>


Martin Panter added the comment:

Posting a new patch with the following changes:

* Added Poleto?s original tests, updated according to review comments. Combined the flag and source code string parameters.

* Used a different approach to guessing where the offending ImportError came from. Now it checks if the module got added to sys.modules, which seems to work in all cases I tried. It no longer does what the bug title says (check ImportError.name), but I think it is a better workaround or fix for the underlying problem.

* Removed Poleto?s ?Error executing package . . .? ImportError wrapper. We already know what package we are trying to execute, and it hasn?t actually been ?executed? yet, because __init__.py failed.

* Cleaned up exception name in the ?Error while finding spec? message

----------
Added file: http://bugs.python.org/file38437/issue_19771_runpy.patch.v3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19771>
_______________________________________

From report at bugs.python.org  Wed Mar 11 09:30:58 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 11 Mar 2015 08:30:58 +0000
Subject: [issue14285] Traceback wrong on ImportError while executing a package
In-Reply-To: <1331621436.28.0.000669565075438.issue14285@psf.upfronthosting.co.za>
Message-ID: <1426062658.25.0.831652576182.issue14285@psf.upfronthosting.co.za>


Martin Panter added the comment:

The patches at Issue 19771 should remove the part of the message that incorrectly says ?. . . is a package and cannot be directly executed?. However that still leaves the problem of the suppressed traceback.

I am posting runpy-traceback.patch here which adds some tests to check if the traceback is suppressed. The offending test is marked @expectedFailure. It also points out where the exception is being incorrectly caught, but I haven?t thought of a nice way to fix the problem.

Other changes in the runpy-traceback.patch:

* Removed the exception message rewriting in _run_module_as_main(), because it seems to be redundant with the _get_main_module_details() function
* Fixed test_cmd_line_script.CmdLineTest.test_dash_m_error_code_is_one(), which was only checking the Python exit status, and not verifying that the specific failure was the one anticipated

----------
keywords: +patch
Added file: http://bugs.python.org/file38438/runpy-traceback.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14285>
_______________________________________

From report at bugs.python.org  Wed Mar 11 09:35:04 2015
From: report at bugs.python.org (=?utf-8?b?THVrw6HFoSBOxJttZWM=?=)
Date: Wed, 11 Mar 2015 08:35:04 +0000
Subject: [issue23637] Warnings error with non-ascii chars.
Message-ID: <1426062904.63.0.0951614232281.issue23637@psf.upfronthosting.co.za>


New submission from Luk?? N?mec:

File "/usr/lib/python2.7/warnings.py", line 29, in _show_warning
    file.write(formatwarning(message, category, filename, lineno, line))
  File "/usr/lib/python2.7/warnings.py", line 38, in formatwarning
    s =  "%s:%s: %s: %s\n" % (filename, lineno, category.__name__, message)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xed' in position 42: ordinal not in range(128)

Only thing required to make this work is add "u" in front of the message so it is unicode. This will work for all ascii characters and all non-ascii should pass unicode anyway.

----------
components: Library (Lib)
messages: 237850
nosy: Luk??.N?mec
priority: normal
severity: normal
status: open
title: Warnings error with non-ascii chars.
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23637>
_______________________________________

From report at bugs.python.org  Wed Mar 11 09:41:21 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 11 Mar 2015 08:41:21 +0000
Subject: [issue14285] Traceback wrong on ImportError while executing a package
In-Reply-To: <1331621436.28.0.000669565075438.issue14285@psf.upfronthosting.co.za>
Message-ID: <1426063281.97.0.501352663756.issue14285@psf.upfronthosting.co.za>


Martin Panter added the comment:

Posting finding-spec.patch which just has another test I wrote. It tests if AttributeError/ValueError/TypeError gets wrapped in the ?finding spec? ImportError, though I?m not sure if this is a bug or a feature, hence I kept it separate. And again I?m not sure of a good way to fix it either.

----------
Added file: http://bugs.python.org/file38439/finding-spec.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14285>
_______________________________________

From report at bugs.python.org  Wed Mar 11 09:48:10 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Mar 2015 08:48:10 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>
Message-ID: <1426063690.19.0.703025745929.issue23566@psf.upfronthosting.co.za>


STINNER Victor added the comment:

issue23566_update.patch looks good to me, but I suggested some minor changes. Usually, I do such changes myself, but I proposed this issue on the Python menthorship list, so I prefer to do the changes to learn the process of reviewing patches and taking comments in account ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23566>
_______________________________________

From report at bugs.python.org  Wed Mar 11 09:48:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 11 Mar 2015 08:48:49 +0000
Subject: [issue23526] Silence resource warnings in test_httplib
In-Reply-To: <1424936136.32.0.667262366966.issue23526@psf.upfronthosting.co.za>
Message-ID: <1426063729.35.0.708368495627.issue23526@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think this one can be closed. Let me know if I was mistaken :)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23526>
_______________________________________

From report at bugs.python.org  Wed Mar 11 09:51:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Mar 2015 08:51:05 +0000
Subject: [issue23526] Silence resource warnings in test_httplib
In-Reply-To: <1424936136.32.0.667262366966.issue23526@psf.upfronthosting.co.za>
Message-ID: <1426063865.87.0.150118388573.issue23526@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I think this one can be closed. Let me know if I was mistaken :)

Correct, I forgot to close it, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23526>
_______________________________________

From report at bugs.python.org  Wed Mar 11 10:18:56 2015
From: report at bugs.python.org (Mario Figueiredo)
Date: Wed, 11 Mar 2015 09:18:56 +0000
Subject: [issue2889] curses for windows (alternative patch)
In-Reply-To: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za>
Message-ID: <1426065536.73.0.135952751162.issue2889@psf.upfronthosting.co.za>


Mario Figueiredo added the comment:

This patch is a huge improvement over the current situation, which is we don't have a cross-platform curses implementation in the standard library.

The alternatives listed by Mark aren't sufficient. For the two reasons given below:

- The implementation at http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses does not support unicode characters, which is a big limitation in today's general computing tasks.

- The UniCurses module isn't compatible with the curses standard lib implementation since it wraps curses/pdcurses and does not provide python own wrappers like the ability of addstr to accept encoded byte strings. This essentially makes UniCurses a 3rd-party library requirements regardless of the operating system, which is always nice to have but does not help the batteries included principles behind python standard library.

Conclusion:
Please implement this patch ASAP. It's been many years since it was made available. It works, it passes all tests and we all benefit if we close this python cross-compatibility issue.

----------
nosy: +Mario Figueiredo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2889>
_______________________________________

From report at bugs.python.org  Wed Mar 11 10:29:43 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 11 Mar 2015 09:29:43 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426066183.06.0.322212957574.issue2211@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Serhiy already reviewed the latest patch. Just one more comment: The deprecated API should be documented in Doc/whatsnew/3.5.rst and Doc/library/http.cookies.rst.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Wed Mar 11 11:00:34 2015
From: report at bugs.python.org (Paul Moore)
Date: Wed, 11 Mar 2015 10:00:34 +0000
Subject: [issue2889] curses for windows (alternative patch)
In-Reply-To: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za>
Message-ID: <1426068034.19.0.292593603113.issue2889@psf.upfronthosting.co.za>


Paul Moore added the comment:

The patch would need updating to be applicable. Minimum changes I would expect to be required:

1. Update to build for Python 3.5 (the patch will *not* be included in earlier versions, as it is a new feature), which means it needs the Visual Studio 2015 build files updating.
2. Rather than wholesale dumping a curses implementation into the Python source (which is what pdcurses.patch seems to do) the appropriate curses source should be fetched via the externals.bat script, like the other external dependencies.
3. Documentation. At a minimum "available in Windows from Python X.Y", but probably also document any differences from Unix, which from the comments here are likely to exist if the patch uses pdcurses on Windows.
4. Tests. Again, make sure that any functionality that differs is properly covered on Windows, or skip specific Unix-only functionality.

That's quite a lot of changes, in practice.

Unless someone is going to step up and do all of that (and keep it maintained until it gets merged, which probably won't be till 3.6) *and* there's one of the core devs willing to support the code going forward once its committed, then I think closing this as "won't fix" and referring to the external packages is the best solution.

A documentation patch to https://docs.python.org/3.4/howto/curses.html ("Curses programming with Python") which explained how to set up one of the external curses modules on Windows, and how to write cross-platform code that uses the core implementation on Unix and the 3rd party module on Windows, would be immensely useful for people interested in this patch. Probably far more so than pushing for this patch to go in, in all honesty, as it's easier to do and would be useful to people on older versions of Python as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2889>
_______________________________________

From report at bugs.python.org  Wed Mar 11 11:32:58 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 11 Mar 2015 10:32:58 +0000
Subject: [issue23526] Silence resource warnings in test_httplib
In-Reply-To: <1424936136.32.0.667262366966.issue23526@psf.upfronthosting.co.za>
Message-ID: <1426069978.21.0.28906804963.issue23526@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: commit review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23526>
_______________________________________

From report at bugs.python.org  Wed Mar 11 11:41:47 2015
From: report at bugs.python.org (yuriy_levchenko)
Date: Wed, 11 Mar 2015 10:41:47 +0000
Subject: [issue23638] shutil.copytree makedirs exception
Message-ID: <1426070507.27.0.472685674051.issue23638@psf.upfronthosting.co.za>


New submission from yuriy_levchenko:

We have a code:
    names = os.listdir(src)
    if ignore is not None:
        ignored_names = ignore(src, names)
    else:
        ignored_names = set()

    os.makedirs(dst)
        
    errors = []

But if I had created this folder. I have exception.

Maybe add "if"?

    if os.path.isdir(dst) is False:
        os.makedirs(dst)
        pass

----------
components: Library (Lib)
messages: 237858
nosy: yuriy_levchenko
priority: normal
severity: normal
status: open
title: shutil.copytree makedirs exception
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23638>
_______________________________________

From report at bugs.python.org  Wed Mar 11 12:15:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Mar 2015 11:15:01 +0000
Subject: [issue23639] Not documented special names
Message-ID: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here are lists of special names used in Python core and the stdlib, but absent in documentation index.

Module level names used in pydoc:
    __author__
    __credits__
    __date__
    __version__

Module level name used in doctest:
    __test__

Other module level names:
    __about__               (heapq only)
    __copyright__           (many modules)
    __cvsid__               (tarfile only)
    __docformat__           (doctest only)
    __email__               (test_with and test_keywordonlyarg only)
    __libmpdec_version__    (decimal only)
    __status__              (logging only)


type attributes (mostly used in tests):
    __abstractmethods__     (used in abc, functools)
    __base__
    __basicsize__
    __dictoffset__
    __flags__               (used in inspect, copyreg)
    __itemsize__
    __weakrefoffset__

super() attributes:
    __self_class__
    __thisclass__

Used in sqlite:
    __adapt__
    __conform__

Used in ctypes:
    __ctype_be__
    __ctype_le__
    __ctypes_from_outparam__

Used in unittest:
    __unittest_expecting_failure__
    __unittest_skip__
    __unittest_skip_why__

float methods, for testing:
    __getformat__
    __setformat__

Used in IDLE RPC:
    __attributes__
    __methods__

Others:
    __alloc__               (bytearray method)
    __args__                (used in bdb)
    __build_class__         (builtins function, used in eval loop)
    __builtins__            (module attribute)
    __decimal_context__     (used in decimal)
    __exception__           (used in pdb)
    __getinitargs__         (used in pickle, datetime)
    __initializing__        (used in importlib)
    __isabstractmethod__    (function/method/descriptor attribute, used in abc, functools, types)
    __ltrace__              (used in eval loop, never set)
    __members__             (Enum attribute, used in many modules)
    __mp_main__             (used in multiprocessing)
    __new_member__          (Enum attribute, used in enum internally)
    __newobj__              (copyreg function, used in pickle, object.__reduce_ex__)
    __newobj_ex__           (copyreg function, used in pickle, object.__reduce_ex__)
    __objclass__            (descriptor/enum attribute, used in inspect, pydoc, doctest, multiprocessing)
    __prepare__             (metaclass method, used in builtins.__build_class__, types)
    __pycache__             (cache directory name)
    __return__              (used in pdb)
    __signature__           (used in inspect, never set)
    __sizeof__              (standard method, used in sys.getsizeof)
    __slotnames__           (used in object.__getstate__ for caching)
    __text_signature__      (function/method/descriptor attribute, used in inspect)
    __trunc__               (used in math.trunc, int, etc)
    __warningregistry__     (used in warnings)
    __weakref__             (used in weakref)
    __wrapped__             (used in inspect, functools, contextlib, asyncio)

Needed a patch or a set of patches that will add theses names to the index and document them if they are not documented.

----------
assignee: docs at python
components: Documentation
messages: 237859
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Not documented special names
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23639>
_______________________________________

From report at bugs.python.org  Wed Mar 11 13:00:10 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 11 Mar 2015 12:00:10 +0000
Subject: [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1426075210.41.0.469970609612.issue23639@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I think most of these are either implementation details or "private" names, so there is no need to document them.  The ones that are intended to be used by developers or that are useful to understand the functioning of a public API should be documented.  If these names are already in the documentation but not in the index, then an index entry should be added.

----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23639>
_______________________________________

From report at bugs.python.org  Wed Mar 11 13:00:52 2015
From: report at bugs.python.org (Bruno Cauet)
Date: Wed, 11 Mar 2015 12:00:52 +0000
Subject: [issue23192] Generator return value ignored in lambda function
In-Reply-To: <1420728125.93.0.910147391239.issue23192@psf.upfronthosting.co.za>
Message-ID: <1426075252.37.0.533384638073.issue23192@psf.upfronthosting.co.za>


Bruno Cauet added the comment:

Here is a working test, testing yield by lambda & function as well as lambda and function yielding from those.

----------
Added file: http://bugs.python.org/file38440/0001-Add-tests-for-issue-23192.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23192>
_______________________________________

From report at bugs.python.org  Wed Mar 11 13:02:40 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Mar 2015 12:02:40 +0000
Subject: [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1426075360.39.0.451479549675.issue23639@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +__sizeof__ is not documented

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23639>
_______________________________________

From report at bugs.python.org  Wed Mar 11 14:07:15 2015
From: report at bugs.python.org (Yann Sionneau)
Date: Wed, 11 Mar 2015 13:07:15 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1426079235.86.0.953913484104.issue23630@psf.upfronthosting.co.za>


Yann Sionneau added the comment:

Here is a test related to Sebastien's patch.

----------
nosy: +ysionneau
Added file: http://bugs.python.org/file38441/asyncio_multibind_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Wed Mar 11 14:18:28 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Mar 2015 13:18:28 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1426079908.83.0.759572414686.issue23630@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Combine patch written for CPython tree, so we get the "review" button.

----------
Added file: http://bugs.python.org/file38442/multibind.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Wed Mar 11 14:34:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Mar 2015 13:34:36 +0000
Subject: [issue23640] Enum.from_bytes() is broken
Message-ID: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Example:

>>> import socket
>>> x = socket.AddressFamily.from_bytes(b'\1', 'big')
>>> type(x)
<enum 'AddressFamily'>
>>> int(x)
1
>>> str(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/enum.py", line 464, in __str__
    return "%s.%s" % (self.__class__.__name__, self._name_)
AttributeError: 'AddressFamily' object has no attribute '_name_'
>>> repr(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/enum.py", line 461, in __repr__
    self.__class__.__name__, self._name_, self._value_)
AttributeError: 'AddressFamily' object has no attribute '_name_'

----------
components: Library (Lib)
messages: 237864
nosy: barry, eli.bendersky, ethan.furman, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Enum.from_bytes() is broken
type: behavior
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________

From report at bugs.python.org  Wed Mar 11 14:46:44 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 11 Mar 2015 13:46:44 +0000
Subject: [issue23486] Enum member lookup is 20x slower than normal class
 attribute lookup
In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za>
Message-ID: <1426081604.84.0.160117164871.issue23486@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Poor performance could fall under the category of bug fixes, so for an in-maintenance mode release, a fix that does not in any way change user visible behavior could be acceptable.  It would probably be fine for 3.4 but I'm just +0 on it.  Larry's call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23486>
_______________________________________

From report at bugs.python.org  Wed Mar 11 15:04:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Mar 2015 14:04:02 +0000
Subject: [issue23486] Enum member lookup is 20x slower than normal class
 attribute lookup
In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za>
Message-ID: <1426082642.49.0.824802187843.issue23486@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is not a regression (there were no enums before 3.4), slow down is not critical (only constant factor, not increased computational complexity), there is a workaround, and the code that just use constants that were converted to IntEnum is not affected. I'm -0 on it.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23486>
_______________________________________

From report at bugs.python.org  Wed Mar 11 15:27:05 2015
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 11 Mar 2015 14:27:05 +0000
Subject: [issue23486] Enum member lookup is 20x slower than normal class
 attribute lookup
In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za>
Message-ID: <1426084025.07.0.560013641237.issue23486@psf.upfronthosting.co.za>


Ethan Furman added the comment:

In getting everything fixed up and tested I realized there was one slight user-facing change:  with this patch it is now possible to say:

  SomeEnum.SomeMember = SomeMember

In other words, it is possible to set a value on the class as long as it is the same value that already existed.

3.5 sounds good.

----------
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23486>
_______________________________________

From report at bugs.python.org  Wed Mar 11 15:42:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Mar 2015 14:42:15 +0000
Subject: [issue23641] Got rid of bad dunder names
Message-ID: <1426084934.72.0.0668161558437.issue23641@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch gets rid of uses and mentions of bad dunder names. I.e. names inherited from Python 2: __cmp__, __nonzero__, __getslice__, __unicode__, __div__, etc. They are replaced by correct names (__truediv__, __floordiv__, __eq__, __bool__, etc) or removed. Also fixed typos and other minor bugs. Also added support for __matmul__ and __getnewargs_ex__ in unittest.mock and added tests for __matmul__.

----------
components: Library (Lib), Tests
files: bad_dunder_names.patch
keywords: patch
messages: 237868
nosy: ezio.melotti, michael.foord, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Got rid of bad dunder names
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38443/bad_dunder_names.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23641>
_______________________________________

From report at bugs.python.org  Wed Mar 11 15:54:38 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 11 Mar 2015 14:54:38 +0000
Subject: [issue23641] Got rid of bad dunder names
In-Reply-To: <1426084934.72.0.0668161558437.issue23641@psf.upfronthosting.co.za>
Message-ID: <1426085678.84.0.447320621792.issue23641@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> Also added support for __matmul__ and __getnewargs_ex__ in unittest.mock [...]

See issue 23581 for __matmul__ support.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23641>
_______________________________________

From report at bugs.python.org  Wed Mar 11 15:54:44 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 11 Mar 2015 14:54:44 +0000
Subject: [issue23615] Reloading tokenize breaks tokenize.open()
In-Reply-To: <1425864069.02.0.403381374988.issue23615@psf.upfronthosting.co.za>
Message-ID: <1426085684.46.0.977769506417.issue23615@psf.upfronthosting.co.za>


Brett Cannon added the comment:

LGTM as well. You want to commit, Serhiy? If not assign to me and I will get to it on Friday.

----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23615>
_______________________________________

From report at bugs.python.org  Wed Mar 11 15:59:43 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 11 Mar 2015 14:59:43 +0000
Subject: [issue23625] load_module() docs: zipped eggs are not loaded.
In-Reply-To: <1425986086.94.0.227506635369.issue23625@psf.upfronthosting.co.za>
Message-ID: <1426085983.55.0.563906521077.issue23625@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Egg files are not a part of the Python stdlib and so I don't understand why you expected them to be supported by imp? Anyway, because egg files are not from Python itself but a third-party project they shouldn't be referenced from the official docs as it would just confuse people who don't know what eggs even are.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +brett.cannon, docs at python
resolution:  -> not a bug
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23625>
_______________________________________

From report at bugs.python.org  Wed Mar 11 16:08:52 2015
From: report at bugs.python.org (David Beazley)
Date: Wed, 11 Mar 2015 15:08:52 +0000
Subject: [issue23642] Interaction of ModuleSpec and C Extension Modules
Message-ID: <1426086531.98.0.531682777516.issue23642@psf.upfronthosting.co.za>


New submission from David Beazley:

I have been investigating some of the new importlib machinery and the addition of ModuleSpec objects.  I am a little curious about the intended handling of C Extension modules going forward. 

Backing up for a moment, consider a pure Python module.  It seems that I can do things like this to bring a module into existence (some steps involving sys.modules omitted).

>>> from importlib.util import find_spec, module_from_spec
>>> spec = find_spec('socket')
>>> socket = module_from_spec(spec)
>>> spec.loader.exec_module(socket)
>>>

However, it all gets "weird" with C extension modules.  For example, you can perform the first few steps:

>>> spec = find_spec('math')
>>> spec
ModuleSpec(name='math', loader=<_frozen_importlib.ExtensionFileLoader object at 0x1012122b0>, origin='/usr/local/lib/python3.5/lib-dynload/math.so')
>>> math = module_from_spec(spec)
>>> math
<module 'math' from '/usr/local/lib/python3.5/lib-dynload/math.so'>
>>> dir(math)
['__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__']

As you can see, you get a fresh "unloaded" module here.  However, if you try to bring in the module contents, things get screwy.

>>> spec.loader.exec_module(math)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'ExtensionFileLoader' object has no attribute 'exec_module'
>>>

Yes, this is the old legacy interface in action--there is no exec_module() method.   You can always fall back to load_module() like this:

>>> spec.loader.load_module(spec.name)
<module 'math' from '/usr/local/lib/python3.5/lib-dynload/math.so'>
>>>

The problem here is that it creates a brand new module and ignores the one that was previously created by module_from_spec().  That module is still empty:

>>> dir(math)
['__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__']
>>> 

I realize that I'm treading into a swamp of legacy interfaces and some pretty complex machinery here.  However, here's my question:  are C extension modules always going to be a special case that need to be considered code that interacts with the import system.  Specifically, will it need to be special-cased to use load_module() instead of the module_from_spec()/exec_module() combination?

I suppose the question might also apply to built-in and frozen modules as well (although I haven't investigated that so much). 

Mainly, I'm just trying to gain some insight from the devs as to the overall direction where the import implementation is going with this.

P.S.  ModuleSpecs are cool. +1

----------
components: Interpreter Core
messages: 237872
nosy: dabeaz
priority: normal
severity: normal
status: open
title: Interaction of ModuleSpec and C Extension Modules
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23642>
_______________________________________

From report at bugs.python.org  Wed Mar 11 16:09:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Mar 2015 15:09:27 +0000
Subject: [issue23581] unittest.mock.MagicMock doesn't support matmul (@)
 operator
In-Reply-To: <1425461221.82.0.715365961896.issue23581@psf.upfronthosting.co.za>
Message-ID: <1426086567.14.0.760184658794.issue23581@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> berker.peksag
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23581>
_______________________________________

From report at bugs.python.org  Wed Mar 11 16:09:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Mar 2015 15:09:36 +0000
Subject: [issue23641] Got rid of bad dunder names
In-Reply-To: <1426084934.72.0.0668161558437.issue23641@psf.upfronthosting.co.za>
Message-ID: <1426086576.83.0.411664745565.issue23641@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +unittest.mock.MagicMock doesn't support matmul (@) operator

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23641>
_______________________________________

From report at bugs.python.org  Wed Mar 11 16:15:15 2015
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 11 Mar 2015 15:15:15 +0000
Subject: [issue23640] Enum.from_bytes() is broken
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1426086915.2.0.608892822509.issue23640@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________

From report at bugs.python.org  Wed Mar 11 16:15:40 2015
From: report at bugs.python.org (David Beazley)
Date: Wed, 11 Mar 2015 15:15:40 +0000
Subject: [issue23642] Interaction of ModuleSpec and C Extension Modules
In-Reply-To: <1426086531.98.0.531682777516.issue23642@psf.upfronthosting.co.za>
Message-ID: <1426086940.37.0.0636488858869.issue23642@psf.upfronthosting.co.za>


David Beazley added the comment:

Note: Might be related to Issue 19713.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23642>
_______________________________________

From report at bugs.python.org  Wed Mar 11 16:17:31 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Mar 2015 15:17:31 +0000
Subject: [issue23467] Improve byte formatting compatibility between Py2 and Py3
In-Reply-To: <1424025207.37.0.294145986044.issue23467@psf.upfronthosting.co.za>
Message-ID: <20150311151727.8065.88267@psf.io>


Roundup Robot added the comment:

New changeset 611fa301b807 by Ethan Furman in branch 'default':
Close issue23467: add %r compatibility to bytes and bytearray
https://hg.python.org/cpython/rev/611fa301b807

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23467>
_______________________________________

From report at bugs.python.org  Wed Mar 11 16:21:35 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 11 Mar 2015 15:21:35 +0000
Subject: [issue23642] Interaction of ModuleSpec and C Extension Modules
In-Reply-To: <1426086531.98.0.531682777516.issue23642@psf.upfronthosting.co.za>
Message-ID: <1426087295.22.0.0598978380365.issue23642@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +brett.cannon, eric.snow, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23642>
_______________________________________

From report at bugs.python.org  Wed Mar 11 16:24:10 2015
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 11 Mar 2015 15:24:10 +0000
Subject: [issue23640] Enum.from_bytes() is broken
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1426087450.65.0.858914697031.issue23640@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
keywords: +patch
stage: test needed -> needs patch
Added file: http://bugs.python.org/file38444/issue23640.stoneleaf.01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________

From report at bugs.python.org  Wed Mar 11 16:28:09 2015
From: report at bugs.python.org (David Beazley)
Date: Wed, 11 Mar 2015 15:28:09 +0000
Subject: [issue23642] Interaction of ModuleSpec and C Extension Modules
In-Reply-To: <1426086531.98.0.531682777516.issue23642@psf.upfronthosting.co.za>
Message-ID: <1426087689.15.0.984036648795.issue23642@psf.upfronthosting.co.za>


David Beazley added the comment:

inal comment.  It seems that one can generally avoid a lot of nastiness if importlib.reload() is used instead.  For example:

>>> mod = sys.modules[spec.name] = module_from_spec(spec)
>>> importlib.reload(mod)

This works for both source and Extension modules and completely avoids the need to worry about the exec_module()/load_module() warts.   Wouldn't say it's an obvious approach though ;-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23642>
_______________________________________

From report at bugs.python.org  Wed Mar 11 16:32:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Mar 2015 15:32:55 +0000
Subject: [issue23615] Reloading tokenize breaks tokenize.open()
In-Reply-To: <1425864069.02.0.403381374988.issue23615@psf.upfronthosting.co.za>
Message-ID: <20150311153252.19085.18047@psf.io>


Roundup Robot added the comment:

New changeset 383ba3699084 by Serhiy Storchaka in branch '3.4':
Issue #23615: Modules bz2, tarfile and tokenize now can be reloaded with
https://hg.python.org/cpython/rev/383ba3699084

New changeset 6e736a57a482 by Serhiy Storchaka in branch 'default':
Issue #23615: Modules bz2, tarfile and tokenize now can be reloaded with
https://hg.python.org/cpython/rev/6e736a57a482

New changeset 36bd5add9732 by Serhiy Storchaka in branch '2.7':
Issue #23615: Module tarfile is now can be reloaded with imp.reload().
https://hg.python.org/cpython/rev/36bd5add9732

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23615>
_______________________________________

From report at bugs.python.org  Wed Mar 11 16:35:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Mar 2015 15:35:00 +0000
Subject: [issue23615] Reloading tokenize breaks tokenize.open()
In-Reply-To: <1425864069.02.0.403381374988.issue23615@psf.upfronthosting.co.za>
Message-ID: <1426088100.13.0.757545229294.issue23615@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23615>
_______________________________________

From report at bugs.python.org  Wed Mar 11 16:43:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Mar 2015 15:43:55 +0000
Subject: [issue23486] Enum member lookup is 20x slower than normal class
 attribute lookup
In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za>
Message-ID: <20150311154346.8085.39776@psf.io>


Roundup Robot added the comment:

New changeset 2545bfe0d273 by Ethan Furman in branch 'default':
Close issue23486: performance boost for enum member lookup
https://hg.python.org/cpython/rev/2545bfe0d273

----------
nosy: +python-dev
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23486>
_______________________________________

From report at bugs.python.org  Wed Mar 11 16:45:36 2015
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 11 Mar 2015 15:45:36 +0000
Subject: [issue23486] Enum member lookup is 20x slower than normal class
 attribute lookup
In-Reply-To: <1424383153.37.0.19682507186.issue23486@psf.upfronthosting.co.za>
Message-ID: <1426088736.9.0.526745801383.issue23486@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Slight reordering of code removed the one user visible change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23486>
_______________________________________

From report at bugs.python.org  Wed Mar 11 16:52:32 2015
From: report at bugs.python.org (Wei Wu)
Date: Wed, 11 Mar 2015 15:52:32 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>
Message-ID: <1426089152.38.0.114203756626.issue23566@psf.upfronthosting.co.za>


Wei Wu added the comment:

Updated the patch and addressed the previous review comments:

 * Fixed the hasattr problem
 * Added a default value None for filename in check_dump_traceback
 * Reverted unnecessary code change in check_dump_traceback_later
 * Added a new paragraph to the enable, dump_traceback_later and
register in doc

Let me know if there is possible further improvement in this patch.

: )

----------
Added file: http://bugs.python.org/file38445/issue23566_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23566>
_______________________________________

From report at bugs.python.org  Wed Mar 11 17:13:18 2015
From: report at bugs.python.org (David Beazley)
Date: Wed, 11 Mar 2015 16:13:18 +0000
Subject: [issue23642] Interaction of ModuleSpec and C Extension Modules
In-Reply-To: <1426086531.98.0.531682777516.issue23642@psf.upfronthosting.co.za>
Message-ID: <1426090398.53.0.412467589309.issue23642@psf.upfronthosting.co.za>


David Beazley added the comment:

Sorry. I take back the previous message.  It still doesn't quite do what I want.   Anyways, any insight or thoughts about this would be appreciated ;-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23642>
_______________________________________

From report at bugs.python.org  Wed Mar 11 17:17:38 2015
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 11 Mar 2015 16:17:38 +0000
Subject: [issue23640] Enum.from_bytes() is broken
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1426090658.06.0.586783770342.issue23640@psf.upfronthosting.co.za>


Ethan Furman added the comment:

The only solution that is coming to mind is to have EnumMeta go through the other base classes, wrap any classmethods it finds, and ensure that they return their appropriate type and not an Enum type.

Any other ideas?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________

From report at bugs.python.org  Wed Mar 11 17:23:06 2015
From: report at bugs.python.org (Thomas Guettler)
Date: Wed, 11 Mar 2015 16:23:06 +0000
Subject: [issue23625] load_module() docs: zipped eggs are not loaded.
In-Reply-To: <1425986086.94.0.227506635369.issue23625@psf.upfronthosting.co.za>
Message-ID: <1426090986.77.0.890162457456.issue23625@psf.upfronthosting.co.za>


Thomas Guettler added the comment:

Dear Bret Cannon,

I don't ask for egg support in the imp module.
I don't want to change the implemenation of imp.find_module()

I just want to update the docs.

Most people run a python version which supports loading zipped eggs.

Please reopened this, since I think you misunderstood me. If not, and you don't care about the docs. Leave it closed :-)

----------
nosy: +guettli

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23625>
_______________________________________

From report at bugs.python.org  Wed Mar 11 17:23:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Mar 2015 16:23:18 +0000
Subject: [issue23192] Generator return value ignored in lambda function
In-Reply-To: <1420728125.93.0.910147391239.issue23192@psf.upfronthosting.co.za>
Message-ID: <20150311162315.19083.93100@psf.io>


Roundup Robot added the comment:

New changeset 2b4a04c3681b by Serhiy Storchaka in branch '3.4':
Issue #23192: Fixed generator lambdas.  Patch by Bruno Cauet.
https://hg.python.org/cpython/rev/2b4a04c3681b

New changeset a3b889e9d3f3 by Serhiy Storchaka in branch 'default':
Issue #23192: Fixed generator lambdas.  Patch by Bruno Cauet.
https://hg.python.org/cpython/rev/a3b889e9d3f3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23192>
_______________________________________

From report at bugs.python.org  Wed Mar 11 17:25:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Mar 2015 16:25:22 +0000
Subject: [issue23192] Generator return value ignored in lambda function
In-Reply-To: <1420728125.93.0.910147391239.issue23192@psf.upfronthosting.co.za>
Message-ID: <1426091122.97.0.686557380625.issue23192@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Committed with non-dis test. Thank you for your contribution Bruno.

----------
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23192>
_______________________________________

From report at bugs.python.org  Wed Mar 11 17:31:11 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Mar 2015 16:31:11 +0000
Subject: [issue23467] Improve byte formatting compatibility between Py2 and Py3
In-Reply-To: <1424025207.37.0.294145986044.issue23467@psf.upfronthosting.co.za>
Message-ID: <1426091471.17.0.984082599631.issue23467@psf.upfronthosting.co.za>


STINNER Victor added the comment:

You should also update the PEP 461.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23467>
_______________________________________

From report at bugs.python.org  Wed Mar 11 17:36:13 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 11 Mar 2015 16:36:13 +0000
Subject: [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1426091773.72.0.0392124622118.issue23639@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I think like Ezio does.  Python covers itself by saying that all names starting and ending with two underscores are reserved, and documents those that are interesting for users.  On the other hand, many third-party frameworks/libs/apps invent their own __names__ (often for metadata, sometimes for custom protocols); I don?t know if a full list of existing names in the doc would have dissuaded them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23639>
_______________________________________

From report at bugs.python.org  Wed Mar 11 17:45:25 2015
From: report at bugs.python.org (Peter Otten)
Date: Wed, 11 Mar 2015 16:45:25 +0000
Subject: [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1426092325.11.0.515132101502.issue23639@psf.upfronthosting.co.za>


Changes by Peter Otten <__peter__ at web.de>:


----------
nosy: +peter.otten

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23639>
_______________________________________

From report at bugs.python.org  Wed Mar 11 17:58:04 2015
From: report at bugs.python.org (Bruno Cauet)
Date: Wed, 11 Mar 2015 16:58:04 +0000
Subject: [issue23640] Enum.from_bytes() is broken
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1426093084.23.0.6121744571.issue23640@psf.upfronthosting.co.za>


Bruno Cauet added the comment:

Hi,
I feel like this behaviour does not only affect IntEnum & related but anything that inherits from int.

Example:
>>> class foo(int):
...     def __init__(self, value, base=10):
...         if value == 2:
...             raise ValueError("not that!!")
...         super(foo, self).__init__(value, base=base)
...
>>> x = foo.from_bytes(b"\2", "big")
>>> x
2
>>> type(x)
foo

2 solutions come to mind:
- always return an int, and not the type. deleting Objects/longobjects.c:4845,4866 does the job.
- instantiate the required type with the value as the (sole?) argument, correctly initializing the object to be returned. In Serhyi's example this results in x == AddressFamily.AF_UNIX. the same lines are concerned.

----------
nosy: +bru

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________

From report at bugs.python.org  Wed Mar 11 18:03:51 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Mar 2015 17:03:51 +0000
Subject: [issue23640] Enum.from_bytes() is broken
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1426093431.73.0.594070728246.issue23640@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Not all classmethods are constructors.

I see two solutions:

1) Override from_bytes() in IntEnum and every int subclass that needs this.

2) Change int.from_bytes() to call __new__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________

From report at bugs.python.org  Wed Mar 11 18:17:31 2015
From: report at bugs.python.org (eryksun)
Date: Wed, 11 Mar 2015 17:17:31 +0000
Subject: [issue23633] Improve py launcher help, index, and doc
In-Reply-To: <1426026714.29.0.122233634927.issue23633@psf.upfronthosting.co.za>
Message-ID: <1426094251.22.0.800395717188.issue23633@psf.upfronthosting.co.za>


eryksun added the comment:

> To me, the reference to the windows internal function is 
> worse than useless and should perhaps be removed.

The docs could add an example commandline to edit the per-user .ini: 

NT 6: notepad "%LOCALAPPDATA%\py.ini"
NT 5: notepad "%USERPROFILE%\Local Settings\Application Data\py.ini"

Editing the global .ini would be simpler if the launcher looked for it in FOLDERID_ProgramData (i.e. CSIDL_COMMON_APPDATA). In that case even a limited user could create it. For example:

NT 6: notepad "%ProgramData%\py.ini"
NT 5: notepad "%ALLUSERSPROFILE%\Application Data\py.ini"

The security on %ProgramData% grants full control to the creator of files and directories. It also allows all users to create, read and execute files and directories.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23633>
_______________________________________

From report at bugs.python.org  Wed Mar 11 18:26:02 2015
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 11 Mar 2015 17:26:02 +0000
Subject: [issue23640] Enum.from_bytes() is broken
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1426094762.6.0.607507382027.issue23640@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I think the classmethod-as-constructor behavior is correct, so it's up to IntEnum (or EnumMeta, or foo, or ...), to work around the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________

From report at bugs.python.org  Wed Mar 11 18:26:50 2015
From: report at bugs.python.org (Michael Klein)
Date: Wed, 11 Mar 2015 17:26:50 +0000
Subject: [issue23643] Segmentation Fault with Large Simple Function
In-Reply-To: <1426094044.96.0.525794841659.issue23643@psf.upfronthosting.co.za>
Message-ID: <1426094810.49.0.805683507611.issue23643@psf.upfronthosting.co.za>


Changes by Michael Klein <michael14486 at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23643>
_______________________________________

From report at bugs.python.org  Wed Mar 11 18:31:51 2015
From: report at bugs.python.org (SilentGhost)
Date: Wed, 11 Mar 2015 17:31:51 +0000
Subject: [issue23643] Segmentation Fault with Large Simple Function
In-Reply-To: <1426094044.96.0.525794841659.issue23643@psf.upfronthosting.co.za>
Message-ID: <1426095111.1.0.898251560303.issue23643@psf.upfronthosting.co.za>


SilentGhost added the comment:

This seems to work on linux (returning 0), but fails on 3.4 with "RuntimeError: maximum recursion depth exceeded during compilation". I wonder if the two are related.

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23643>
_______________________________________

From report at bugs.python.org  Wed Mar 11 18:38:00 2015
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 11 Mar 2015 17:38:00 +0000
Subject: [issue23643] Segmentation Fault with Large Simple Function
In-Reply-To: <1426094044.96.0.525794841659.issue23643@psf.upfronthosting.co.za>
Message-ID: <1426095480.16.0.0511083274191.issue23643@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Probably a stack overflow, when the AST is too deep:
eval("+1" * 748580) also crashed for me

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23643>
_______________________________________

From report at bugs.python.org  Wed Mar 11 19:01:37 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 Mar 2015 18:01:37 +0000
Subject: [issue23633] Improve py launcher help, index, and doc
In-Reply-To: <1426026714.29.0.122233634927.issue23633@psf.upfronthosting.co.za>
Message-ID: <1426096897.9.0.260775186601.issue23633@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Good idea, but what do 'NT5' and 'NT6' correspond to in user terms -- Vista, Win 7, Win 8, and Win 10?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23633>
_______________________________________

From report at bugs.python.org  Wed Mar 11 19:06:05 2015
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 11 Mar 2015 18:06:05 +0000
Subject: [issue23643] Segmentation Fault with Large Simple Function
In-Reply-To: <1426094044.96.0.525794841659.issue23643@psf.upfronthosting.co.za>
Message-ID: <1426097165.1.0.757447747155.issue23643@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

So the recursion crash was fixed in python3,
but it's still one of the limits of the Python AST compiler.

I suggest to replace your long expression by a list:
  exprs = [(1-a36)*(a37)*(1-a41), (a22)*(a33)*(1-a23), ...]
  return sum(exprs)

...but this function requires large storage at runtime, on the Python stack, and for the list.
Maybe better:
  loopcount = 0
  loopcount += (1-a36)*(a37)*(1-a41)
  ...
  return loopcount

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23643>
_______________________________________

From report at bugs.python.org  Wed Mar 11 19:09:19 2015
From: report at bugs.python.org (Bruno Cauet)
Date: Wed, 11 Mar 2015 18:09:19 +0000
Subject: [issue23640] Enum.from_bytes() is broken
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1426097359.18.0.00650001245838.issue23640@psf.upfronthosting.co.za>


Bruno Cauet added the comment:

I took the liberty of putting together a small patch which makes from_bytes() call & return type(value_found) if type != long (Serhiy's & my 2nd solution).

Ethan: in that case, type.from_bytes() would always return an int, and not resort to build-a-pseudo-int, right? That way not overriding from_bytes() would not result in strange behaviour.

----------
Added file: http://bugs.python.org/file38447/0001-int.from_bytes-calls-constructor-for-subclasses.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________

From report at bugs.python.org  Wed Mar 11 19:10:13 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 11 Mar 2015 18:10:13 +0000
Subject: [issue23633] Improve py launcher help, index, and doc
In-Reply-To: <1426026714.29.0.122233634927.issue23633@psf.upfronthosting.co.za>
Message-ID: <1426097413.17.0.745515540429.issue23633@psf.upfronthosting.co.za>


Steve Dower added the comment:

NT 5 would be Vista and earlier in this case, I believe. Specifying %LOCALAPPDATA% should be sufficient, though %USERPROFILE% (e.g. C:\Users\Steve) would also be okay.

%ProgramData% is not writable by limited users, but we don't want the global .ini to be editable by non-admin users. That said, even admins aren't supposed to go editing stuff in %ProgramData%, as I understand it.

I think having "alongside the EXE or in %LOCALAPPDATA%" is fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23633>
_______________________________________

From report at bugs.python.org  Wed Mar 11 19:26:11 2015
From: report at bugs.python.org (Michael Klein)
Date: Wed, 11 Mar 2015 18:26:11 +0000
Subject: [issue23643] Segmentation Fault with Large Simple Function
In-Reply-To: <1426094044.96.0.525794841659.issue23643@psf.upfronthosting.co.za>
Message-ID: <1426098371.73.0.59418391959.issue23643@psf.upfronthosting.co.za>


Michael Klein added the comment:

I found a simpler one, like Amaury's eval("+1" * 748580):

def f(x): 
    y = x+x+x+x+x
    return y
print f(0)

(Except there are 74875 x+'s. This is exactly enough for a segfault, one less runs fine.)

I've tried something like:

 loopcount = 0
  loopcount += (1-a36)*(a37)*(1-a41)
  ...
  return loopcount

It works, but it's still pretty slow. (At least it doesn't crash.) I tried converting to C with Cython, but it's too big to be processed in a reasonable amount of time, but this is irrelevant to the bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23643>
_______________________________________

From report at bugs.python.org  Wed Mar 11 19:30:52 2015
From: report at bugs.python.org (eryksun)
Date: Wed, 11 Mar 2015 18:30:52 +0000
Subject: [issue23633] Improve py launcher help, index, and doc
In-Reply-To: <1426026714.29.0.122233634927.issue23633@psf.upfronthosting.co.za>
Message-ID: <1426098652.06.0.456574497682.issue23633@psf.upfronthosting.co.za>


eryksun added the comment:

> Good idea, but what do 'NT5' and 'NT6' correspond to in user terms
> -- Vista, Win 7, Win 8, and Win 10?

Don't worry about NT 5 if Python's no longer supporting Windows XP in any fashion. Vista, Windows 7, Windows 8, Windows 8.1, and Windows 10 are respectively NT kernel versions 6.0, 6.1, 6.2, 6.3, and 10.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23633>
_______________________________________

From report at bugs.python.org  Wed Mar 11 19:50:39 2015
From: report at bugs.python.org (eryksun)
Date: Wed, 11 Mar 2015 18:50:39 +0000
Subject: [issue23633] Improve py launcher help, index, and doc
In-Reply-To: <1426026714.29.0.122233634927.issue23633@psf.upfronthosting.co.za>
Message-ID: <1426099839.94.0.359556636937.issue23633@psf.upfronthosting.co.za>


eryksun added the comment:

> Specifying %LOCALAPPDATA% should be sufficient, though 
> %USERPROFILE% (e.g. C:\Users\Steve) would also be okay.

The command using %USERPROFILE% was for XP (NT 5.1), since the %LOCALAPPDATA% environment variable was added in Vista (NT 6.0).

> %ProgramData% is not writable by limited users, but we 
> don't want the global .ini to be editable by non-admin 
> users. That said, even admins aren't supposed to go 
> editing stuff in %ProgramData%, as I understand it.

    C:\>icacls "%ProgramData%"
    C:\ProgramData NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                   BUILTIN\Administrators:(OI)(CI)(F)
                   CREATOR OWNER:(OI)(CI)(IO)(F)
                   BUILTIN\Users:(OI)(CI)(RX)
                   BUILTIN\Users:(CI)(WD,AD,WEA,WA)

All users have the right to create files and directories here (i.e. (CI)(WD,AD,WEA,WA)), and by "CREATOR OWNER" they have full control of the files they create. So obviously if a system account or administrator creates the .ini, then non-admin users won't be able to edit it.

> I think having "alongside the EXE or in %LOCALAPPDATA%" is fine.

Editing an .ini in %SystemRoot% feels a bit weird, like something out of NT 4 in the 1990s. Really it belongs in %ProgramData%, not that there's anything wrong with checking for it alongside the executable as well. I just think it wouldn't hurt to check in both locations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23633>
_______________________________________

From report at bugs.python.org  Wed Mar 11 20:02:00 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 Mar 2015 19:02:00 +0000
Subject: [issue23633] Improve py launcher help, index, and doc
In-Reply-To: <1426026714.29.0.122233634927.issue23633@psf.upfronthosting.co.za>
Message-ID: <1426100520.51.0.0998314779474.issue23633@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

C:\Users\Terry>notepad %localappdata%
"Access denied"

"Alongside the EXE" is not fine.  I only knew to look in C:/Windows because I have using DOS/Windoes since the early 80s (and there is still much that I do not know, like 'icacls'), and I believe there was a mention somewhere in the pydev py.exe discussion.  I still found it surprising since installed programs are generally not put there the way they once were.  If py.exe is always in that directory for all Windows versions we support, we should just say 'in C:/windows', but my impression is that this may not always be true.

Doc-only changes can and should be backported to 2.7 and 3.4, which do support XP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23633>
_______________________________________

From report at bugs.python.org  Wed Mar 11 18:14:05 2015
From: report at bugs.python.org (Michael Klein)
Date: Wed, 11 Mar 2015 17:14:05 +0000
Subject: [issue23643] Segmentation Fault with Large Simple Function
Message-ID: <1426094044.96.0.525794841659.issue23643@psf.upfronthosting.co.za>


New submission from Michael Klein:

I have gotten "Segmentation Fault: 11" with the newest version of Python 2.7 and nothing but standard functions. The program is of the following form (attached to this email):

def loopcountaux(a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11, a12, a13, a14, a15, a16, a17, a18, a19, a20, a21, a22, a23, a24, a25, a26, a27, a28, a29, a30, a31, a32, a33, a34, a35, a36, a37, a38, a39, a40, a41, a42, a43):

    loopcount = ((1-a36)*(a37)*(1-a41)) + ((a22)*(a33)*(1-a23)) + ((a27)*(a34)*(1-a28)) + ((a38)*(a43)*(1-a39)) + ((a40)*(a42)*(1-a41))+((1-a22)*(1-a33)*(a23)) + ((1-a27)*(1-a34)*(a28)) + ((1-a38)*(1-a43)*(a39)) + ((1-a40)*(1-a42)*(a41)) + ((a36)*(1-a37)*(a41))
    return loopcount

print loopcountaux(1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1)

The only difference between this and the file which causes the fault is the number of formulas added to the line where "loopcount" is defined (74858 more of a similar kind). Note that this program finds the number of boolean formulas from a given set which are true for given variables a1, a2,... For example, "((1-a36)*(a37)*(1-a41))" is effectively the same as "(not a36) and (a37) and (not a41)".

If this example makes debugging particularly difficult, I can try to find a less complex example, though this example is just long enough to cause a segfault (with one less statement it runs well).

Thank you for your time.

The OSX error report is as follows:

Process:               Python [8151]
Path:                  /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
Identifier:            Python
Version:               2.7.9 (2.7.9)
Code Type:             X86-64 (Native)
Parent Process:        bash [3554]
Responsible:           Terminal [599]
User ID:               501

Date/Time:             2015-03-11 12:21:52.952 -0400
OS Version:            Mac OS X 10.10.2 (14C109)
Report Version:        11
Anonymous UUID:        49801587-229C-BA4D-0630-D2490825F5C7

Sleep/Wake UUID:       44D3FBEF-DC64-44CA-A10A-70E9E16AE5C2

Time Awake Since Boot: 160000 seconds
Time Since Wake:       17000 seconds

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_PROTECTION_FAILURE at 0x00007fff5f3ffff8

VM Regions Near 0x7fff5f3ffff8:
    MALLOC_SMALL           000000014e800000-0000000151000000 [ 40.0M] rw-/rwx SM=PRV  
--> STACK GUARD            00007fff5bc00000-00007fff5f400000 [ 56.0M] ---/rwx SM=NUL  stack guard for thread 0
    Stack                  00007fff5f400000-00007fff5fc00000 [ 8192K] rw-/rwx SM=COW  thread 0

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   org.python.python             	0x000000010005d734 PyObject_RichCompareBool + 4
1   org.python.python             	0x0000000100070f38 tuplerichcompare + 152
2   org.python.python             	0x000000010005cbf9 PyObject_RichCompare + 201
3   org.python.python             	0x000000010005d760 PyObject_RichCompareBool + 48
4   org.python.python             	0x0000000100052ebd lookdict + 397
5   org.python.python             	0x0000000100054900 PyDict_GetItem + 112
6   org.python.python             	0x00000001000c63a5 compiler_add_o + 277
7   org.python.python             	0x00000001000c9348 compiler_visit_expr + 840
8   org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
9   org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
10  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
11  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
12  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
13  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
14  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
15  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
16  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
17  org.python.python             	0x00000001000c9bc0 compiler_visit_expr + 3008
18  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
19  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
20  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
21  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
22  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
23  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
24  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
25  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
26  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
27  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
28  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
29  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
30  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
31  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
32  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
33  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
34  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
35  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
36  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
37  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
38  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
39  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
40  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
41  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
42  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
43  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
44  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
45  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
46  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
47  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
48  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
49  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
50  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
51  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
52  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
53  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
54  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
55  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
56  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
57  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
58  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
59  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
60  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
61  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
62  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
63  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
64  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
65  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
66  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
67  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
68  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
69  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
70  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
71  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
72  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
73  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
74  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
75  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
76  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
77  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
78  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
79  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
80  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
81  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
82  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
83  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
84  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
85  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
86  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
87  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
88  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
89  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
90  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
91  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
92  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
93  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
94  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
95  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
96  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
97  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
98  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
99  org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
100 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
101 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
102 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
103 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
104 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
105 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
106 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
107 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
108 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
109 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
110 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
111 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
112 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
113 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
114 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
115 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
116 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
117 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
118 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
119 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
120 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
121 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
122 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
123 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
124 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
125 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
126 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
127 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
128 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
129 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
130 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
131 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
132 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
133 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
134 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
135 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
136 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
137 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
138 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
139 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
140 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
141 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
142 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
143 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
144 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
145 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
146 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
147 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
148 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
149 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
150 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
151 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
152 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
153 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
154 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
155 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
156 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
157 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
158 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
159 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
160 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
161 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
162 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
163 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
164 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
165 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
166 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
167 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
168 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
169 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
170 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
171 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
172 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
173 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
174 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
175 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
176 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
177 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
178 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
179 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
180 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
181 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
182 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
183 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
184 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
185 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
186 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
187 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
188 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
189 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
190 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
191 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
192 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
193 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
194 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
195 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
196 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
197 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
198 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
199 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
200 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
201 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
202 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
203 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
204 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
205 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
206 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
207 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
208 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
209 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
210 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
211 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
212 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
213 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
214 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
215 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
216 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
217 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
218 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
219 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
220 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
221 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
222 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
223 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
224 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
225 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
226 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
227 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
228 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
229 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
230 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
231 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
232 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
233 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
234 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
235 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
236 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
237 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
238 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
239 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
240 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
241 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
242 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
243 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
244 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
245 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
246 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
247 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
248 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
249 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
250 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
251 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
252 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
253 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
254 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
255 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
256 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
257 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
258 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
259 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
260 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
261 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
262 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
263 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
264 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
265 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
266 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
267 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
268 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
269 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
270 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
271 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
272 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
273 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
274 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
275 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
276 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
277 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
278 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
279 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
280 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
281 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
282 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
283 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
284 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
285 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
286 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
287 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
288 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
289 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
290 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
291 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
292 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
293 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
294 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
295 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
296 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
297 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
298 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
299 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
300 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
301 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
302 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
303 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
304 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
305 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
306 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
307 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
308 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
309 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
310 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
311 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
312 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
313 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
314 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
315 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
316 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
317 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
318 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
319 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
320 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
321 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
322 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
323 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
324 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
325 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
326 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
327 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
328 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
329 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
330 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
331 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
332 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
333 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
334 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
335 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
336 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
337 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
338 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
339 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
340 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
341 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
342 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
343 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
344 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
345 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
346 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
347 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
348 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
349 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
350 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
351 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
352 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
353 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
354 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
355 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
356 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
357 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
358 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
359 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
360 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
361 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
362 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
363 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
364 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
365 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
366 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
367 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
368 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
369 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
370 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
371 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
372 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
373 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
374 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
375 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
376 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
377 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
378 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
379 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
380 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
381 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
382 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
383 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
384 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
385 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
386 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
387 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
388 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
389 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
390 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
391 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
392 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
393 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
394 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
395 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
396 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
397 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
398 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
399 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
400 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
401 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
402 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
403 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
404 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
405 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
406 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
407 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
408 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
409 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
410 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
411 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
412 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
413 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
414 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
415 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
416 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
417 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
418 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
419 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
420 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
421 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
422 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
423 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
424 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
425 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
426 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
427 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
428 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
429 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
430 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
431 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
432 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
433 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
434 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
435 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
436 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
437 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
438 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
439 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
440 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
441 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
442 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
443 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
444 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
445 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
446 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
447 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
448 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
449 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
450 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
451 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
452 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
453 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
454 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
455 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
456 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
457 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
458 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
459 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
460 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
461 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
462 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
463 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
464 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
465 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
466 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
467 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
468 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
469 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
470 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
471 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
472 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
473 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
474 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
475 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
476 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
477 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
478 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
479 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
480 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
481 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
482 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
483 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
484 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
485 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
486 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
487 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
488 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
489 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
490 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
491 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
492 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
493 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
494 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
495 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
496 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
497 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
498 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
499 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
500 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
501 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
502 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
503 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
504 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
505 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
506 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
507 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
508 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
509 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
510 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988
511 org.python.python             	0x00000001000c9bac compiler_visit_expr + 2988

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000100182c80  rbx: 0x0000000000000000  rcx: 0x0000000100070ea0  rdx: 0x0000000000000002
  rdi: 0x000000010030e2a8  rsi: 0x000000010030e2a8  rbp: 0x00007fff5f400000  rsp: 0x00007fff5f400000
   r8: 0x0000000000000002   r9: 0x0000000000000006  r10: 0x0000000000000000  r11: 0x000000010005a130
  r12: 0x00000001004c03f8  r13: 0x0000000000000002  r14: 0x00000001004c0440  r15: 0x0000000000000002
  rip: 0x000000010005d734  rfl: 0x0000000000010202  cr2: 0x00007fff5f3ffff8
  
Logical CPU:     2
Error Code:      0x00000006
Trap Number:     14


Binary Images:
       0x100000000 -        0x100000fff +org.python.python (2.7.9 - 2.7.9) <8B6E6BCC-310B-E381-4F96-CD43435AE589> /Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
       0x100003000 -        0x100170ff7 +org.python.python (2.7.9, [c] 2004-2014 Python Software Foundation. - 2.7.9) <51C9254B-00A0-0B7D-4DC6-BE7C9295ECD6> /Library/Frameworks/Python.framework/Versions/2.7/Python
       0x1002f2000 -        0x1002f4ff7 +_locale.so (???) <4294AC62-5881-66AE-E045-59F50FDFBCA1> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_locale.so
    0x7fff6099c000 -     0x7fff609d2837  dyld (353.2.1) <65DCCB06-339C-3E25-9702-600A28291D0E> /usr/lib/dyld
    0x7fff87e68000 -     0x7fff87e6cfff  libcache.dylib (69) <45E9A2E7-99C4-36B2-BEE3-0C4E11614AD1> /usr/lib/system/libcache.dylib
    0x7fff8804b000 -     0x7fff88050ff7  libunwind.dylib (35.3) <BE7E51A0-B6EA-3A54-9CCA-9D88F683A6D6> /usr/lib/system/libunwind.dylib
    0x7fff88a8e000 -     0x7fff88ab6fff  libsystem_info.dylib (459) <B85A85D5-8530-3A93-B0C3-4DEC41F79478> /usr/lib/system/libsystem_info.dylib
    0x7fff88b8f000 -     0x7fff88b91fff  libsystem_configuration.dylib (699.1.5) <5E14864E-089A-3D84-85A4-980B776427A8> /usr/lib/system/libsystem_configuration.dylib
    0x7fff88d3c000 -     0x7fff88d3dfff  libDiagnosticMessagesClient.dylib (100) <2EE8E436-5CDC-34C5-9959-5BA218D507FB> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff88de7000 -     0x7fff88df8ff7  libsystem_coretls.dylib (35.1.2) <BC691CD1-17B6-39A5-BD02-AF973695FD1D> /usr/lib/system/libsystem_coretls.dylib
    0x7fff88f07000 -     0x7fff88f10fff  libsystem_pthread.dylib (105.10.1) <3103AA7F-3BAE-3673-9649-47FFD7E15C97> /usr/lib/system/libsystem_pthread.dylib
    0x7fff8942e000 -     0x7fff89430ff7  libsystem_coreservices.dylib (9) <41B7C578-5A53-31C8-A96F-C73E030B0938> /usr/lib/system/libsystem_coreservices.dylib
    0x7fff894e7000 -     0x7fff89512fff  libc++abi.dylib (125) <88A22A0F-87C6-3002-BFBA-AC0F2808B8B9> /usr/lib/libc++abi.dylib
    0x7fff8986c000 -     0x7fff89871ff7  libsystem_stats.dylib (163.10.18) <9B8CCF24-DDDB-399A-9237-4BEC225D2E8C> /usr/lib/system/libsystem_stats.dylib
    0x7fff898a5000 -     0x7fff898abfff  libsystem_trace.dylib (72.1.3) <A9E6B7D8-C327-3742-AC54-86C94218B1DF> /usr/lib/system/libsystem_trace.dylib
    0x7fff89a9d000 -     0x7fff89aa8fff  libcommonCrypto.dylib (60061) <D381EBC6-69D8-31D3-8084-5A80A32CB748> /usr/lib/system/libcommonCrypto.dylib
    0x7fff89aa9000 -     0x7fff89afdfff  libc++.1.dylib (120) <1B9530FD-989B-3174-BB1C-BDC159501710> /usr/lib/libc++.1.dylib
    0x7fff89afe000 -     0x7fff89b0fff7  libz.1.dylib (55) <88C7C7DE-04B8-316F-8B74-ACD9F3DE1AA1> /usr/lib/libz.1.dylib
    0x7fff89b10000 -     0x7fff89b13ff7  libdyld.dylib (353.2.1) <4E33E416-F1D8-3598-B8CC-6863E2ECD0E6> /usr/lib/system/libdyld.dylib
    0x7fff8a1f0000 -     0x7fff8a1f1fff  libSystem.B.dylib (1213) <90B107BC-FF74-32CC-B1CF-4E02F544D957> /usr/lib/libSystem.B.dylib
    0x7fff8a35f000 -     0x7fff8a367fff  libsystem_platform.dylib (63) <64E34079-D712-3D66-9CE2-418624A5C040> /usr/lib/system/libsystem_platform.dylib
    0x7fff8a512000 -     0x7fff8a588fe7  libcorecrypto.dylib (233.1.2) <E1789801-3985-3949-B736-6B3378873301> /usr/lib/system/libcorecrypto.dylib
    0x7fff8bd61000 -     0x7fff8bd68ff7  libcompiler_rt.dylib (35) <BF8FC133-EE10-3DA6-9B90-92039E28678F> /usr/lib/system/libcompiler_rt.dylib
    0x7fff8c3c4000 -     0x7fff8c3caff7  libsystem_networkextension.dylib (167.1.10) <29AB225B-D7FB-30ED-9600-65D44B9A9442> /usr/lib/system/libsystem_networkextension.dylib
    0x7fff8d0f2000 -     0x7fff8d0f2ff7  libunc.dylib (29) <5676F7EA-C1DF-329F-B006-D2C3022B7D70> /usr/lib/system/libunc.dylib
    0x7fff8e4ba000 -     0x7fff8e500ff7  libauto.dylib (186) <A260789B-D4D8-316A-9490-254767B8A5F1> /usr/lib/libauto.dylib
    0x7fff8e8ee000 -     0x7fff8e8f6fff  libsystem_dnssd.dylib (561.1.1) <62B70ECA-E40D-3C63-896E-7F00EC386DDB> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff8efcd000 -     0x7fff8efeafff  libsystem_kernel.dylib (2782.10.72) <97CD7ACD-EA0C-3434-BEFC-FCD013D6BB73> /usr/lib/system/libsystem_kernel.dylib
    0x7fff8ff7b000 -     0x7fff8ff7bff7  libkeymgr.dylib (28) <77845842-DE70-3CC5-BD01-C3D14227CED5> /usr/lib/system/libkeymgr.dylib
    0x7fff90a05000 -     0x7fff90a91ff7  libsystem_c.dylib (1044.10.1) <199ED5EB-77A1-3D43-AA51-81779CE0A742> /usr/lib/system/libsystem_c.dylib
    0x7fff90a92000 -     0x7fff90e28fff  com.apple.CoreFoundation (6.9 - 1152) <CBD1591C-405E-376E-87E9-B264610EBF49> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff919c4000 -     0x7fff919fcffb  libsystem_network.dylib (411.1) <2EC3A005-473F-3C36-A665-F88B5BACC7F0> /usr/lib/system/libsystem_network.dylib
    0x7fff9208f000 -     0x7fff92091ff7  libsystem_sandbox.dylib (358.1.1) <95312E09-DA28-324A-A084-F3E574D0210E> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff9233a000 -     0x7fff9236afff  libsystem_m.dylib (3086.1) <1E12AB45-6D96-36D0-A226-F24D9FB0D9D6> /usr/lib/system/libsystem_m.dylib
    0x7fff9236b000 -     0x7fff92393fff  libxpc.dylib (559.10.3) <876216DC-D5D3-381E-8AF9-49AE464E5107> /usr/lib/system/libxpc.dylib
    0x7fff92680000 -     0x7fff92681fff  libsystem_secinit.dylib (18) <581DAD0F-6B63-3A48-B63B-917AF799ABAA> /usr/lib/system/libsystem_secinit.dylib
    0x7fff92f9a000 -     0x7fff92f9aff7  liblaunch.dylib (559.10.3) <DFCDEBDF-8247-3DC7-9879-E7E497DDA4B4> /usr/lib/system/liblaunch.dylib
    0x7fff92f9b000 -     0x7fff92fb1ff7  libsystem_asl.dylib (267) <F153AC5B-0542-356E-88C8-20A62CA704E2> /usr/lib/system/libsystem_asl.dylib
    0x7fff93ed9000 -     0x7fff93ef5ff7  libsystem_malloc.dylib (53.1.1) <19BCC257-5717-3502-A71F-95D65AFA861B> /usr/lib/system/libsystem_malloc.dylib
    0x7fff93fd8000 -     0x7fff93fddff7  libmacho.dylib (862) <126CA2ED-DE91-308F-8881-B9DAEC3C63B6> /usr/lib/system/libmacho.dylib
    0x7fff94003000 -     0x7fff9400bffb  libcopyfile.dylib (118.1.2) <0C68D3A6-ACDD-3EF3-991A-CC82C32AB836> /usr/lib/system/libcopyfile.dylib
    0x7fff94241000 -     0x7fff9443b46f  libobjc.A.dylib (647) <759E155D-BC42-3D4E-869B-6F57D477177C> /usr/lib/libobjc.A.dylib
    0x7fff944ba000 -     0x7fff944c3ff7  libsystem_notify.dylib (133.1.1) <61147800-F320-3DAA-850C-BADF33855F29> /usr/lib/system/libsystem_notify.dylib
    0x7fff944c4000 -     0x7fff944eeff7  libdispatch.dylib (442.1.4) <502CF32B-669B-3709-8862-08188225E4F0> /usr/lib/system/libdispatch.dylib
    0x7fff95c6e000 -     0x7fff95c6fffb  libremovefile.dylib (35) <3485B5F4-6CE8-3C62-8DFD-8736ED6E8531> /usr/lib/system/libremovefile.dylib
    0x7fff95e69000 -     0x7fff95e6bff7  libquarantine.dylib (76) <DC041627-2D92-361C-BABF-A869A5C72293> /usr/lib/system/libquarantine.dylib
    0x7fff96290000 -     0x7fff96475ff3  libicucore.A.dylib (531.31) <B08E00D5-13C6-3391-AB3A-8DE693D3B42E> /usr/lib/libicucore.A.dylib
    0x7fff97443000 -     0x7fff97444ff7  libsystem_blocks.dylib (65) <9615D10A-FCA7-3BE4-AA1A-1B195DACE1A1> /usr/lib/system/libsystem_blocks.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 1
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 7502283
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=83.7M resident=73.1M(87%) swapped_out_or_unallocated=10.5M(13%)
Writable regions: Total=323.1M written=239.8M(74%) resident=255.3M(79%) swapped_out=0K(0%) unallocated=67.8M(21%)
 
REGION TYPE                      VIRTUAL
===========                      =======
Kernel Alloc Once                     4K
MALLOC                            314.8M
MALLOC (admin)                       16K
STACK GUARD                        56.0M
Stack                              8192K
VM_ALLOCATE                           8K
__DATA                             1440K
__LINKEDIT                         70.8M
__TEXT                             12.8M
__UNICODE                           544K
shared memory                         4K
===========                      =======
TOTAL                             464.4M

Model: MacBookPro8,2, BootROM MBP81.0047.B27, 4 processors, Intel Core i7, 2.5 GHz, 8 GB, SMC 1.69f4
Graphics: Intel HD Graphics 3000, Intel HD Graphics 3000, Built-In, 512 MB
Graphics: AMD Radeon HD 6770M, AMD Radeon HD 6770M, PCIe, 1024 MB
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80AD, 0x484D54333531533642465238432D48392020
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1333 MHz, 0x80AD, 0x484D54333531533642465238432D48392020
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xD6), Broadcom BCM43xx 1.0 (5.106.98.100.24)
Bluetooth: Version 4.3.2f6 15235, 3 services, 19 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en1
Serial ATA Device: Hitachi HTS727575A9E362, 750.16 GB
Serial ATA Device: HL-DT-ST DVDRW  GS31N
USB Device: Hub
USB Device: IR Receiver
USB Device: FaceTime HD Camera (Built-in)
USB Device: Hub
USB Device: BRCM2070 Hub
USB Device: Bluetooth USB Host Controller
USB Device: Apple Internal Keyboard / Trackpad
Thunderbolt Bus: MacBook Pro, Apple Inc., 22.1

----------
components: Macintosh
files: test.py
messages: 237889
nosy: Michael Klein, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Segmentation Fault with Large Simple Function
versions: Python 2.7
Added file: http://bugs.python.org/file38446/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23643>
_______________________________________

From report at bugs.python.org  Wed Mar 11 21:41:57 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 11 Mar 2015 20:41:57 +0000
Subject: [issue23633] Improve py launcher help, index, and doc
In-Reply-To: <1426026714.29.0.122233634927.issue23633@psf.upfronthosting.co.za>
Message-ID: <1426106517.24.0.694296731665.issue23633@psf.upfronthosting.co.za>


Steve Dower added the comment:

For a per-user install, the launcher does not go in C:\Windows (note that Python 3.4 does not really have per-users installs). The correct location for the ini file in every case is alongside the executable, and it must always be named "py.ini".

py.exe is put into C:\Windows because that directory will always be on PATH and has no 32-bit/64-bit redirection. The next best location would be a subdirectory of %CommonProgramFiles% and %CommonProgramFiles(x86)% and we'd probably need to install it twice.

The access denied message you got was because %LocalAppData% is a directory. Try doing:

> notepad %localappdata%\test.txt

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23633>
_______________________________________

From report at bugs.python.org  Wed Mar 11 22:00:10 2015
From: report at bugs.python.org (Nathan Jensen)
Date: Wed, 11 Mar 2015 21:00:10 +0000
Subject: [issue14436] SocketHandler sends obejcts while they cannot be
 unpickled on receiver's side
In-Reply-To: <1333015391.87.0.193286932611.issue14436@psf.upfronthosting.co.za>
Message-ID: <1426107610.66.0.214034272028.issue14436@psf.upfronthosting.co.za>


Nathan Jensen added the comment:

I'm not sure this was fixed in an optimal way.

We have a set of processes using the SocketHandler to send log records to a single log process.  Some of these log records have the msg attribute as a dictionary that contained a variety of extra information about the event that was being logged.  After this change, our process receiving the events and logging to a file stopped working correctly because it was expecting a dictionary for the msg but was always receiving a string.  (I have since made it smarter).

The fix for this ticket makes sense when you don't have a guarantee of being able to unpickle the msg on the receiving end, but it also limits some of the adaptability to pass objects using the SocketHandler.

Some possible improvements:
1. Add a flag to SocketHandler on whether or not it should force the msg to a string
2. If it's it a built-in picklable type, don't force to string, else force msg to string

Suggestion 2 has some drawbacks in that you'd have to loop over lists, dictionaries, etc to verify everything inside there is also picklable.  Also it would prevent you from sending custom objects across.

----------
nosy: +Nathan Jensen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14436>
_______________________________________

From report at bugs.python.org  Wed Mar 11 22:38:26 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 Mar 2015 21:38:26 +0000
Subject: [issue23615] Reloading tokenize breaks tokenize.open()
In-Reply-To: <1426088100.17.0.012869707648.issue23615@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYuMYA-1Lx8v-Czz5PNzHo-YUsmedL6Niab0UVFE1-vWw@mail.gmail.com>


STINNER Victor added the comment:

Is there a method to detect other reload bugs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23615>
_______________________________________

From report at bugs.python.org  Wed Mar 11 22:50:00 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 11 Mar 2015 21:50:00 +0000
Subject: [issue23643] Segmentation Fault with Large Simple Function
In-Reply-To: <1426094044.96.0.525794841659.issue23643@psf.upfronthosting.co.za>
Message-ID: <1426110600.06.0.492167520245.issue23643@psf.upfronthosting.co.za>


Ned Deily added the comment:

Isn't this a duplicate of Issue5765 and Issue11383?

----------
nosy:  -ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23643>
_______________________________________

From report at bugs.python.org  Wed Mar 11 22:50:39 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 11 Mar 2015 21:50:39 +0000
Subject: [issue23643] Segmentation Fault with Large Simple Function
In-Reply-To: <1426094044.96.0.525794841659.issue23643@psf.upfronthosting.co.za>
Message-ID: <1426110639.29.0.175396117953.issue23643@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy:  -ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23643>
_______________________________________

From report at bugs.python.org  Wed Mar 11 22:51:03 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 11 Mar 2015 21:51:03 +0000
Subject: [issue23643] Segmentation Fault with Large Simple Function
In-Reply-To: <1426094044.96.0.525794841659.issue23643@psf.upfronthosting.co.za>
Message-ID: <1426110663.97.0.294256196179.issue23643@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
components:  -Macintosh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23643>
_______________________________________

From report at bugs.python.org  Wed Mar 11 22:54:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Mar 2015 21:54:20 +0000
Subject: [issue23615] Reloading tokenize breaks tokenize.open()
In-Reply-To: <1425864069.02.0.403381374988.issue23615@psf.upfronthosting.co.za>
Message-ID: <1426110860.08.0.169500936019.issue23615@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Only grep.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23615>
_______________________________________

From report at bugs.python.org  Wed Mar 11 23:18:53 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 11 Mar 2015 22:18:53 +0000
Subject: [issue23638] shutil.copytree makedirs exception
In-Reply-To: <1426070507.27.0.472685674051.issue23638@psf.upfronthosting.co.za>
Message-ID: <1426112333.24.0.0798962934896.issue23638@psf.upfronthosting.co.za>


Martin Panter added the comment:

In case it?s not clear to others, the first bit of code is from the shutil.copytree() implementation at Lib/shutil.py:303.

The documentation currently says ?The destination directory . . . must not already exist?. Yuriy seems to be proposing to make copytree() use the existing destination directory, and only create it if it does not already exist. Perhaps you might be interested in Issue 20849, which proposes passing the os.makedirs(exist_ok=...) flag through, which would allow this functionality in a backwards-compatible way.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23638>
_______________________________________

From report at bugs.python.org  Thu Mar 12 00:32:38 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 11 Mar 2015 23:32:38 +0000
Subject: [issue23641] Got rid of bad dunder names
In-Reply-To: <1426084934.72.0.0668161558437.issue23641@psf.upfronthosting.co.za>
Message-ID: <1426116758.89.0.414199795203.issue23641@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?m not very familiar with the mock module so can't comment if removing div is sensible there. But all the other changes seem reasonable. I just left a few suggestions for further tweaks on Rietveld.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23641>
_______________________________________

From report at bugs.python.org  Thu Mar 12 00:38:57 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 11 Mar 2015 23:38:57 +0000
Subject: [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1426117137.5.0.22387678085.issue23639@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23639>
_______________________________________

From report at bugs.python.org  Thu Mar 12 01:51:09 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 12 Mar 2015 00:51:09 +0000
Subject: [issue23088] Document that PyUnicode_AsUTF8() returns a
 null-terminated string
In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>
Message-ID: <1426121469.76.0.747118856014.issue23088@psf.upfronthosting.co.za>


Martin Panter added the comment:

Posting a new patch updating the documentation for some of the extra functions Serhiy mentioned. Also changed references of ?NUL?, ?nul? and ?0? characters to ?null?. I?m not very familiar with Python?s C API, so I am mainly relying on what you guys say without much of my own verification. But if there are other related doc fixes you can think of, I?m happy to include them.

The PyUnicode_AsWideCharString() function already seems to document null termination well enough, so I did not change it. Let me know if you had a specific change in mind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23088>
_______________________________________

From report at bugs.python.org  Thu Mar 12 01:51:22 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 12 Mar 2015 00:51:22 +0000
Subject: [issue23088] Document that PyUnicode_AsUTF8() returns a
 null-terminated string
In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>
Message-ID: <1426121482.17.0.368321839984.issue23088@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Added file: http://bugs.python.org/file38448/utf8-null.v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23088>
_______________________________________

From report at bugs.python.org  Thu Mar 12 03:18:26 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 12 Mar 2015 02:18:26 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1426126706.83.0.699340055638.issue1553375@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

The functionality described here certainly seems wanted and there's been some other work on the traceback module recently so could we get this into 3.5?

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Thu Mar 12 03:27:48 2015
From: report at bugs.python.org (Ben Hoyt)
Date: Thu, 12 Mar 2015 02:27:48 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1426127268.9.0.150696057901.issue23605@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

@Scott Dial: just a response about this benchmark: note that this benchmark isn't really valid, as it says "Using slower ctypes version of scandir", which is the slow all-Python version. You want it to be saying "Using Python 3.5's builtin os.scandir()".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Thu Mar 12 03:53:49 2015
From: report at bugs.python.org (Ben Hoyt)
Date: Thu, 12 Mar 2015 02:53:49 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1426128829.99.0.763230702833.issue23605@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

To Victor and Serhiy:

1) Serhiy's point about not needing to build the symlinks set when followlinks is True is a good one, because it'll never get used. Just a "if not followlinks: ..." around that try/except would do it. Though this is a small optimization, as I expect 95% of people use os.walk() with followlinks=False, which is the default.

2) Much as I don't want to admit it :-), I think Serhiy has a point regarding the change in behaviour. Can we accept this tiny change? This happens because the previous implementation of os.walk() calls path.islink(), which does a real syscall, after the yield returns.

So if the caller modifies "dirnames" and adds a symlink to a directory it won't be in the symlinks set. Or if (as Serhiy's example shows) they change a symlink-to-a-directory to a directory the new implementation doesn't do another syscall to check, so differs from the old one -- in Serhiy's example, the old os.walk() will recurse into the changed symlink-to-a-directory-that's-now-a-directory, whereas the new os.walk() won't recurse.

Arguably the new behaviour is just as good here, but it is different. And Serhiy's function unsymlink() is a reasonable example of how this might play out.

The os.walk() docs explicitly allow modifying "dirnames" -- not just removing and reordering, but also adding entries, which could surface the difference in behaviour: "the caller can modify the dirnames list in-place ... even to inform walk() about directories the caller creates or renames before it resumes walk() again". See here:

https://docs.python.org/3.4/library/os.html#os.walk

So I do think it's a real issue. Will this really be an issue in practice? I don't know; I'm tempted to think not.

Obviously if we have to call stat/islink again, it defeats half of the purpose of scandir. But I don't see a way around it if we want to keep the exact old os.walk() behaviour. We could fix the behaviour if a directory/symlink was added to "dirnames" fairly easily by testing whether it changed, but I don't see a way to fix the unsymlinks() example without a syscall.

Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Thu Mar 12 03:56:38 2015
From: report at bugs.python.org (Ben Hoyt)
Date: Thu, 12 Mar 2015 02:56:38 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1426128998.12.0.798475925215.issue23605@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

Note specifically in the unsymlink() example Serhiy gave, you probably don't *want* os.walk() to recurse into a symlink-to-a-directory-that's-changed-to-a-directory, and you probably haven't thought about it doing so, so maybe the new behaviour is fine?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Thu Mar 12 05:54:22 2015
From: report at bugs.python.org (Michael Klein)
Date: Thu, 12 Mar 2015 04:54:22 +0000
Subject: [issue23643] Segmentation Fault with Large Simple Function
In-Reply-To: <1426094044.96.0.525794841659.issue23643@psf.upfronthosting.co.za>
Message-ID: <1426136062.5.0.338084422509.issue23643@psf.upfronthosting.co.za>


Changes by Michael Klein <michael14486 at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23643>
_______________________________________

From report at bugs.python.org  Thu Mar 12 06:25:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 12 Mar 2015 05:25:41 +0000
Subject: [issue1173475] __slots__ for subclasses of variable length types
Message-ID: <1426137941.41.0.176718303709.issue1173475@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1173475>
_______________________________________

From report at bugs.python.org  Thu Mar 12 06:27:03 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 12 Mar 2015 05:27:03 +0000
Subject: [issue17295] __slots__ on PyVarObject subclass
In-Reply-To: <1361809462.28.0.456255129432.issue17295@psf.upfronthosting.co.za>
Message-ID: <1426138023.19.0.650033956275.issue17295@psf.upfronthosting.co.za>


Martin Panter added the comment:

Encountered this when trying to add some fields to urllib.parse.SplitResult for Issue 22852. Issue 1173475 has a patch; I haven?t tried using it though.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17295>
_______________________________________

From report at bugs.python.org  Thu Mar 12 07:21:17 2015
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 12 Mar 2015 06:21:17 +0000
Subject: [issue22928] HTTP header injection in
 urrlib2/urllib/httplib/http.client
In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za>
Message-ID: <1426141277.8.0.26332251269.issue22928@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


Added file: http://bugs.python.org/file38449/issue22928_6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22928>
_______________________________________

From report at bugs.python.org  Thu Mar 12 08:05:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Mar 2015 07:05:01 +0000
Subject: [issue22928] HTTP header injection in
 urrlib2/urllib/httplib/http.client
In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za>
Message-ID: <1426143901.18.0.0330728497769.issue22928@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'll return previous implementation of header value regex. All other LGTM.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22928>
_______________________________________

From report at bugs.python.org  Thu Mar 12 09:13:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Mar 2015 08:13:04 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <20150312081301.30072.80709@psf.io>


Roundup Robot added the comment:

New changeset 1a972140ab62 by Victor Stinner in branch 'default':
Issue #23605: os.walk() doesn't need to call entry.is_symlink() if followlinks
https://hg.python.org/cpython/rev/1a972140ab62

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Thu Mar 12 10:11:48 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 09:11:48 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1426151508.48.0.252466899429.issue23605@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> 1) Serhiy's point about not needing to build the symlinks set when followlinks is True is a good one, because it'll never get used. Just a "if not followlinks: ..." around that try/except would do it. Though this is a small optimization, as I expect 95% of people use os.walk() with followlinks=False, which is the default.

No, it's not a "small optimization". I/O are expensive, especially disk I/O. Try os.walk() on a NFS share with the cache disabled ;-)

> My first note was about efficiency of the implementation. When followlinks is 
> true, you can avoid testing entry.is_link() and creating the symlinks set.

Oh, I misunderstood your comment. The changeset 1a972140ab62 avoids calling entry.is_symlink() when it's not needed. Thanks for the report.

--

walk_added_symlink_to_dir.patch: Small modification to os.walk() to keep the performances of os.scandir() *and* still supported adding symlinks to dirs (no backward compatibility changes).

Happy? :-)

I started to work on an unit test, but I don't understand how WalkTests and FwalkTests are written.

The setUp() method contais unit tests?! For example, setUp() has a unit test removing a directory from the dirs list to check os.walk() behaviour.

I will try harder to understand how these tests are written and post a patch for tests later.

----------
Added file: http://bugs.python.org/file38450/walk_added_symlink_to_dir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Thu Mar 12 10:16:13 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Mar 2015 09:16:13 +0000
Subject: [issue22928] HTTP header injection in
 urrlib2/urllib/httplib/http.client
In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za>
Message-ID: <20150312091610.32085.29865@psf.io>


Roundup Robot added the comment:

New changeset 1c45047c5102 by Serhiy Storchaka in branch '2.7':
Issue #22928: Disabled HTTP header injections in httplib.
https://hg.python.org/cpython/rev/1c45047c5102

New changeset bf3e1c9b80e9 by Serhiy Storchaka in branch '3.4':
Issue #22928: Disabled HTTP header injections in http.client.
https://hg.python.org/cpython/rev/bf3e1c9b80e9

New changeset aa4c6992c126 by Serhiy Storchaka in branch 'default':
Issue #22928: Disabled HTTP header injections in http.client.
https://hg.python.org/cpython/rev/aa4c6992c126

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22928>
_______________________________________

From report at bugs.python.org  Thu Mar 12 10:21:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Mar 2015 09:21:27 +0000
Subject: [issue22928] HTTP header injection in
 urrlib2/urllib/httplib/http.client
In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za>
Message-ID: <1426152087.23.0.382286203816.issue22928@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added new tests and tweaked regexpes. Thank you for your contribution Demian.

Now we can start long-standing deprecation process for conforming to RFC.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22928>
_______________________________________

From report at bugs.python.org  Thu Mar 12 10:25:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Mar 2015 09:25:59 +0000
Subject: [issue17322] urllib.request add_header() currently allows trailing
 spaces (and other weird stuff)
In-Reply-To: <1362086834.26.0.0452612015515.issue17322@psf.upfronthosting.co.za>
Message-ID: <1426152359.9.0.525787109007.issue17322@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Trailing spaces, newlines and like were disabled in put_header() in issue22928. Now we can start long-standing deprecation process for headers that don't conform RFC 7230.

----------
nosy: +serhiy.storchaka
stage: commit review -> needs patch
versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17322>
_______________________________________

From report at bugs.python.org  Thu Mar 12 10:32:35 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Mar 2015 09:32:35 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <20150312093232.27371.88880@psf.io>


Roundup Robot added the comment:

New changeset c06ebb57d4ed by Victor Stinner in branch '3.4':
Issue #23605: Refactor os.walk() tests to also run them on os.fwalk()
https://hg.python.org/cpython/rev/c06ebb57d4ed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Thu Mar 12 10:40:16 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 09:40:16 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1426153215.99.0.200364847835.issue23605@psf.upfronthosting.co.za>


STINNER Victor added the comment:

walk_added_symlink_to_dir-2.patch: Ok, here is a new patch, now with tests.

Without the fix on os.walk(), WalkTests.test_add_dir_symlink() fails, whereas FwalkTests.test_add_dir_symlink() pass.

----------
Added file: http://bugs.python.org/file38451/walk_added_symlink_to_dir-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Thu Mar 12 10:43:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Mar 2015 09:43:22 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1426153402.66.0.354107816195.issue23605@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Happy? :-)

No, it doesn't fix my example. :-(

I see following possibilities:

1. Partially revert the patch and always call path.islink(). I will not kill all the benefit of using os.scandir(), because there is a benefit from avoiding path.isdir() and in any case in large directories most content is usually files, not dirs.

2. Accept and document behavior change. This will break someone's code. :-(

3. Left os.walk as was (or only partially optimized as in 1), and add a new function with new behavior.

4. Add new boolean parameter that control behavior to os.walk().

5. Try to detect when dir list or filesystem were changed. Victor's patch does the first. For the second we can check if top directory inode and mtime were changed. But I afraid this wouldn't decrease a number of system calls.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Thu Mar 12 12:34:31 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 11:34:31 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1426160071.51.0.120301428166.issue23605@psf.upfronthosting.co.za>


STINNER Victor added the comment:

And now something completly differenet: fast_bottom-up.patch, fast bottom-up, but "slow" top-down.

In bottom-up mode (topdown=False), use entry.path and entry.is_symlink() => optimization compared to Python 3.4 (avoid one call to os.stat()).

In top-down mode (topdown=True, default), use os.path.join() and os.path.islink() => no change compared to Python 3.4 on this part. More globally, os.walk() should still be much faster in Python 3.5 than in Python 3.5 thanks to entry.is_dir() which avoids a call to os.path.isdir() (and so os.stat()).

Correctness matters more than performances!

> 2. Accept and document behavior change. This will break someone's code. :-(
> 3. Left os.walk as was (or only partially optimized as in 1), and add a new function with new behavior.
> 4. Add new boolean parameter that control behavior to os.walk().

Sorry but all these options sucks :-p

> 5. Try to detect when dir list or filesystem were changed. Victor's patch does the first. For the second we can check if top directory inode and mtime were changed. But I afraid this wouldn't decrease a number of system calls.

By experience, it's very hard to write portable code. Even if we find a way to detect FS change on some platforms, it will not work on some other platforms.

----------
Added file: http://bugs.python.org/file38452/fast_bottom-up.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Thu Mar 12 13:05:56 2015
From: report at bugs.python.org (yuriy_levchenko)
Date: Thu, 12 Mar 2015 12:05:56 +0000
Subject: [issue23638] shutil.copytree makedirs exception
In-Reply-To: <1426070507.27.0.472685674051.issue23638@psf.upfronthosting.co.za>
Message-ID: <1426161956.72.0.547133918967.issue23638@psf.upfronthosting.co.za>


yuriy_levchenko added the comment:

Thanks for the clarifications. Yes parameter will be a good solution!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23638>
_______________________________________

From report at bugs.python.org  Thu Mar 12 13:19:57 2015
From: report at bugs.python.org (yuriy_levchenko)
Date: Thu, 12 Mar 2015 12:19:57 +0000
Subject: [issue23638] shutil.copytree makedirs exception
In-Reply-To: <1426070507.27.0.472685674051.issue23638@psf.upfronthosting.co.za>
Message-ID: <1426162797.28.0.626888710497.issue23638@psf.upfronthosting.co.za>


Changes by yuriy_levchenko <levchenko.yuriy.vladimirovich at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23638>
_______________________________________

From report at bugs.python.org  Thu Mar 12 13:52:36 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Mar 2015 12:52:36 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <1426164756.17.0.00371300965952.issue23632@psf.upfronthosting.co.za>


R. David Murray added the comment:

Aren't there wider implications of python starting to support tuple indexing?  If we make this work, aren't people going to expect [[1,2], [3,4]][0,1] to work?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Thu Mar 12 13:57:38 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Mar 2015 12:57:38 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <1426165058.32.0.716215839789.issue23632@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> If we make this work, aren't people going to expect [[1,2], [3,4]][0,1] to work?

Or even [[1,2], [3,4]][*(0,1)] :-)

But seriously, I don't know. memorview is a pretty specialized object, its semantics have more to do with Numpy (which has been a major inspiration and use case for the buffer protocol's design) than standard Python containers. I wouldn't expect a list of lists to support tuple indexing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Thu Mar 12 14:02:51 2015
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 12 Mar 2015 13:02:51 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <1426165371.52.0.0504648915116.issue23632@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Multi-dimensional slicing is explicitly mentioned in PEP-3118, so
I guess the intention was to cover this use case as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Thu Mar 12 14:04:27 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Mar 2015 13:04:27 +0000
Subject: [issue23637] Warnings error with non-ascii chars.
In-Reply-To: <1426062904.63.0.0951614232281.issue23637@psf.upfronthosting.co.za>
Message-ID: <1426165467.87.0.0887269708999.issue23637@psf.upfronthosting.co.za>


R. David Murray added the comment:

Can you provide a complete failure example?  If message is unicode, the format string should (in python2) be auto-promoted to unicode.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23637>
_______________________________________

From report at bugs.python.org  Thu Mar 12 14:06:52 2015
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 12 Mar 2015 13:06:52 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <1426165612.11.0.767959087858.issue23632@psf.upfronthosting.co.za>


Stefan Krah added the comment:

To be sure, the PEP contains some odd proposals like "Unpacking a long-double will return a decimal object", but the one in this issue seems reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Thu Mar 12 14:07:10 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Mar 2015 13:07:10 +0000
Subject: [issue23638] shutil.copytree makedirs exception
In-Reply-To: <1426070507.27.0.472685674051.issue23638@psf.upfronthosting.co.za>
Message-ID: <1426165630.89.0.333320435724.issue23638@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> add exist_ok to shutil.copytree

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23638>
_______________________________________

From report at bugs.python.org  Thu Mar 12 14:26:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Mar 2015 13:26:23 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <1426166783.05.0.807867990444.issue23632@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be add support of multi-dimensional sub-views?

>>> m = memoryview(bytearray(range(12)))
>>> m2 = m.cast('B', (3,4))
>>> m2[0]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NotImplementedError: multi-dimensional sub-views are not implemented

Then we could use m2[0][1].

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Thu Mar 12 14:35:56 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Mar 2015 13:35:56 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <1426167356.3.0.177542010249.issue23632@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Sub-views are not as easily implemented. Besides, they create an intermediate object which is immediately thrown away. And tuple indexing is a very common idiom in the Numpy universe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Thu Mar 12 14:43:22 2015
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 12 Mar 2015 13:43:22 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <1426167802.4.0.675981420488.issue23632@psf.upfronthosting.co.za>


Stefan Krah added the comment:

sub-views and multi-dimensional slicing are not that bad: They're already implemented in _testbuffer (indeed with intermediate objects though).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Thu Mar 12 14:44:10 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Mar 2015 13:44:10 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <1426167850.83.0.263268164507.issue23632@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Well, we could certainly do both :) I don't think we should weigh this issue with separate features, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Thu Mar 12 14:46:50 2015
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 12 Mar 2015 13:46:50 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <1426168010.69.0.147791012543.issue23632@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Yes, to be clear I'm +1 on this specific feature -- and separate issues. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Thu Mar 12 15:22:24 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 12 Mar 2015 14:22:24 +0000
Subject: [issue23642] Interaction of ModuleSpec and C Extension Modules
In-Reply-To: <1426086531.98.0.531682777516.issue23642@psf.upfronthosting.co.za>
Message-ID: <1426170144.27.0.171699804337.issue23642@psf.upfronthosting.co.za>


Brett Cannon added the comment:

There is a proposed PEP on the import-sig: https://mail.python.org/pipermail/import-sig/2015-March/000904.html . I'm hoping to add it for the author to the PEP index on Friday.

Basically we punted on extension modules as we ran out of time in Python 3.4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23642>
_______________________________________

From report at bugs.python.org  Thu Mar 12 15:24:50 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 12 Mar 2015 14:24:50 +0000
Subject: [issue23625] load_module() docs: zipped eggs are not loaded.
In-Reply-To: <1425986086.94.0.227506635369.issue23625@psf.upfronthosting.co.za>
Message-ID: <1426170290.43.0.385761366212.issue23625@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I understood what you asked. My point is that mentioning eggs in the imp doesn't make sense since the imp module nor import supports them natively. Eggs are a setuptools thing, not a Python standard library thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23625>
_______________________________________

From report at bugs.python.org  Thu Mar 12 15:28:45 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Mar 2015 14:28:45 +0000
Subject: [issue10967] move regrtest over to using more unittest infrastructure
In-Reply-To: <1295567145.8.0.568957178125.issue10967@psf.upfronthosting.co.za>
Message-ID: <1426170525.27.0.517412869822.issue10967@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10967>
_______________________________________

From report at bugs.python.org  Thu Mar 12 15:32:32 2015
From: report at bugs.python.org (David Beazley)
Date: Thu, 12 Mar 2015 14:32:32 +0000
Subject: [issue23642] Interaction of ModuleSpec and C Extension Modules
In-Reply-To: <1426086531.98.0.531682777516.issue23642@psf.upfronthosting.co.za>
Message-ID: <1426170752.73.0.241518215843.issue23642@psf.upfronthosting.co.za>


David Beazley added the comment:

This is great news.   Read the PEP draft and think this is a very good thing to be addressing. Thanks, Brett.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23642>
_______________________________________

From report at bugs.python.org  Thu Mar 12 15:33:21 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Mar 2015 14:33:21 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>
Message-ID: <20150312143318.70288.399@psf.io>


Roundup Robot added the comment:

New changeset e78de5b1e3ef by Victor Stinner in branch 'default':
Issue #23566: enable(), register(), dump_traceback() and dump_traceback_later()
https://hg.python.org/cpython/rev/e78de5b1e3ef

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23566>
_______________________________________

From report at bugs.python.org  Thu Mar 12 15:36:01 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 14:36:01 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>
Message-ID: <1426170961.82.0.536537431885.issue23566@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Let me know if there is possible further improvement in this patch.

I was going to push your change, but I noticed that you use stderr.fileno() in tests. I modified the test to use a different file descriptor. sys.stderr is also the default value, so the test may pass because the file descriptor was ignored (if there was a bug in your change, which is not the case).

I pushed the modified patch.

Thanks for your contribution Wei Wu!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23566>
_______________________________________

From report at bugs.python.org  Thu Mar 12 15:55:47 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 14:55:47 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>
Message-ID: <1426172147.39.0.328347208042.issue23566@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oops, I forgot Windows. On Windows, we should maybe use stderr.fileno() and avoid pass_fds.

(Or maybe just skip the tests on Windows?)

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/5828/steps/test/logs/stdio

======================================================================
FAIL: test_dump_traceback_fd (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_faulthandler.py", line 378, in test_dump_traceback_fd
    self.check_dump_traceback(fd=fp.fileno())
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_faulthandler.py", line 365, in check_dump_traceback
    trace, exitcode = self.get_output(code, filename, fd)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_faulthandler.py", line 60, in get_output
    process = script_helper.spawn_python('-c', code, pass_fds=pass_fds)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\script_helper.py", line 136, in spawn_python
    **kw)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\subprocess.py", line 855, in __init__
    restore_signals, start_new_session)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\subprocess.py", line 1096, in _execute_child
    assert not pass_fds, "pass_fds not supported on Windows."
AssertionError: pass_fds not supported on Windows.

======================================================================
FAIL: test_enable_fd (test.test_faulthandler.FaultHandlerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_faulthandler.py", line 235, in test_enable_fd
    fd=fd)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_faulthandler.py", line 106, in check_fatal_error
    output, exitcode = self.get_output(code, filename=filename, fd=fd)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_faulthandler.py", line 60, in get_output
    process = script_helper.spawn_python('-c', code, pass_fds=pass_fds)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\script_helper.py", line 136, in spawn_python
    **kw)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\subprocess.py", line 855, in __init__
    restore_signals, start_new_session)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\subprocess.py", line 1096, in _execute_child
    assert not pass_fds, "pass_fds not supported on Windows."
AssertionError: pass_fds not supported on Windows.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23566>
_______________________________________

From report at bugs.python.org  Thu Mar 12 15:59:00 2015
From: report at bugs.python.org (Joshua J Cogliati)
Date: Thu, 12 Mar 2015 14:59:00 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_swig_compile_fails_with_=E2=80=98=5FAtomic?=
 =?utf-8?q?=E2=80=99_does_not_name_a_type?=
Message-ID: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>


New submission from Joshua J Cogliati:

The attached example works fine with Python 3.4.2, but fails with Python 3.5.0a1 and 3.5.0a2

I am using:
$ g++ --version
g++ (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)
$ swig -version

SWIG Version 3.0.5

Compiled with g++ [x86_64-redhat-linux-gnu]

Configured options: +pcre
$ python3 --version
Python 3.5.0a2



The output of trying the makefile with Python 3.5.0a2 is:

$ make
swig -c++ -python -py3 example.i
g++ -g -fPIC -c example.cxx example_wrap.cxx -I/local/python350a2/include/python3.5m -I/local/python350a2/include/python3.5m
In file included from /local/python350a2/include/python3.5m/pyatomic.h:10:0,
                 from /local/python350a2/include/python3.5m/Python.h:53,
                 from example_wrap.cxx:154:
/usr/include/c++/4.9.2/exception:161:34: error: missing binary operator before token "("
 #if (__cplusplus >= 201103L) && (ATOMIC_INT_LOCK_FREE > 1)
                                  ^
In file included from /local/python350a2/include/python3.5m/pyatomic.h:10:0,
                 from /local/python350a2/include/python3.5m/Python.h:53,
                 from example_wrap.cxx:154:
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:40:9: error: ?_Atomic? does not name a type
 typedef _Atomic _Bool atomic_bool;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:41:9: error: ?_Atomic? does not name a type
 typedef _Atomic char atomic_char;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:42:9: error: ?_Atomic? does not name a type
 typedef _Atomic signed char atomic_schar;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:43:9: error: ?_Atomic? does not name a type
 typedef _Atomic unsigned char atomic_uchar;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:44:9: error: ?_Atomic? does not name a type
 typedef _Atomic short atomic_short;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:45:9: error: ?_Atomic? does not name a type
 typedef _Atomic unsigned short atomic_ushort;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:46:9: error: ?_Atomic? does not name a type
 typedef _Atomic int atomic_int;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:47:9: error: ?_Atomic? does not name a type
 typedef _Atomic unsigned int atomic_uint;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:48:9: error: ?_Atomic? does not name a type
 typedef _Atomic long atomic_long;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:49:9: error: ?_Atomic? does not name a type
 typedef _Atomic unsigned long atomic_ulong;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:50:9: error: ?_Atomic? does not name a type
 typedef _Atomic long long atomic_llong;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:51:9: error: ?_Atomic? does not name a type
 typedef _Atomic unsigned long long atomic_ullong;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:52:9: error: ?_Atomic? does not name a type
 typedef _Atomic __CHAR16_TYPE__ atomic_char16_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:53:9: error: ?_Atomic? does not name a type
 typedef _Atomic __CHAR32_TYPE__ atomic_char32_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:54:9: error: ?_Atomic? does not name a type
 typedef _Atomic __WCHAR_TYPE__ atomic_wchar_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:55:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INT_LEAST8_TYPE__ atomic_int_least8_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:56:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINT_LEAST8_TYPE__ atomic_uint_least8_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:57:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INT_LEAST16_TYPE__ atomic_int_least16_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:58:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINT_LEAST16_TYPE__ atomic_uint_least16_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:59:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INT_LEAST32_TYPE__ atomic_int_least32_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:60:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINT_LEAST32_TYPE__ atomic_uint_least32_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:61:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INT_LEAST64_TYPE__ atomic_int_least64_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:62:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINT_LEAST64_TYPE__ atomic_uint_least64_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:63:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INT_FAST8_TYPE__ atomic_int_fast8_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:64:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINT_FAST8_TYPE__ atomic_uint_fast8_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:65:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INT_FAST16_TYPE__ atomic_int_fast16_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:66:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINT_FAST16_TYPE__ atomic_uint_fast16_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:67:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INT_FAST32_TYPE__ atomic_int_fast32_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:68:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINT_FAST32_TYPE__ atomic_uint_fast32_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:69:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INT_FAST64_TYPE__ atomic_int_fast64_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:70:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINT_FAST64_TYPE__ atomic_uint_fast64_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:71:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INTPTR_TYPE__ atomic_intptr_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:72:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINTPTR_TYPE__ atomic_uintptr_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:73:9: error: ?_Atomic? does not name a type
 typedef _Atomic __SIZE_TYPE__ atomic_size_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:74:9: error: ?_Atomic? does not name a type
 typedef _Atomic __PTRDIFF_TYPE__ atomic_ptrdiff_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:75:9: error: ?_Atomic? does not name a type
 typedef _Atomic __INTMAX_TYPE__ atomic_intmax_t;
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:76:9: error: ?_Atomic? does not name a type
 typedef _Atomic __UINTMAX_TYPE__ atomic_uintmax_t;        
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:232:9: error: ?_Atomic? does not name a type
 typedef _Atomic struct
         ^
/usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:239:3: error: ?atomic_flag? does not name a type
 } atomic_flag;
   ^
In file included from /local/python350a2/include/python3.5m/Python.h:53:0,
                 from example_wrap.cxx:154:
/local/python350a2/include/python3.5m/pyatomic.h:37:5: error: ?_Atomic? does not name a type
     _Atomic void *_value;
     ^
/local/python350a2/include/python3.5m/pyatomic.h:41:5: error: ?atomic_int? does not name a type
     atomic_int _value;
     ^
Makefile:4: recipe for target 'example.so' failed
make: *** [example.so] Error 1


The output with Python 3.4.2:
$ make
swig -c++ -python -py3 example.i
g++ -g -fPIC -c example.cxx example_wrap.cxx -I/local/python342m/include/python3.4m -I/local/python342m/include/python3.4m
g++ -g -shared *.o -o _example.so
$ python3.4 a_test.py 
3

----------
files: min_example.tar.gz
messages: 237942
nosy: Joshua.J.Cogliati, jrincayc
priority: normal
severity: normal
status: open
title: swig compile fails with ?_Atomic? does not name a type
versions: Python 3.5
Added file: http://bugs.python.org/file38453/min_example.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Thu Mar 12 16:02:28 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 15:02:28 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_swig_compile_fails_with_=E2=80=98=5FAtomic?=
 =?utf-8?q?=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426172548.96.0.330727602351.issue23644@psf.upfronthosting.co.za>


STINNER Victor added the comment:

_Atomic was added by the issue #22038.

----------
nosy: +gustavotemple, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Thu Mar 12 16:02:40 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 15:02:40 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_swig_compile_fails_with_=E2=80=98=5FAtomic?=
 =?utf-8?q?=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426172560.17.0.780585278346.issue23644@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +Vitor.de.Lima

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Thu Mar 12 16:05:34 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Mar 2015 15:05:34 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_swig_compile_fails_with_=E2=80=98=5FAtomic?=
 =?utf-8?q?=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <20150312150523.70290.83405@psf.io>


Roundup Robot added the comment:

New changeset eb48295e1f8b by Victor Stinner in branch 'default':
Issue #23644, #22038: Move #include <stdatomic.c> inside the extern "C" { ... }
https://hg.python.org/cpython/rev/eb48295e1f8b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Thu Mar 12 16:05:34 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Mar 2015 15:05:34 +0000
Subject: [issue22038] Implement atomic operations on non-x86 platforms
In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za>
Message-ID: <20150312150523.70290.82485@psf.io>


Roundup Robot added the comment:

New changeset eb48295e1f8b by Victor Stinner in branch 'default':
Issue #23644, #22038: Move #include <stdatomic.c> inside the extern "C" { ... }
https://hg.python.org/cpython/rev/eb48295e1f8b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22038>
_______________________________________

From report at bugs.python.org  Thu Mar 12 16:06:09 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 15:06:09 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_swig_compile_fails_with_=E2=80=98=5FAtomic?=
 =?utf-8?q?=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426172769.21.0.749026502817.issue23644@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Can you please try with the latest development version?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Thu Mar 12 16:24:36 2015
From: report at bugs.python.org (=?utf-8?q?Ga=C3=ABtan_de_Menten?=)
Date: Thu, 12 Mar 2015 15:24:36 +0000
Subject: [issue23645] Incorrect doc for __getslice__
Message-ID: <1426173876.09.0.220076074076.issue23645@psf.upfronthosting.co.za>


New submission from Ga?tan de Menten:

The documentation for __getslice__ at https://docs.python.org/2/reference/datamodel.html#object.__getslice__ states: "Note that missing i or j in the slice expression are replaced by zero or sys.maxint, respectively."

However, in practice, it seems like it is replaced by sys.maxsize instead. This is obviously only a problem for 64bit versions of Python 2 since sys.maxint and sys.maxsize are the same on 32bit Python.

In [1]: class A(object):
   ...:     def __getslice__(self, i, j):
   ...:         print i, j
   ...:

In [2]: a = A()

In [3]: a[:]
0 9223372036854775807

In [4]: import sys

In [5]: sys.maxint
Out[5]: 2147483647

In [6]: sys.maxsize
Out[6]: 9223372036854775807L

In [7]: sys.version
Out[7]: '2.7.9 |Continuum Analytics, Inc.| (default, Dec 18 2014, 16:57:52) [MSC v.1500 64 bit (AMD64)]'

----------
assignee: docs at python
components: Documentation
messages: 237947
nosy: docs at python, gdementen
priority: normal
severity: normal
status: open
title: Incorrect doc for __getslice__
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23645>
_______________________________________

From report at bugs.python.org  Thu Mar 12 16:37:42 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 15:37:42 +0000
Subject: [issue23646] PEP 475: handle EINTR in the time module, retry sleep()
Message-ID: <1426174662.68.0.293958221956.issue23646@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch changes time.sleep() to retry select() when select() is interrupted by a signal or retry WaitForSingleObjectEx() when the signal SIGINT is received on Windows.

The patch drops support for EMX, sorry! I didn't know EMX, I had to Google it: "EMX is a free 32-bit DOS extender which adds some properties of Unix to MS-compatible DOS and IBM's OS/2 operating systems." (OS/2 support was dropped in Python 3.4  by the PEP 11.)

The patch also drops support for Watcom C compiler. I guess that it's also something specific to MS-DOS or very old (and unsupported) Windows versions.

select.select() is available on all platforms according to the doc, so I don't understand why we would not use it on all platforms for time.sleep() in 2015!
https://docs.python.org/dev/library/select.html#select.select

----------
files: sleep_eintr.patch
keywords: patch
messages: 237948
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: PEP 475: handle EINTR in the time module, retry sleep()
versions: Python 3.5
Added file: http://bugs.python.org/file38454/sleep_eintr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23646>
_______________________________________

From report at bugs.python.org  Thu Mar 12 16:38:31 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 15:38:31 +0000
Subject: [issue23646] PEP 475: handle EINTR in the time module, retry sleep()
In-Reply-To: <1426174662.68.0.293958221956.issue23646@psf.upfronthosting.co.za>
Message-ID: <1426174711.59.0.641701957457.issue23646@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The patch includes a unit test for POSIX.

For Windows, you can test manually using the attached sleep.py program: press CTRL+c to send SIGINT signals.

----------
Added file: http://bugs.python.org/file38455/sleep.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23646>
_______________________________________

From report at bugs.python.org  Thu Mar 12 16:39:25 2015
From: report at bugs.python.org (Arnt Gulbrandsen)
Date: Thu, 12 Mar 2015 15:39:25 +0000
Subject: [issue23647] imaplib.py MAXLINE value is too low for 2015 (patch
 attached)
Message-ID: <1426174765.08.0.908432771269.issue23647@psf.upfronthosting.co.za>


New submission from Arnt Gulbrandsen:

http://stackoverflow.com/q/28923997 and various other SO questions point out that imaplib's _MAXLINE value is a bit behind the times. Fine for 1997, when people had 10MB mailbox quotas, not so fine for the age of gmail.

I'm tired of seeing those questions, so the attached patch increases the limit without abolishing it completely.

There are also other issues in imaplib, but I fix just this one now, to test the waters so to speak.

FWIW, I've signed the contributor form, just in case.

----------
components: Library (Lib)
files: 0001-Increase-IMAP-line-length-limit.patch
keywords: patch
messages: 237950
nosy: arnt
priority: normal
severity: normal
status: open
title: imaplib.py MAXLINE value is too low for 2015 (patch attached)
type: enhancement
Added file: http://bugs.python.org/file38456/0001-Increase-IMAP-line-length-limit.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23647>
_______________________________________

From report at bugs.python.org  Thu Mar 12 16:45:08 2015
From: report at bugs.python.org (Joshua J Cogliati)
Date: Thu, 12 Mar 2015 15:45:08 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_swig_compile_fails_with_=E2=80=98=5FAtomic?=
 =?utf-8?q?=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426175108.56.0.953910413577.issue23644@psf.upfronthosting.co.za>


Joshua J Cogliati added the comment:

I have:
/local/python_fix/include/python3.5m/pyatomic.h
#ifndef Py_LIMITED_API
#ifndef Py_ATOMIC_H
#define Py_ATOMIC_H

#include "dynamic_annotations.h"

#include "pyconfig.h"

#ifdef __cplusplus
extern "C" {
#endif

#if defined(HAVE_STD_ATOMIC)
#include <stdatomic.h>
#endif

...

and still get:
In file included from /local/python_fix/include/python3.5m/pyatomic.h:14:0,
                 from /local/python_fix/include/python3.5m/Python.h:53,
                 from example_wrap.cxx:154:
/usr/include/c++/4.9.2/exception:161:34: error: missing binary operator before token "("
 #if (__cplusplus >= 201103L) && (ATOMIC_INT_LOCK_FREE > 1)


So the bug still seems to be there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Thu Mar 12 16:45:09 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 15:45:09 +0000
Subject: [issue23646] PEP 475: handle EINTR in the time module, retry sleep()
In-Reply-To: <1426174662.68.0.293958221956.issue23646@psf.upfronthosting.co.za>
Message-ID: <1426175109.46.0.514364819908.issue23646@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, test_signal fails with the patch because time.sleep() is not interrupted by a signal. New patch.

I also reverted #ifdef order in floatsleep() to have a patch easier to review.

----------
Added file: http://bugs.python.org/file38457/sleep_eintr-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23646>
_______________________________________

From report at bugs.python.org  Thu Mar 12 16:46:36 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 15:46:36 +0000
Subject: [issue23646] PEP 475: handle EINTR in the time module, retry sleep()
In-Reply-To: <1426174662.68.0.293958221956.issue23646@psf.upfronthosting.co.za>
Message-ID: <1426175196.97.0.193963939721.issue23646@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Note: test_signal will have to be modified again when select will also retry on EINTR :-) See issue #23485. For example, test_signal.test_wakeup_fd_early() can register a signal handler which raises an exception and catch InterruptedError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23646>
_______________________________________

From report at bugs.python.org  Thu Mar 12 16:51:26 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 15:51:26 +0000
Subject: [issue23648] PEP 475 meta issue
Message-ID: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I created this issue to group all issues related to the implementation of the PEP 475 "Retry system calls failing with EINTR".
https://www.python.org/dev/peps/pep-0475/

- Issue #23646: the time module, retry sleep()
- Issue #23618: the socket module
- Issue #23285: the io and the os modules, and open()
- Issue #23485: the select and selectors module

----------
messages: 237954
nosy: haypo
priority: normal
severity: normal
status: open
title: PEP 475 meta issue
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Thu Mar 12 16:51:50 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 15:51:50 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>
Message-ID: <1426175510.28.0.929108600137.issue23648@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
dependencies: +PEP 475 - EINTR handling, PEP 475: handle EINTR in the select and selectors module, PEP 475: handle EINTR in the socket module, PEP 475: handle EINTR in the time module, retry sleep()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Thu Mar 12 16:51:59 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 15:51:59 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>
Message-ID: <1426175519.08.0.0910385993205.issue23648@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Thu Mar 12 16:58:31 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 15:58:31 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_swig_compile_fails_with_=E2=80=98=5FAtomic?=
 =?utf-8?q?=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426175911.23.0.738275359066.issue23644@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The problem is more general than Python: #include <stdatomic.h> fails in C++. Try to compiled atomic.cpp with g++, you will get the same error.

The following bug report in the glibc has been closed as WONTFIX:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932

It suggests to use the following code:

#ifdef __cplusplus
#include <atomic>
using namespace std;
#else
#include <stdatomic.h>
#endif

I don't know if it works.

----------
Added file: http://bugs.python.org/file38458/atomic.cpp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Thu Mar 12 17:00:02 2015
From: report at bugs.python.org (Leonardo Bianconi)
Date: Thu, 12 Mar 2015 16:00:02 +0000
Subject: [issue22038] Implement atomic operations on non-x86 platforms
In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za>
Message-ID: <1426176002.75.0.658172870539.issue22038@psf.upfronthosting.co.za>


Changes by Leonardo Bianconi <leonardo.bianconi at eldorado.org.br>:


----------
nosy: +lbianc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22038>
_______________________________________

From report at bugs.python.org  Thu Mar 12 17:00:05 2015
From: report at bugs.python.org (Leonardo Bianconi)
Date: Thu, 12 Mar 2015 16:00:05 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_swig_compile_fails_with_=E2=80=98=5FAtomic?=
 =?utf-8?q?=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426176005.91.0.76191873578.issue23644@psf.upfronthosting.co.za>


Changes by Leonardo Bianconi <leonardo.bianconi at eldorado.org.br>:


----------
nosy: +lbianc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Thu Mar 12 17:14:08 2015
From: report at bugs.python.org (Gustavo Frederico Temple Pedrosa)
Date: Thu, 12 Mar 2015 16:14:08 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_swig_compile_fails_with_=E2=80=98=5FAtomic?=
 =?utf-8?q?=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426176848.1.0.262385855436.issue23644@psf.upfronthosting.co.za>


Gustavo Frederico Temple Pedrosa added the comment:

@haypo, @lbianc will investigate this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Thu Mar 12 17:18:31 2015
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 12 Mar 2015 16:18:31 +0000
Subject: [issue22928] HTTP header injection in
 urrlib2/urllib/httplib/http.client
In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za>
Message-ID: <1426177111.63.0.70746242926.issue22928@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Thanks for the tweaks Serhiy, those seem reasonable to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22928>
_______________________________________

From report at bugs.python.org  Thu Mar 12 17:27:37 2015
From: report at bugs.python.org (Joshua J Cogliati)
Date: Thu, 12 Mar 2015 16:27:37 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_g++_module_compile_fails_with_=E2=80=98=5FAtom?=
 =?utf-8?q?ic=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426177657.18.0.783247506496.issue23644@psf.upfronthosting.co.za>


Joshua J Cogliati added the comment:

If I change the header to:
#ifndef Py_LIMITED_API
#ifndef Py_ATOMIC_H
#define Py_ATOMIC_H

#include "dynamic_annotations.h"

#include "pyconfig.h"

#ifdef __cplusplus
extern "C" {
#endif

#if defined(HAVE_STD_ATOMIC)
#ifdef __cplusplus
#include <atomic>
using namespace std;
#else
#include <stdatomic.h>
#endif
#endif

... (rest same)

AND use -std=c++11
Then the error changes to:
In file included from /local/python_fix/include/python3.5m/Python.h:53:0,
                 from example_wrap.cxx:154:
/local/python_fix/include/python3.5m/pyatomic.h:42:5: error: ?_Atomic? does not name a type
     _Atomic void *_value;
     ^


Basically, <atomic> does define std::atomic_int, but it does not define _Atomic, so the line:
_Atomic void *_value;
will also need to be changed.

----------
title: swig compile fails with ?_Atomic? does not name a type -> g++ module compile fails with ?_Atomic? does not name a type

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Thu Mar 12 17:35:18 2015
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 12 Mar 2015 16:35:18 +0000
Subject: [issue23646] PEP 475: handle EINTR in the time module, retry sleep()
In-Reply-To: <1426175196.97.0.193963939721.issue23646@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM12T-z0br+LmBwfNGuYwQFk3Fw0156kztbM1xu1qCT=+A@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

As for the change to select/poll/etc, IIRC Guido was opposed to it,
that's why I didn't update them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23646>
_______________________________________

From report at bugs.python.org  Thu Mar 12 17:40:01 2015
From: report at bugs.python.org (Srdjan Grubor)
Date: Thu, 12 Mar 2015 16:40:01 +0000
Subject: [issue23649] tarfile not re-entrant for multi-threading
Message-ID: <1426178401.83.0.913984210908.issue23649@psf.upfronthosting.co.za>


New submission from Srdjan Grubor:

When running tarfile.extract through multiple threads, the archive reading pointer is not protected from simultaneous seeks and causes various convoluted bugs:

  <some code>
    self.archive_object.extract(member, extraction_path)
  File "/usr/lib/python3.4/tarfile.py", line 2019, in extract
    set_attrs=set_attrs)
  File "/usr/lib/python3.4/tarfile.py", line 2088, in _extract_member
    self.makefile(tarinfo, targetpath)
  File "/usr/lib/python3.4/tarfile.py", line 2127, in makefile
    source.seek(tarinfo.offset_data)
  File "/usr/lib/python3.4/gzip.py", line 573, in seek
    self.read(1024)
  File "/usr/lib/python3.4/gzip.py", line 365, in read
    if not self._read(readsize):
  File "/usr/lib/python3.4/gzip.py", line 449, in _read
    self._read_eof()
  File "/usr/lib/python3.4/gzip.py", line 485, in _read_eof
    hex(self.crc)))
OSError: CRC check failed 0x1036a2e1 != 0x0

----------
messages: 237960
nosy: sgnn7
priority: normal
severity: normal
status: open
title: tarfile not re-entrant for multi-threading
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23649>
_______________________________________

From report at bugs.python.org  Thu Mar 12 17:45:57 2015
From: report at bugs.python.org (Srdjan Grubor)
Date: Thu, 12 Mar 2015 16:45:57 +0000
Subject: [issue23649] tarfile not re-entrant for multi-threading
In-Reply-To: <1426178401.83.0.913984210908.issue23649@psf.upfronthosting.co.za>
Message-ID: <1426178757.91.0.366059379903.issue23649@psf.upfronthosting.co.za>


Srdjan Grubor added the comment:

Also, extract_member in tarfile.py is not thread-safe since the check for folder existence might occur during another thread's creation of that same dir causing the code to error out.

  File "/usr/lib/python3.4/concurrent/futures/thread.py", line 54, in run
    result = self.fn(*self.args, **self.kwargs)
  File "./xdelta3-dir-patcher", line 499, in _apply_file_delta
    archive_object.expand(patch_file, staging_dir)
  File "./xdelta3-dir-patcher", line 284, in expand
    self.archive_object.extract(member, extraction_path)
  File "/usr/lib/python3.4/tarfile.py", line 2019, in extract
    set_attrs=set_attrs)
  File "/usr/lib/python3.4/tarfile.py", line 2080, in _extract_member
    os.makedirs(upperdirs)
  File "/usr/lib/python3.4/os.py", line 237, in makedirs
    mkdir(name, mode)
FileExistsError: [Errno 17] File exists: '/tmp/XDelta3DirPatcher_is0y4_5f/xdelta/updated folder'

Code causing problems:
2065     def _extract_member(self, tarinfo, targetpath, set_attrs=True):
...
2075         # Create all upper directories.
2076         upperdirs = os.path.dirname(targetpath)
2077         if upperdirs and not os.path.exists(upperdirs):
...
2080             os.makedirs(upperdirs)  # Fails since the dir might be already created between lines 2077 and 2080

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23649>
_______________________________________

From report at bugs.python.org  Thu Mar 12 17:46:07 2015
From: report at bugs.python.org (Srdjan Grubor)
Date: Thu, 12 Mar 2015 16:46:07 +0000
Subject: [issue23649] tarfile not re-entrant for multi-threading
In-Reply-To: <1426178401.83.0.913984210908.issue23649@psf.upfronthosting.co.za>
Message-ID: <1426178767.83.0.104149706725.issue23649@psf.upfronthosting.co.za>


Changes by Srdjan Grubor <sgnn7 at sgnn7.org>:


----------
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23649>
_______________________________________

From report at bugs.python.org  Thu Mar 12 17:46:14 2015
From: report at bugs.python.org (Srdjan Grubor)
Date: Thu, 12 Mar 2015 16:46:14 +0000
Subject: [issue23649] tarfile not re-entrant for multi-threading
In-Reply-To: <1426178401.83.0.913984210908.issue23649@psf.upfronthosting.co.za>
Message-ID: <1426178774.34.0.248116254734.issue23649@psf.upfronthosting.co.za>


Changes by Srdjan Grubor <sgnn7 at sgnn7.org>:


----------
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23649>
_______________________________________

From report at bugs.python.org  Thu Mar 12 17:50:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Mar 2015 16:50:18 +0000
Subject: [issue20617] test_ssl does not use mock
In-Reply-To: <1392292104.23.0.984787666166.issue20617@psf.upfronthosting.co.za>
Message-ID: <20150312165015.118009.91889@psf.io>


Roundup Robot added the comment:

New changeset 2b7cf33ccd74 by Berker Peksag in branch '3.4':
Issue #20617: Remove unused import in test_ssl.
https://hg.python.org/cpython/rev/2b7cf33ccd74

New changeset 07e8c0ae232c by Berker Peksag in branch 'default':
Issue #20617: Remove unused import in test_ssl.
https://hg.python.org/cpython/rev/07e8c0ae232c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20617>
_______________________________________

From report at bugs.python.org  Thu Mar 12 17:51:29 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Mar 2015 16:51:29 +0000
Subject: [issue20617] test_ssl does not use mock
In-Reply-To: <1392292104.23.0.984787666166.issue20617@psf.upfronthosting.co.za>
Message-ID: <1426179089.35.0.534741511656.issue20617@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks Xavier and Mark.

----------
components: +Tests -Library (Lib)
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20617>
_______________________________________

From report at bugs.python.org  Thu Mar 12 17:52:03 2015
From: report at bugs.python.org (Srdjan Grubor)
Date: Thu, 12 Mar 2015 16:52:03 +0000
Subject: [issue23649] tarfile not re-entrant for multi-threading
In-Reply-To: <1426178401.83.0.913984210908.issue23649@psf.upfronthosting.co.za>
Message-ID: <1426179123.75.0.888483736031.issue23649@psf.upfronthosting.co.za>


Srdjan Grubor added the comment:

The code around tarfile multi-threading was fixed for me on the user-side with threading.Lock() usage so it might work to use this within the library and the directory creation could be improved by probably doing a try/except around the makedirs() call with ignoring of the exception if it's FileExistsError - my code I use elsewhere fixes this with:
    def _safe_makedirs(self, dir_path):
        try:
            makedirs(dir_path)
        # Concurrency problems need to be handled. If two threads create
        # the same dir, there might be a race between them checking and
        # doing makedirs so we handle that as gracefully as possible here.
        except FileExistsError as fee:
            if not os.path.isdir(dir_path):
                raise fee 

If I get time, I'll submit a patch but it seems like I probably won't for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23649>
_______________________________________

From report at bugs.python.org  Thu Mar 12 18:12:12 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 17:12:12 +0000
Subject: [issue23649] tarfile not re-entrant for multi-threading
In-Reply-To: <1426178401.83.0.913984210908.issue23649@psf.upfronthosting.co.za>
Message-ID: <1426180332.77.0.936024210297.issue23649@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo, lars.gustaebel
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23649>
_______________________________________

From report at bugs.python.org  Thu Mar 12 18:32:05 2015
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois-Michel_L=27Heureux?=)
Date: Thu, 12 Mar 2015 17:32:05 +0000
Subject: [issue23650] xml.etree.ElementTreee.write can't parse its own output
Message-ID: <1426181525.16.0.169351519158.issue23650@psf.upfronthosting.co.za>


New submission from Fran?ois-Michel L'Heureux:

Using TreeBuilder to put data into XML tree.
Convert that tree to a string.
Parse that string.
XML parser error.

I expect XML library to be able to parse its own output.

Reference example: https://github.com/FinchPowers/python_xml_builder_bug/blob/d98b2422d9ecadbee37e2896a5098abf82b1d7a4/python_xml_builder_bug.py

----------
components: XML
files: python_xml_builder_bug.py
messages: 237965
nosy: Fran?ois-Michel L'Heureux
priority: normal
severity: normal
status: open
title: xml.etree.ElementTreee.write can't parse its own output
versions: Python 2.7
Added file: http://bugs.python.org/file38459/python_xml_builder_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23650>
_______________________________________

From report at bugs.python.org  Thu Mar 12 18:32:38 2015
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois-Michel_L=27Heureux?=)
Date: Thu, 12 Mar 2015 17:32:38 +0000
Subject: [issue23650] xml.etree.ElementTreee.write can't parse its own output
In-Reply-To: <1426181525.16.0.169351519158.issue23650@psf.upfronthosting.co.za>
Message-ID: <1426181558.34.0.272634123213.issue23650@psf.upfronthosting.co.za>


Changes by Fran?ois-Michel L'Heureux <fm.lheureux at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23650>
_______________________________________

From report at bugs.python.org  Thu Mar 12 18:36:59 2015
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois-Michel_L=27Heureux?=)
Date: Thu, 12 Mar 2015 17:36:59 +0000
Subject: [issue23650] xml.etree.ElementTreee.write can't parse its own output
In-Reply-To: <1426181525.16.0.169351519158.issue23650@psf.upfronthosting.co.za>
Message-ID: <1426181819.06.0.38167735026.issue23650@psf.upfronthosting.co.za>


Fran?ois-Michel L'Heureux added the comment:

Note that you cannot copy paste the code and expect to reproduce the issue because it contains special characters that cannot be copy pasted via a web browser.

Here is the output when run.

<?xml version='1.0' encoding='utf-8'?>
<top><line>2015-03-12 09:44:54.560 script runner plugin Hello, world</line></top>
Traceback (most recent call last):
  File "python_xml_builder_bug.py", line 17, in <module>
    ElementTree.fromstring(io.getvalue())
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 1300, in XML
    parser.feed(text)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 1642, in feed
    self._raiseerror(v)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py", line 1506, in _raiseerror
    raise err
xml.etree.ElementTree.ParseError: not well-formed (invalid token): line 2, column 35

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23650>
_______________________________________

From report at bugs.python.org  Thu Mar 12 18:47:06 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Mar 2015 17:47:06 +0000
Subject: [issue23647] imaplib.py MAXLINE value is too low for gmail
In-Reply-To: <1426174765.08.0.908432771269.issue23647@psf.upfronthosting.co.za>
Message-ID: <1426182426.57.0.304959507323.issue23647@psf.upfronthosting.co.za>


R. David Murray added the comment:

Gmail breaks the standards again, eh?  I suppose we'll have to accommodate them ;)

----------
components: +email
nosy: +barry, r.david.murray
title: imaplib.py MAXLINE value is too low for 2015 (patch attached) -> imaplib.py MAXLINE value is too low for gmail
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23647>
_______________________________________

From report at bugs.python.org  Thu Mar 12 18:47:26 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Mar 2015 17:47:26 +0000
Subject: [issue23647] imaplib.py MAXLINE value is too low for gmail
In-Reply-To: <1426174765.08.0.908432771269.issue23647@psf.upfronthosting.co.za>
Message-ID: <1426182446.31.0.236802367286.issue23647@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23647>
_______________________________________

From report at bugs.python.org  Thu Mar 12 18:51:22 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Mar 2015 17:51:22 +0000
Subject: [issue23649] tarfile not re-entrant for multi-threading
In-Reply-To: <1426178401.83.0.913984210908.issue23649@psf.upfronthosting.co.za>
Message-ID: <1426182682.21.0.694866773392.issue23649@psf.upfronthosting.co.za>


R. David Murray added the comment:

If you want to use an object that has state in more than one thread you generally have to put some locking around it.  Unless I'm missing something (which I might be) I don't think it is tarfile's responsibility to do this.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23649>
_______________________________________

From report at bugs.python.org  Thu Mar 12 18:56:22 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Mar 2015 17:56:22 +0000
Subject: [issue23650] xml.etree.ElementTreee.write can't parse its own output
In-Reply-To: <1426181525.16.0.169351519158.issue23650@psf.upfronthosting.co.za>
Message-ID: <1426182982.98.0.467316447716.issue23650@psf.upfronthosting.co.za>


R. David Murray added the comment:

Use \x escapes to construct your example, then.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23650>
_______________________________________

From report at bugs.python.org  Thu Mar 12 18:57:03 2015
From: report at bugs.python.org (Srdjan Grubor)
Date: Thu, 12 Mar 2015 17:57:03 +0000
Subject: [issue23649] tarfile not re-entrant for multi-threading
In-Reply-To: <1426178401.83.0.913984210908.issue23649@psf.upfronthosting.co.za>
Message-ID: <1426183023.91.0.413922841769.issue23649@psf.upfronthosting.co.za>


Srdjan Grubor added the comment:

I don't know if that's true of core libraries. Why complicate things for end users when those issues could be done in the library itself and be completely transparent to the devs? A simple RLock latch wouldn't pose almost any speed degradation but would work in both threaded and non-threaded situations as expected.

----------
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23649>
_______________________________________

From report at bugs.python.org  Thu Mar 12 19:37:11 2015
From: report at bugs.python.org (Nathan West)
Date: Thu, 12 Mar 2015 18:37:11 +0000
Subject: [issue23651] Typo in argparse allow_abrev
Message-ID: <1426185431.21.0.35714831717.issue23651@psf.upfronthosting.co.za>


New submission from Nathan West:

The documentation for the new argparse feature allow_abrev contains a typo:

>>> parser.add_argument('--foobar', action='store_true')
>>> parser.add_argument('--foonley', action='store_false')
>>> parser.parse_args([--foon])
usage: PROG [-h] [--foobar] [--foonley]
PROG: error: unrecognized arguments: --foon

The --foon should be quoted:

>>> parser.parse_args(['--foon'])

----------
assignee: docs at python
components: Documentation
messages: 237971
nosy: Lucretiel, docs at python
priority: normal
severity: normal
status: open
title: Typo in argparse allow_abrev
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23651>
_______________________________________

From report at bugs.python.org  Thu Mar 12 19:41:57 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Mar 2015 18:41:57 +0000
Subject: [issue23581] unittest.mock.MagicMock doesn't support matmul (@)
 operator
In-Reply-To: <1425461221.82.0.715365961896.issue23581@psf.upfronthosting.co.za>
Message-ID: <20150312184150.32083.31015@psf.io>


Roundup Robot added the comment:

New changeset 8c65480a1e19 by Berker Peksag in branch 'default':
Issue #23581: Add matmul support to MagicMock.
https://hg.python.org/cpython/rev/8c65480a1e19

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23581>
_______________________________________

From report at bugs.python.org  Thu Mar 12 19:44:21 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Mar 2015 18:44:21 +0000
Subject: [issue23581] unittest.mock.MagicMock doesn't support matmul (@)
 operator
In-Reply-To: <1425461221.82.0.715365961896.issue23581@psf.upfronthosting.co.za>
Message-ID: <1426185861.77.0.33862319367.issue23581@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, H?kan. If you want to add tests for other magic methods, please open a new issue.

Thanks for the report, Zygmunt.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23581>
_______________________________________

From report at bugs.python.org  Thu Mar 12 19:46:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Mar 2015 18:46:42 +0000
Subject: [issue23651] Typo in argparse allow_abrev
In-Reply-To: <1426185431.21.0.35714831717.issue23651@psf.upfronthosting.co.za>
Message-ID: <20150312184636.118005.34922@psf.io>


Roundup Robot added the comment:

New changeset 8411ae359c98 by Berker Peksag in branch 'default':
Issue #23651: Fix typo in allow_abbrev docs.
https://hg.python.org/cpython/rev/8411ae359c98

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23651>
_______________________________________

From report at bugs.python.org  Thu Mar 12 19:47:09 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Mar 2015 18:47:09 +0000
Subject: [issue23651] Typo in argparse allow_abrev
In-Reply-To: <1426185431.21.0.35714831717.issue23651@psf.upfronthosting.co.za>
Message-ID: <1426186029.73.0.329137444215.issue23651@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Good catch, Nathan. Thanks!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23651>
_______________________________________

From report at bugs.python.org  Thu Mar 12 20:06:46 2015
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois-Michel_L=27Heureux?=)
Date: Thu, 12 Mar 2015 19:06:46 +0000
Subject: [issue23650] xml.etree.ElementTreee.write can't parse its own output
In-Reply-To: <1426181525.16.0.169351519158.issue23650@psf.upfronthosting.co.za>
Message-ID: <1426187206.15.0.520054243346.issue23650@psf.upfronthosting.co.za>


Changes by Fran?ois-Michel L'Heureux <fm.lheureux at gmail.com>:


Removed file: http://bugs.python.org/file38459/python_xml_builder_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23650>
_______________________________________

From report at bugs.python.org  Thu Mar 12 20:07:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Mar 2015 19:07:23 +0000
Subject: [issue23641] Got rid of bad dunder names
In-Reply-To: <1426084934.72.0.0668161558437.issue23641@psf.upfronthosting.co.za>
Message-ID: <1426187243.43.0.692872107219.issue23641@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Do you want first commit the patch in issue23581 Berker?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23641>
_______________________________________

From report at bugs.python.org  Thu Mar 12 20:07:27 2015
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois-Michel_L=27Heureux?=)
Date: Thu, 12 Mar 2015 19:07:27 +0000
Subject: [issue23650] xml.etree.ElementTreee.write can't parse its own output
In-Reply-To: <1426181525.16.0.169351519158.issue23650@psf.upfronthosting.co.za>
Message-ID: <1426187247.08.0.457764877895.issue23650@psf.upfronthosting.co.za>


Fran?ois-Michel L'Heureux added the comment:

Updated file where copy/pasting works.

----------
Added file: http://bugs.python.org/file38460/python_xml_builder_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23650>
_______________________________________

From report at bugs.python.org  Thu Mar 12 20:12:22 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Mar 2015 19:12:22 +0000
Subject: [issue23641] Got rid of bad dunder names
In-Reply-To: <1426084934.72.0.0668161558437.issue23641@psf.upfronthosting.co.za>
Message-ID: <1426187542.77.0.189343516232.issue23641@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> Do you want first commit the patch in issue23581 Berker?

I just committed it. Thanks for the review :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23641>
_______________________________________

From report at bugs.python.org  Thu Mar 12 20:48:58 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Mar 2015 19:48:58 +0000
Subject: [issue23650] xml.etree.ElementTreee.write can't parse its own output
In-Reply-To: <1426181525.16.0.169351519158.issue23650@psf.upfronthosting.co.za>
Message-ID: <1426189738.44.0.314336795726.issue23650@psf.upfronthosting.co.za>


Ned Deily added the comment:

This is a duplicate of Issue5166.  Note that in your example, you are not serializing valid XML 1.0: \x1b (ESC) is not a valid XML character, it has to be escaped and, as the discussion in Issue5166 points out, etree does not automatically do that for you.

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> ElementTree and minidom don't prevent creation of not well-formed XML

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23650>
_______________________________________

From report at bugs.python.org  Thu Mar 12 21:01:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Mar 2015 20:01:58 +0000
Subject: [issue23641] Got rid of bad dunder names
In-Reply-To: <1426084934.72.0.0668161558437.issue23641@psf.upfronthosting.co.za>
Message-ID: <20150312200155.27349.10010@psf.io>


Roundup Robot added the comment:

New changeset 7522bb14e36a by Serhiy Storchaka in branch '3.4':
Issue #23641: Cleaned out legacy dunder names from tests and docs.
https://hg.python.org/cpython/rev/7522bb14e36a

New changeset 9332a545ad85 by Serhiy Storchaka in branch 'default':
Issue #23641: Cleaned out legacy dunder names from tests and docs.
https://hg.python.org/cpython/rev/9332a545ad85

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23641>
_______________________________________

From report at bugs.python.org  Thu Mar 12 21:04:10 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Mar 2015 20:04:10 +0000
Subject: [issue23641] Got rid of bad dunder names
In-Reply-To: <1426084934.72.0.0668161558437.issue23641@psf.upfronthosting.co.za>
Message-ID: <1426190650.25.0.749461922576.issue23641@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Committed all except changes to multiprocessing.sharedctypes (remove __getslice__ and __setslice__) and unittest.mock (remove __div__, add __getnewargs_ex__).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23641>
_______________________________________

From report at bugs.python.org  Thu Mar 12 21:12:36 2015
From: report at bugs.python.org (Alex Zhang)
Date: Thu, 12 Mar 2015 20:12:36 +0000
Subject: [issue23635] Python won't install correctly.
In-Reply-To: <1426032900.09.0.644989151138.issue23635@psf.upfronthosting.co.za>
Message-ID: <1426191156.39.0.0533018309238.issue23635@psf.upfronthosting.co.za>


Alex Zhang added the comment:

Never mind, I used ccleaner and revo uninstaller to delete traces, then reinstalled using the msi. Thanks for help, it's all good now!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23635>
_______________________________________

From report at bugs.python.org  Thu Mar 12 21:27:58 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 Mar 2015 20:27:58 +0000
Subject: [issue23646] PEP 475: handle EINTR in the time module, retry sleep()
In-Reply-To: <CAH_1eM12T-z0br+LmBwfNGuYwQFk3Fw0156kztbM1xu1qCT=+A@mail.gmail.com>
Message-ID: <CAMpsgwbD5qvESPGZwp+h=uUp+9FhaJMoUe7igdc0G80173B8cQ@mail.gmail.com>


STINNER Victor added the comment:

Le jeudi 12 mars 2015, Charles-Fran?ois Natali <report at bugs.python.org> a
?crit :
>
> As for the change to select/poll/etc, IIRC Guido was opposed to it,
> that's why I didn't update them.
>

Wait what? can you elaborate? I'm not aware of that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23646>
_______________________________________

From report at bugs.python.org  Thu Mar 12 21:41:46 2015
From: report at bugs.python.org (Matt Frank)
Date: Thu, 12 Mar 2015 20:41:46 +0000
Subject: [issue23652] ifdef uses of EPOLLxxx macros so we can compile on
 systems that don't have them
Message-ID: <1426192906.82.0.724323476801.issue23652@psf.upfronthosting.co.za>


New submission from Matt Frank:

With the LSB (Linux Standard Base) headers for libc Modules/selectmodule.c fails to compile because we have code that uses EPOLLRDNORM, EPOLLRDBAND, EPOLLWRNORM and EPOLLMSG without first checking that they are defined.

The patch wraps the five uses of PyModule_AddIntMacro in #ifdefs, following exactly the same pattern that is used for the POLLRDNORM, POLLRDBAND, POLLWRNORM, POLLMSG macros 30 lines earlier in selectmodule.c.

The only documentation I can find for these five macros from Linux is (a) in the Python documentation for the select module!  (https://docs.python.org/3.4/library/select.html#edge-and-level-trigger-polling-epoll-objects) and (b) on this StackOverflow answer: http://stackoverflow.com/a/27143672/2209313.

They are not described on http://man7.org/linux/man-pages/man2/epoll_ctl.2.html (where the rest of the EPOLL macros are defined), nor at http://linux.die.net/man/4/epoll.  As explained by the StackOverflow answer they actually are described (indirectly) by http://man7.org/linux/man-pages/man2/poll.2.html.

Nor are these macros in the Linux Foundation's LSB database: http://www.linuxbase.org/navigator/browse/headgroup.php?cmd=list-byheadgroup&HGid=1398.

Obviously almost all modern Linuxes have these macros, so we should keep them, but we should also compile with the LSB headers (since compiling and linking against the LSB SDK (http://www.linuxfoundation.org/collaborate/workgroups/lsb/group) is one of the easiest ways to produce a Python binary that will actually run on most important supported Linux distros (e.g., RHEL 5).

http://man7.org/linux/man-pages/man7/epoll.7.html,

----------
components: Build
files: epoll-macros-patch.diff
keywords: patch
messages: 237984
nosy: WanderingLogic
priority: normal
severity: normal
status: open
title: ifdef uses of EPOLLxxx macros so we can compile on systems that don't have them
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38461/epoll-macros-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23652>
_______________________________________

From report at bugs.python.org  Thu Mar 12 21:47:20 2015
From: report at bugs.python.org (Matt Frank)
Date: Thu, 12 Mar 2015 20:47:20 +0000
Subject: [issue23652] ifdef uses of EPOLLxxx macros so we can compile on
 systems that don't have them
In-Reply-To: <1426192906.82.0.724323476801.issue23652@psf.upfronthosting.co.za>
Message-ID: <1426193240.06.0.978456111346.issue23652@psf.upfronthosting.co.za>


Changes by Matt Frank <matthew.i.frank at intel.com>:


----------
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23652>
_______________________________________

From report at bugs.python.org  Thu Mar 12 21:54:01 2015
From: report at bugs.python.org (Arnt Gulbrandsen)
Date: Thu, 12 Mar 2015 20:54:01 +0000
Subject: [issue23647] imaplib.py MAXLINE value is too low for gmail
In-Reply-To: <1426174765.08.0.908432771269.issue23647@psf.upfronthosting.co.za>
Message-ID: <1426193641.23.0.341835100258.issue23647@psf.upfronthosting.co.za>


Arnt Gulbrandsen added the comment:

The RFC in question is 2683, which isn't a standard, it's just advice.

What gmail breaks is the expectation that mailboxes and seach results are smallish. If you run a python script on gmail and it runs a search, the result can be a great deal bigger than the author of RFC2683 foresaw.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23647>
_______________________________________

From report at bugs.python.org  Thu Mar 12 21:59:43 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 Mar 2015 20:59:43 +0000
Subject: [issue23652] ifdef uses of EPOLLxxx macros so we can compile on
 systems that don't have them
In-Reply-To: <1426192906.82.0.724323476801.issue23652@psf.upfronthosting.co.za>
Message-ID: <1426193983.14.0.655731193655.issue23652@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23652>
_______________________________________

From report at bugs.python.org  Thu Mar 12 22:04:11 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 12 Mar 2015 21:04:11 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_g++_module_compile_fails_with_=E2=80=98=5FAtom?=
 =?utf-8?q?ic=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426194251.4.0.46817975343.issue23644@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Thu Mar 12 22:05:30 2015
From: report at bugs.python.org (Srdjan Grubor)
Date: Thu, 12 Mar 2015 21:05:30 +0000
Subject: [issue23649] tarfile not re-entrant for multi-threading
In-Reply-To: <1426178401.83.0.913984210908.issue23649@psf.upfronthosting.co.za>
Message-ID: <1426194330.2.0.353282134111.issue23649@psf.upfronthosting.co.za>


Srdjan Grubor added the comment:

After some thinking, for the makedirs it should only need makedirs(exist_ok=True)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23649>
_______________________________________

From report at bugs.python.org  Thu Mar 12 22:31:49 2015
From: report at bugs.python.org (Nathan West)
Date: Thu, 12 Mar 2015 21:31:49 +0000
Subject: [issue23653] Make inspect._empty test to False
Message-ID: <1426195909.5.0.733462239813.issue23653@psf.upfronthosting.co.za>


New submission from Nathan West:

A common Python idiom is to test objects by value in an if. This includes container emptiness and regular expression matches, or using 'or' to specify a default value:

    if my_list:
        # list isn't empty
    if regex.match(string):
        # string matched the regex
    my_list = arg or [1,2,3]

It'd be nice if we could use this idiom with inspect.Signature._empty or inspect.Parameter.empty:

    sig = signature(func)
    for param in sig.parameters.values():
        if param.annotation:
            ...

or, to use a the example that motivated this idea:

    def arg_type(param):
        return param.annotation or str

The only issue I can think of is that, if an annotation or default value is some False value, like None, than the test will fail even if the value isn't _empty. However, this issue already exists for other uses of this idiom, and I think this is a perfect extension of the form.

----------
components: Library (Lib)
messages: 237987
nosy: Lucretiel
priority: normal
severity: normal
status: open
title: Make inspect._empty test to False
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23653>
_______________________________________

From report at bugs.python.org  Thu Mar 12 22:32:19 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Mar 2015 21:32:19 +0000
Subject: [issue23647] imaplib.py MAXLINE value is too low for gmail
In-Reply-To: <1426174765.08.0.908432771269.issue23647@psf.upfronthosting.co.za>
Message-ID: <1426195939.39.0.580606584897.issue23647@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sorry, I was being a facetious, but despite the smiley that wasn't clear.  I *have* run into a number of cases where gmail violates the standard, but I wasn't really serious about this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23647>
_______________________________________

From report at bugs.python.org  Thu Mar 12 22:59:53 2015
From: report at bugs.python.org (Srdjan Grubor)
Date: Thu, 12 Mar 2015 21:59:53 +0000
Subject: [issue23649] tarfile not re-entrant for multi-threading
In-Reply-To: <1426178401.83.0.913984210908.issue23649@psf.upfronthosting.co.za>
Message-ID: <1426197593.85.0.438140276268.issue23649@psf.upfronthosting.co.za>


Srdjan Grubor added the comment:

Patch for the multithreaded expansion of files and use of makedirs.

----------
keywords: +patch
Added file: http://bugs.python.org/file38462/mutithreading_tarfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23649>
_______________________________________

From report at bugs.python.org  Thu Mar 12 23:03:17 2015
From: report at bugs.python.org (Srdjan Grubor)
Date: Thu, 12 Mar 2015 22:03:17 +0000
Subject: [issue23649] tarfile not re-entrant for multi-threading
In-Reply-To: <1426178401.83.0.913984210908.issue23649@psf.upfronthosting.co.za>
Message-ID: <1426197797.39.0.0913941372446.issue23649@psf.upfronthosting.co.za>


Srdjan Grubor added the comment:

The whole lib still needs the threading locks added but the patch submitted should fix things for people that do the locking from their code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23649>
_______________________________________

From report at bugs.python.org  Thu Mar 12 23:12:07 2015
From: report at bugs.python.org (Jean-Charles Lefebvre)
Date: Thu, 12 Mar 2015 22:12:07 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1426198327.09.0.153191448122.issue17797@psf.upfronthosting.co.za>


Jean-Charles Lefebvre added the comment:

Hi all, a small update to confirm this issue with version 3.5.0a2 embedded in a native C++ GUI application, having everything built with VS2013 SP4.

Same execution flow as described by Mateusz in msg198689.

I've modified Python/pylifecycle.c file according to Tomasz's attached patch.
It just "works for me" and I've just slightly modified the #ifdef line:

#if defined(MS_WINDOWS) && defined(HAVE_FSTAT) && defined(_MSC_VER) && _MSC_VER >= 1700 && _MSC_VER < 2000

It would definitely be nice to have this workaround applied to the 3.5 branch since MS' fix is lost in release cycle. Would it be too intrusive?

----------
nosy: +Jean-Charles Lefebvre
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Thu Mar 12 23:14:11 2015
From: report at bugs.python.org (Jean-Charles Lefebvre)
Date: Thu, 12 Mar 2015 22:14:11 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1426198450.99.0.151689157325.issue17797@psf.upfronthosting.co.za>


Jean-Charles Lefebvre added the comment:

Oops, mistyping, #ifdef test would be:

#if defined(MS_WINDOWS) && defined(HAVE_FSTAT) && defined(_MSC_VER) && _MSC_VER >= 1700 && _MSC_VER < 1900

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Thu Mar 12 23:51:27 2015
From: report at bugs.python.org (Matt Frank)
Date: Thu, 12 Mar 2015 22:51:27 +0000
Subject: [issue23654] infinite loop in faulthandler._stack_overflow
Message-ID: <1426200687.84.0.455927631723.issue23654@psf.upfronthosting.co.za>


New submission from Matt Frank:

When the faulthandler module is compiled at -O3 (the default for non-debug builds) with a compiler that does tailcall optimization the Modules/faulthandler.c:stack_overflow() function may become an infinite loop that does not expand the stack.  This puts the interpreter into an infinite loop with 100% CPU utilization that won't respond to SIGINT.  (But sending SIGTERM will get it to exit.)

The Intel compiler (15.0.1 on Linux) seems to be able to prove this optimization "safe".  (And thus cause the function to turn into an infinite loop.)  While gcc 4.8.2 and clang 3.4.2 do not currently optimize this call (because their pointer analysis isn't quite strong enough to deal with the pointer to the depth argument), there's no guarantee that they won't be able to optimize it in their next versions.

This patch adds a test between the recursive call and the return statement which makes it not a tail call.

----------
components: Extension Modules
files: faulthandler-infloop.patch
keywords: patch
messages: 237993
nosy: WanderingLogic
priority: normal
severity: normal
status: open
title: infinite loop in faulthandler._stack_overflow
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38463/faulthandler-infloop.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23654>
_______________________________________

From report at bugs.python.org  Fri Mar 13 00:02:30 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Mar 2015 23:02:30 +0000
Subject: [issue23654] infinite loop in faulthandler._stack_overflow
In-Reply-To: <1426200687.84.0.455927631723.issue23654@psf.upfronthosting.co.za>
Message-ID: <1426201350.18.0.0160415774435.issue23654@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23654>
_______________________________________

From report at bugs.python.org  Fri Mar 13 00:13:11 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 12 Mar 2015 23:13:11 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1426201991.72.0.824909083805.issue17797@psf.upfronthosting.co.za>


Steve Dower added the comment:

There's not much point putting this into 3.5 anymore, as we are going to break pre-VS2015 builds completely sooner or later (too many changes to the CRT that we can't just work around with #ifdefs - and too much opposition to having code purely to support unsupported compilers).

It's probably only worth putting this into 3.4 at this stage, which I'm okay with but I'm not going to push hard to make it happen. Also worth noting that the code here in 3.5 has diverged from 3.4, and so the attached patch doesn't apply.

Any of the other core devs strongly opposed to me updating 3.4 so people embedding that version can have the fix?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Fri Mar 13 00:15:50 2015
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 12 Mar 2015 23:15:50 +0000
Subject: [issue23138] cookiejar parses cookie value as int with empty
 name-value pair and Expires
In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za>
Message-ID: <1426202150.01.0.605481477172.issue23138@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


Added file: http://bugs.python.org/file38464/issue23138_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23138>
_______________________________________

From report at bugs.python.org  Fri Mar 13 00:18:29 2015
From: report at bugs.python.org (BJ Dierkes)
Date: Thu, 12 Mar 2015 23:18:29 +0000
Subject: [issue9253] argparse: optional subparsers
In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>
Message-ID: <1426202309.59.0.572745522007.issue9253@psf.upfronthosting.co.za>


Changes by BJ Dierkes <wdierkes at gmail.com>:


----------
nosy: +derks

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9253>
_______________________________________

From report at bugs.python.org  Fri Mar 13 01:23:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 Mar 2015 00:23:55 +0000
Subject: [issue17403] Robotparser fails to parse some robots.txt
In-Reply-To: <1363085904.54.0.398684856881.issue17403@psf.upfronthosting.co.za>
Message-ID: <1426206235.07.0.880530693547.issue17403@psf.upfronthosting.co.za>


Martin Panter added the comment:

Perhaps it?s too late to modify the 3.2 branch now?

IMO the change made for this bug abuses the behaviour of urlunparse() removing empty query strings; see Issue 22852 where I proposed to stop it doing that.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17403>
_______________________________________

From report at bugs.python.org  Fri Mar 13 01:29:14 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Mar 2015 00:29:14 +0000
Subject: [issue22154] ZipFile.open context manager support
In-Reply-To: <1407311800.94.0.537081542584.issue22154@psf.upfronthosting.co.za>
Message-ID: <20150313002911.28819.94104@psf.io>


Roundup Robot added the comment:

New changeset b6fdf8c7a74d by Berker Peksag in branch '3.4':
Issue #22154: Add an example to show context management protocol support of ZipFile.open().
https://hg.python.org/cpython/rev/b6fdf8c7a74d

New changeset 390a2f4dfd4a by Berker Peksag in branch 'default':
Issue #22154: Add an example to show context management protocol support of ZipFile.open().
https://hg.python.org/cpython/rev/390a2f4dfd4a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22154>
_______________________________________

From report at bugs.python.org  Fri Mar 13 01:31:52 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 13 Mar 2015 00:31:52 +0000
Subject: [issue22154] ZipFile.open context manager support
In-Reply-To: <1407311800.94.0.537081542584.issue22154@psf.upfronthosting.co.za>
Message-ID: <1426206712.71.0.881581758924.issue22154@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Mike.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
type: behavior -> enhancement
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22154>
_______________________________________

From report at bugs.python.org  Fri Mar 13 01:39:32 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 13 Mar 2015 00:39:32 +0000
Subject: [issue17403] Robotparser fails to parse some robots.txt
In-Reply-To: <1363085904.54.0.398684856881.issue17403@psf.upfronthosting.co.za>
Message-ID: <1426207172.0.0.633217875659.issue17403@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Yes, this doesn't look like a security issue to me. Too late for 3.2. Closing this as "fixed".

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17403>
_______________________________________

From report at bugs.python.org  Fri Mar 13 01:41:00 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 Mar 2015 00:41:00 +0000
Subject: [issue22852] urllib.parse wrongly strips empty #fragment
In-Reply-To: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za>
Message-ID: <1426207260.37.0.867917360519.issue22852@psf.upfronthosting.co.za>


Martin Panter added the comment:

There have been a few recent bug reports (Issue 23505, Issue 23636) that may be solved by the has_netloc proposal. So I am posting a patch implementing it. The changes were a bit more involved than I anticipated, but should still be usable.

I reused some of Stian?s tests, however the results are slightly different in my patch, matching the existing behaviour:

* Never sets netloc, query, fragment to None
* Always leaves hostname as None rather than ""
* Retains username, password and port components in netloc
* Converts hostname to lowercase

Unfortunately I discovered that you cannot add __slots__ to namedtuple() subclasses; see Issue 17295 and Issue 1173475. Therefore in my patch I have removed __slots__ from the SplitResult etc classes, so that those classes can gain the has_netloc etc attributes.

I chose to make the default has_netloc value based on existing urlunsplit() behaviour:

>>> empty_netloc = ""
>>> SplitResult("mailto", empty_netloc, "chris at example.com", "", "").has_netloc
False
>>> SplitResult("file", empty_netloc, "/path", "", "").has_netloc
True

I found out that the ?urllib.robotparser? module uses a urlunparse(urlparse()) combination to normalize URLs, so had to be changed. This is a backwards incompatibility of this proposal.

----------
keywords: +patch
type:  -> enhancement
Added file: http://bugs.python.org/file38465/has_netloc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22852>
_______________________________________

From report at bugs.python.org  Fri Mar 13 01:55:10 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Mar 2015 00:55:10 +0000
Subject: [issue23081] Document PySequence_List(o) as equivalent to list(o)
In-Reply-To: <1418908520.28.0.480794985208.issue23081@psf.upfronthosting.co.za>
Message-ID: <20150313005507.32069.62777@psf.io>


Roundup Robot added the comment:

New changeset e31e987207ab by Berker Peksag in branch '3.4':
Issue #23081: Document that PySequence_List also accepts iterables.
https://hg.python.org/cpython/rev/e31e987207ab

New changeset eb4a0048978c by Berker Peksag in branch 'default':
Issue #23081: Document that PySequence_List also accepts iterables.
https://hg.python.org/cpython/rev/eb4a0048978c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23081>
_______________________________________

From report at bugs.python.org  Fri Mar 13 01:56:10 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 13 Mar 2015 00:56:10 +0000
Subject: [issue23081] Document PySequence_List(o) as equivalent to list(o)
In-Reply-To: <1418908520.28.0.480794985208.issue23081@psf.upfronthosting.co.za>
Message-ID: <1426208170.18.0.992445656236.issue23081@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report and the patch, Lars.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23081>
_______________________________________

From report at bugs.python.org  Fri Mar 13 03:28:57 2015
From: report at bugs.python.org (Ben Hoyt)
Date: Fri, 13 Mar 2015 02:28:57 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1426213737.12.0.18456430583.issue23605@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

Thanks, Victor.

I haven't quite grokked all the changes here -- it's gotten somewhat more complicated with the scandir_it and manual next() call -- but I ran some benchmarks (via a hacked version of my scandir project's benchmark.py). The results were surprising, and in a good way:

Dev version in hg (no extra islink syscall):
--------------------------------------------
Windows: 13.1x as fast (68.8x as fast in funky caching mode)
Linux: 7.8x as fast

With Victor's fast_bottom_up patch (100% correct behaviour):
--------------------------------------------
Windows: 9.4x as fast (50.2x as fast in funky caching mode)
Linux: 6.5x as fast

So os.walk() will still be 10x as fast on Windows if you apply this patch, and 6x as fast on my Linux VM. I haven't dug too deeply to know quite why the numbers are this good, especially on Linux, but that's what I'm seeing, which is great!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Fri Mar 13 04:05:56 2015
From: report at bugs.python.org (Davin Potts)
Date: Fri, 13 Mar 2015 03:05:56 +0000
Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()]
 deadlock
In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za>
Message-ID: <1426215956.06.0.20448193164.issue23051@psf.upfronthosting.co.za>


Davin Potts added the comment:

After pondering it for two days and coming back to it with hopefully "fresh eyes", I believe that changing the for-loop to a while-loop is not overall easier to understand -- I would lean towards keeping the for-loop.

I do think the change to the while-loop very much made the exception handling logic clearer but seeing the while-loop with the "manual" invocation of next and incrementing of the variable i and re-use of i as a signal to break out of a loop (setting i = None) made other things less clear.  My belief is that someone reading this method's code for the first time will read the for-loop version as, "try to loop through the enumerated tasks and if anything goes wrong then set the next position in the cache to 'failed'".  That top-level reading is, I think, not quite as easy with the while-loop.  Without the exception handling that we add in this patch, the original code used the for-loop and would, I think, have looked weird if it had tried to use a while-loop -- I think that's a sign that the for-loop is likely to be more easily understood by a first-time reader.

Though I am not sure it really matters, the while-loop version would only help end the processing of further jobs if an exception occurs in the iterator whereas the for-loop version might help if exceptions occur in a couple of other places.  We do not have a clear motivation for needing that however.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23051>
_______________________________________

From report at bugs.python.org  Fri Mar 13 04:13:40 2015
From: report at bugs.python.org (Akira Li)
Date: Fri, 13 Mar 2015 03:13:40 +0000
Subject: [issue23574] datetime: support leap seconds
In-Reply-To: <1425393743.39.0.519990063132.issue23574@psf.upfronthosting.co.za>
Message-ID: <1426216420.17.0.175740848409.issue23574@psf.upfronthosting.co.za>


Akira Li added the comment:

POSIX timestamp doesn't count (literally) past/future leap seconds.
It allows to find out that the timestamp 2**31-1 corresponds to
2038-01-19T03:14:07Z (UTC) regardless of how many leap seconds will
occur before 2038:

  >>> from datetime import datetime, timedelta
  >>> str(datetime(1970,1,1) + timedelta(seconds=2**31-1))
  '2038-01-19 03:14:07'

If you use "right" timezone then mktime() may count leap seconds:

  $ TZ=right/UTC ./python
  >>> import time
  >>> time.mktime((2012, 6, 30, 23, 59, 59, -1, -1, -1))
  1341100823.0
  >>> time.mktime((2012, 6, 30, 23, 59, 60, -1, -1, -1))
  1341100824.0
  >>> time.mktime((2012, 7, 1, 0, 0, 0, -1, -1, -1))
  1341100825.0

It is a different time scale. There are no leap seconds in TAI:

  >>> str(datetime(1970,1,1, 0,0, 10) + timedelta(seconds=1341100825))
  '2012-07-01 00:00:35'

i.e., 2012-07-01 00:00:35 TAI that corresponds to 2012-07-01 00:00:00
UTC. Each positive leap second increases the difference TAI-UTC (on
2015-07-01UTC it will be 36 [1]).

TAI-UTC in the future (more than 6 months) is unknown but it is less
than ~200 seconds until 2100 [2].

It might be convenient to think about datetime as a broken-down
timestamp and therefore

  (datetime(2012,6,30,23,59,60) - epoch) == 
  (datetime(2012,7, 1, 0, 0, 0) - epoch)

The code [3] that silently truncates 60 to 59 when datetime
constructor is called implicitly should retire.

Use case: parse timestamps that might include a leap second [4]

[1] https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
[2] http://www.ucolick.org/~sla/leapsecs/year2100.html
[3] https://bugs.python.org/msg155689
[4] http://stackoverflow.com/q/21027639

----------
nosy: +akira

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23574>
_______________________________________

From report at bugs.python.org  Fri Mar 13 04:36:43 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 Mar 2015 03:36:43 +0000
Subject: [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1426217803.93.0.552062121349.issue23639@psf.upfronthosting.co.za>


Martin Panter added the comment:

Some of these that I believe are at least partially documented, so could be added to the index. But the index for these is not very good anyway, because they are listed in a funny (ASCII-betical?) order in a special section called ?symbols?, rather than alphabetically as you would expect. But that would be a separate issue.

Potential index entries:

builtins.__build_class__() ? https://docs.python.org/dev/library/dis.html#opcode-LOAD_BUILD_CLASS
__builtins__ global variable ? https://docs.python.org/dev/reference/executionmodel.html#naming-and-binding
__conform__() method ? https://docs.python.org/dev/library/sqlite3.html#letting-your-object-adapt-itself
__isabstractmethod__ ? https://docs.python.org/dev/library/abc.html#abc.abstractmethod
Enum.__members__ ? https://docs.python.org/dev/library/enum.html#iteration
__objclass__ ? https://docs.python.org/dev/reference/datamodel.html#implementing-descriptors
type.__prepare__ ? https://docs.python.org/dev/reference/datamodel.html#preparing-the-class-namespace
__pycache__/ directory ? https://docs.python.org/dev/tutorial/modules.html#compiled-python-files
object.__signature__ ? https://docs.python.org/dev/library/inspect.html#inspect.unwrap
object.__sizeof__() ? https://docs.python.org/dev/library/sys.html#sys.getsizeof
module.__test__ ? https://docs.python.org/dev/library/doctest.html#which-docstrings-are-examined
Real.__trunc__ ? https://docs.python.org/dev/library/math.html#math.trunc
module.__warningregistry__ ? https://docs.python.org/dev/library/warnings.html#warnings.warn_explicit
object.__weakref__ ? https://docs.python.org/dev/c-api/typeobj.html#c.PyTypeObject.tp_weaklistoffset

Others that are referenced by the documentation, but not explained anywhere that I can tell:

* module.__version__, referenced as an attribute in a few modules and also in sample code
* __getformat__(), __setformat__(), __getinitargs__() methods, referenced in ?unittest.mock? documentation

Regarding __base__, I always assumed this was a leftover from Python 2 from some time before multiple inheritance, so maybe __bases__ could be used instead now (unless testing backwards compatibility).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23639>
_______________________________________

From report at bugs.python.org  Fri Mar 13 04:39:53 2015
From: report at bugs.python.org (Wei Wu)
Date: Fri, 13 Mar 2015 03:39:53 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>
Message-ID: <1426217993.34.0.223400152898.issue23566@psf.upfronthosting.co.za>


Wei Wu added the comment:

Or we could reuse the file created by filename in subprocess?

if filename:
    file = open(filename, "wb")
    if use_fd:
        file = file.fileno()
else:
    file = None

In this case, we need to pass two arguments(both filename and a bool use_fd) to check_xxx functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23566>
_______________________________________

From report at bugs.python.org  Fri Mar 13 07:05:16 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 13 Mar 2015 06:05:16 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426226716.28.0.824438897368.issue2211@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


Added file: http://bugs.python.org/file38466/issue2211_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Fri Mar 13 07:09:34 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 13 Mar 2015 06:09:34 +0000
Subject: [issue22852] urllib.parse wrongly strips empty #fragment
In-Reply-To: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za>
Message-ID: <1426226974.98.0.139543569319.issue22852@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22852>
_______________________________________

From report at bugs.python.org  Fri Mar 13 07:32:27 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Mar 2015 06:32:27 +0000
Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()]
 deadlock
In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za>
Message-ID: <20150313063224.28831.28526@psf.io>


Roundup Robot added the comment:

New changeset 525ccfcc55f7 by Serhiy Storchaka in branch '3.4':
Issue #23051: multiprocessing.Pool methods imap() and imap_unordered() now
https://hg.python.org/cpython/rev/525ccfcc55f7

New changeset 7891d084a9ad by Serhiy Storchaka in branch 'default':
Issue #23051: multiprocessing.Pool methods imap() and imap_unordered() now
https://hg.python.org/cpython/rev/7891d084a9ad

New changeset 311d52878a65 by Serhiy Storchaka in branch '2.7':
Issue #23051: multiprocessing.Pool methods imap() and imap_unordered() now
https://hg.python.org/cpython/rev/311d52878a65

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23051>
_______________________________________

From report at bugs.python.org  Fri Mar 13 07:33:43 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Mar 2015 06:33:43 +0000
Subject: [issue23051] multiprocessing.pool methods imap()[_unordered()]
 deadlock
In-Reply-To: <1418597249.2.0.790454761619.issue23051@psf.upfronthosting.co.za>
Message-ID: <1426228423.7.0.802822587563.issue23051@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your contribution Alon and Davin.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23051>
_______________________________________

From report at bugs.python.org  Fri Mar 13 07:47:15 2015
From: report at bugs.python.org (John Nagle)
Date: Fri, 13 Mar 2015 06:47:15 +0000
Subject: [issue23655] Memory corruption using pickle over pipe to subprocess
Message-ID: <1426229235.01.0.332656133041.issue23655@psf.upfronthosting.co.za>


New submission from John Nagle:

I'm porting a large, working system from Python 2 to Python 3, using "six", so the same code works with both. One part of the system works a lot like the multiprocessing module, but predates it. It launches child processes with "Popen" and talks to them using "pickle" over stdin/stdout as pipes.  Works fine under Python 2, and has been working in production for years.

Under Python 3, I'm getting errors that indicate memory corruption:

Fatal Python error: GC object already tracked

Current thread 0x00001a14 (most recent call first):
  File "C:\python34\lib\site-packages\pymysql\connections.py", line 411
in description
  File "C:\python34\lib\site-packages\pymysql\connections.py", line 1248
in _get_descriptions
  File "C:\python34\lib\site-packages\pymysql\connections.py", line 1182
in _read_result_packet
  File "C:\python34\lib\site-packages\pymysql\connections.py", line 1132
in read
  File "C:\python34\lib\site-packages\pymysql\connections.py", line 929
in _read_query_result
  File "C:\python34\lib\site-packages\pymysql\connections.py", line 768
in query
  File "C:\python34\lib\site-packages\pymysql\cursors.py", line 282 in
_query
  File "C:\python34\lib\site-packages\pymysql\cursors.py", line 134 in
execute
  File "C:\projects\sitetruth\domaincacheitem.py", line 128 in select
  File "C:\projects\sitetruth\domaincache.py", line 30 in search
  File "C:\projects\sitetruth\ratesite.py", line 31 in ratedomain
  File "C:\projects\sitetruth\RatingProcess.py", line 68 in call
  File "C:\projects\sitetruth\subprocesscall.py", line 140 in docall
  File "C:\projects\sitetruth\subprocesscall.py", line 158 in run
  File "C:\projects\sitetruth\RatingProcess.py", line 89 in main
  File "C:\projects\sitetruth\RatingProcess.py", line 95 in <module>

That's clear memory corruption.

Also,

  File "C:\projects\sitetruth\InfoSiteRating.py", line 200, in scansite
    if len(self.badbusinessinfo) > 0 :                  # if bad stuff
NameError: name 'len' is not defined

There are others, but those two should be impossible to cause from Python source. 

I've done the obvious stuff - deleted all .pyc files and Python cache directories.  All my code is in Python. Every library module came in via "pip", into a clean Python 3.4.3 (32 bit) installation on Win7/x86-64.

Currently installed packages (via "pip list")

beautifulsoup4 (4.3.2)
dnspython3 (1.12.0)
html5lib (0.999)
pip (6.0.8)
PyMySQL (0.6.6)
pyparsing (2.0.3)
setuptools (12.0.5)
six (1.9.0)

Nothing exotic there.  The project has zero local C code; any C code came 
from the Python installation or the above packages, most of which are pure Python.

It all works fine with Python 2.7.9.  Everything else in the program seems
to be working fine under both 2.7.9 and 3.4.3, until subprocesses are involved.

What's being pickled is very simple; no custom objects, although Exception types are sometimes pickled if the subprocess raises an exception.  

Pickler and Unpickler instances are being reused here.  A message is pickled, piped to the subprocess, unpickled, work is done, and a response comes back later via the return pipe.  A send looks like:

    self.writer.dump(args)      # send data
    self.dataout.flush()        # finish output
    self.writer.clear_memo()    # no memory from cycle to cycle

and a receive looks like:

    result = self.reader.load() # read and return from child
    self.reader.memo = {}       # no memory from cycle to cycle

Those were the recommended way to reset "pickle" for new traffic years ago.
(You have to clear the receive side as well as the send side, or the dictionary
of saved objects grows forever.) My guess is that there's something about reusing "pickle" instances that botches memory uses in CPython 3's C code 
for "cpickle".  That should work, though; the "multiprocessing" module works
by sending pickled data over pipes.

The only code difference between Python 2 and 3 is that under Python 3 I have to use "sys.stdin.buffer" and "sys.stdout.buffer" as arguments to Pickler and Unpickler. Otherwise they complain that they're getting type "str".

Unfortunately, I don't have an easy way to reproduce this bug yet. 

Is there some way to force the use of the pure Python pickle module under Python 3? That would help isolate the problem.

				John Nagle

----------
components: Library (Lib)
messages: 238009
nosy: nagle
priority: normal
severity: normal
status: open
title: Memory corruption using pickle over pipe to subprocess
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23655>
_______________________________________

From report at bugs.python.org  Fri Mar 13 08:10:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Mar 2015 07:10:58 +0000
Subject: [issue23138] cookiejar parses cookie value as int with empty
 name-value pair and Expires
In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za>
Message-ID: <20150313071055.1853.45710@psf.io>


Roundup Robot added the comment:

New changeset 44c1c0cbdc06 by Serhiy Storchaka in branch '2.7':
Issue #23138: Fixed parsing cookies with absent keys or values in cookiejar.
https://hg.python.org/cpython/rev/44c1c0cbdc06

New changeset c1abcbcfefab by Serhiy Storchaka in branch '3.4':
Issue #23138: Fixed parsing cookies with absent keys or values in cookiejar.
https://hg.python.org/cpython/rev/c1abcbcfefab

New changeset 7cc7c794d1cb by Serhiy Storchaka in branch 'default':
Issue #23138: Fixed parsing cookies with absent keys or values in cookiejar.
https://hg.python.org/cpython/rev/7cc7c794d1cb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23138>
_______________________________________

From report at bugs.python.org  Fri Mar 13 08:17:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Mar 2015 07:17:20 +0000
Subject: [issue23138] cookiejar parses cookie value as int with empty
 name-value pair and Expires
In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za>
Message-ID: <1426231040.16.0.293669068929.issue23138@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

As side effect the parsing is now twice faster.

$ ./python -m timeit -s "from http.cookiejar import parse_ns_headers" -- "parse_ns_headers('foo=bar; Expires=Thu, 01 Jan 1970 00:00:10 GMT')"
Before: 1000 loops, best of 3: 976 usec per loop
After:  1000 loops, best of 3: 537 usec per loop

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23138>
_______________________________________

From report at bugs.python.org  Fri Mar 13 08:21:50 2015
From: report at bugs.python.org (Ian Lee)
Date: Fri, 13 Mar 2015 07:21:50 +0000
Subject: [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1426231310.98.0.926938703781.issue23639@psf.upfronthosting.co.za>


Changes by Ian Lee <ianlee1521 at gmail.com>:


----------
nosy: +IanLee1521

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23639>
_______________________________________

From report at bugs.python.org  Fri Mar 13 08:27:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Mar 2015 07:27:14 +0000
Subject: [issue23655] Memory corruption using pickle over pipe to subprocess
In-Reply-To: <1426229235.01.0.332656133041.issue23655@psf.upfronthosting.co.za>
Message-ID: <1426231634.12.0.201059433749.issue23655@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

sys.modules['_pickle']
del sys.modules['pickle'] # if exists
import pickle

Or just use pickle._Pickler instead of pickle.Pickler and like (implementation detail!).

----------
nosy: +alexandre.vassalotti, pitrou, serhiy.storchaka
stage:  -> test needed
type:  -> behavior
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23655>
_______________________________________

From report at bugs.python.org  Fri Mar 13 09:13:02 2015
From: report at bugs.python.org (Hiroaki Miyajima)
Date: Fri, 13 Mar 2015 08:13:02 +0000
Subject: [issue23656] shutil.copyfile (or built-in open) releases sqlite3's
 transaction lock
Message-ID: <1426234382.55.0.94867097951.issue23656@psf.upfronthosting.co.za>


New submission from Hiroaki Miyajima:

When copying sqlite3's database file by shutil.copyfile while holding its transaction lock, its lock is released unexpectedly.

Attached is a sample program showing this. Inside,
process-1 and process-2 just do following steps respectively:
   (1) open a sqlite dbfile
   (2) execute('begin EXCLUSIVE transaction') to acquire lock
   (3) copy the dbfile
   (4) sleep some seconds for demonstration
   (4) rollback() to release lock

if shutil.copyfile() is used as (3), process-2 gets a lock
while process-1 must hold a lock.
It seems that this happens if database file is opened with built-in open(), which is used in shutil.copyfile.

In addition,
- With os.open(), there seems no problem.
- With linux cp command, it works correct.
- Using multi-thread instead of multi-process, it works expectedly.

I think this is a bug, but does someone explain this behaviour?
Thank you.

Below is the execute example of the attached on python 2.7.9.
----------
# python Test_sqlite3_lock.py
Use <function shutil_copyfile at 0x7fe810b22500>
process-1 : Transaction lock acquired
process-2 : Transaction lock acquired
process-1 : Transaction lock released
process-2 : Transaction lock released

Use <function low_copyfile at 0x7fe810b22578>
process-1 : Transaction lock acquired
process-1 : Transaction lock released
process-2 : Transaction lock acquired
process-2 : Transaction lock released

Use <function command_copyfile at 0x7fe810b225f0>
process-1 : Transaction lock acquired
process-1 : Transaction lock released
process-2 : Transaction lock acquired
process-2 : Transaction lock released

----------

----------
files: Test_sqlite3_lock.py
messages: 238013
nosy: h-miyajima
priority: normal
severity: normal
status: open
title: shutil.copyfile (or built-in open) releases sqlite3's transaction lock
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file38467/Test_sqlite3_lock.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23656>
_______________________________________

From report at bugs.python.org  Fri Mar 13 09:39:45 2015
From: report at bugs.python.org (Alex Shkop)
Date: Fri, 13 Mar 2015 08:39:45 +0000
Subject: [issue23645] Incorrect doc for __getslice__
In-Reply-To: <1426173876.09.0.220076074076.issue23645@psf.upfronthosting.co.za>
Message-ID: <1426235985.66.0.0285242313603.issue23645@psf.upfronthosting.co.za>


Alex Shkop added the comment:

This is true. In ceval.c default value for end index is PY_SSIZE_T_MAX. Whereas in sysmodule.c defined:

SET_SYS_FROM_STRING("maxsize",
                    PyInt_FromSsize_t(PY_SSIZE_T_MAX));
SET_SYS_FROM_STRING("maxint",
                    PyInt_FromLong(PyInt_GetMax()));

I added a patch that fixes documentation. But please note, that __getslice__ is deprecated since Python 2.0 and is no longer supported in Python 3. Use __getitem__ instead.

----------
keywords: +patch
nosy: +ashkop
Added file: http://bugs.python.org/file38468/issue23645.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23645>
_______________________________________

From report at bugs.python.org  Fri Mar 13 10:00:48 2015
From: report at bugs.python.org (=?utf-8?q?Ga=C3=ABtan_de_Menten?=)
Date: Fri, 13 Mar 2015 09:00:48 +0000
Subject: [issue23645] Incorrect doc for __getslice__
In-Reply-To: <1426173876.09.0.220076074076.issue23645@psf.upfronthosting.co.za>
Message-ID: <1426237248.37.0.725271521406.issue23645@psf.upfronthosting.co.za>


Ga?tan de Menten added the comment:

Thanks for creating the patch! 

PS: I know it is deprecated. But I am stuck on Python2 for that project and my class inherits from numpy ndarray, so I do not have a choice...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23645>
_______________________________________

From report at bugs.python.org  Fri Mar 13 10:17:04 2015
From: report at bugs.python.org (Jean-Charles Lefebvre)
Date: Fri, 13 Mar 2015 09:17:04 +0000
Subject: [issue17797] Visual C++ 11.0 reports fileno(stdin) == 0 for
 non-console program
In-Reply-To: <1366373912.56.0.138468709297.issue17797@psf.upfronthosting.co.za>
Message-ID: <1426238224.15.0.321099862618.issue17797@psf.upfronthosting.co.za>


Jean-Charles Lefebvre added the comment:

Well, just in case, I've attached the patch to apply against 3.5.0a2.

----------
Added file: http://bugs.python.org/file38469/python-3.5.0a2-fdvalidation.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17797>
_______________________________________

From report at bugs.python.org  Fri Mar 13 10:18:28 2015
From: report at bugs.python.org (James Rutherford)
Date: Fri, 13 Mar 2015 09:18:28 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <1426238308.76.0.729078293087.issue23539@psf.upfronthosting.co.za>


James Rutherford added the comment:

Hi all, apologies for the spam, but I just wanted to confirm that no-one is waiting on anything from me... I'm happy to consolidate the final minor points & make the patch against python3 if that would simplify things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23539>
_______________________________________

From report at bugs.python.org  Fri Mar 13 11:14:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Mar 2015 10:14:32 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>
Message-ID: <20150313101429.118027.68955@psf.io>


Roundup Robot added the comment:

New changeset 211e29335e72 by Victor Stinner in branch 'default':
Issue #23566: Skip "fd" tests of test_faulthandler on Windows
https://hg.python.org/cpython/rev/211e29335e72

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23566>
_______________________________________

From report at bugs.python.org  Fri Mar 13 11:17:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Mar 2015 10:17:45 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <20150313101429.118027.68955@psf.io>
Message-ID: <CAMpsgwbKHPcixjW-PqhH8j+QZT7GGM64aUDRRfsjuW_BH-EDVw@mail.gmail.com>


STINNER Victor added the comment:

I commited a fix to repair Windows buildbots.

> Or we could reuse the file created by filename in subprocess?

I tried to pass a file descriptor from the parent to the child
process, but this option is complex. It's possible to pass a handle
with close_fds=False, but then I have to recreate a file descriptor
with a function from msvcrt.open_fshandle(). This solution looks
complex for a simple unit test.

Your solution looks simple. Would you like to work on a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23566>
_______________________________________

From report at bugs.python.org  Fri Mar 13 11:18:44 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 13 Mar 2015 10:18:44 +0000
Subject: [issue9679] unicode DNS names in urllib, urlopen
In-Reply-To: <1282721968.42.0.723881796109.issue9679@psf.upfronthosting.co.za>
Message-ID: <1426241924.15.0.372334614538.issue9679@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +demian.brecht

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9679>
_______________________________________

From report at bugs.python.org  Fri Mar 13 11:26:15 2015
From: report at bugs.python.org (Christoph Sieghart)
Date: Fri, 13 Mar 2015 10:26:15 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>
Message-ID: <1426242375.86.0.278663534945.issue23566@psf.upfronthosting.co.za>


Changes by Christoph Sieghart <sigi at 0x2a.at>:


----------
nosy:  -sigi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23566>
_______________________________________

From report at bugs.python.org  Fri Mar 13 11:27:59 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Mar 2015 10:27:59 +0000
Subject: [issue23654] infinite loop in faulthandler._stack_overflow
In-Reply-To: <1426200687.84.0.455927631723.issue23654@psf.upfronthosting.co.za>
Message-ID: <1426242479.59.0.171794553559.issue23654@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> When the faulthandler module is compiled at -O3 (the default for non-debug builds) with a compiler that does tailcall optimization ...

test_faulthandler pass with GCC 4.9.2 (Fedora 21) when faulthandler.c is compiled in -O3 mode. I guess that such config doesn't support tailcall optimization.

I guess that this issue is currently specific to Intel C compiler (ICC), right?

> ... with a compiler that does tailcall optimization the Modules/faulthandler.c:stack_overflow() function may become an infinite loop that does not expand the stack.

Hum, I didn't expect that I would be so hard to write a reliable stack overflow :-) I modified recently the function in issue #23433 to a different issue with void*/intptr_t conversion.

My function writes into a buffer allocated on the stack. How the compiler avoids to allocate 4 KB for each loop iteration? It doesn't matter if the function is recursive or not, it only matters if each iteration allocates 4 KB on the stack.

I'm writing into the buffer allocated on the stack to ensure that the buffer is really allocated. Maybe the pattern is too reliable?

Can you try to mark the buffer with the volatile keyword? (See attached patch.) This keyword is already used in faulthandler_read_null() and faulthandler_sigfpe() to workaround issues with compiler optimizations. (See attached patch.)

----------
Added file: http://bugs.python.org/file38470/volatile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23654>
_______________________________________

From report at bugs.python.org  Fri Mar 13 11:32:52 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Mar 2015 10:32:52 +0000
Subject: [issue13290] get vars for object with __slots__
In-Reply-To: <1319871850.77.0.869546838833.issue13290@psf.upfronthosting.co.za>
Message-ID: <1426242772.94.0.978457450401.issue13290@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, this was incorrect example. The correct one is:

$ ./python -m timeit -s "from http.cookiejar import parse_ns_headers" -- "parse_ns_headers(['foo=bar; path=/; version=1; Expires=Thu, 01 Jan 1970 00:00:10 GMT'])"
Before: 10000 loops, best of 3: 177 usec per loop
After:  10000 loops, best of 3: 104 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13290>
_______________________________________

From report at bugs.python.org  Fri Mar 13 11:33:39 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Mar 2015 10:33:39 +0000
Subject: [issue13290] get vars for object with __slots__
In-Reply-To: <1319871850.77.0.869546838833.issue13290@psf.upfronthosting.co.za>
Message-ID: <1426242819.81.0.0481233572643.issue13290@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
Removed message: http://bugs.python.org/msg238021

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13290>
_______________________________________

From report at bugs.python.org  Fri Mar 13 11:34:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Mar 2015 10:34:11 +0000
Subject: [issue23138] cookiejar parses cookie value as int with empty
 name-value pair and Expires
In-Reply-To: <1420002389.34.0.647467472383.issue23138@psf.upfronthosting.co.za>
Message-ID: <1426242851.22.0.55180550828.issue23138@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, this was incorrect example. The correct one is:

$ ./python -m timeit -s "from http.cookiejar import parse_ns_headers" -- "parse_ns_headers(['foo=bar; path=/; version=1; Expires=Thu, 01 Jan 1970 00:00:10 GMT'])"
Before: 10000 loops, best of 3: 177 usec per loop
After:  10000 loops, best of 3: 104 usec per loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23138>
_______________________________________

From report at bugs.python.org  Fri Mar 13 11:37:53 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Mar 2015 10:37:53 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1426243073.89.0.00873686546561.issue23605@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I don't understand your benchmark. Do you mean that os.walk() is slower with fast_bottom-up.patch because islink() is called or because I replaced "for entry in scandir(top):" with "entry = next(scandir_it)"?

Are you testing the top-bottom or bottom-up?

Here is a variant of my patch with "for entry in scandir(top):". I would prefer to avoid this variant with a boolean to not catch OSError on the recursive call to walk() if next() has similar performances.

----------
Added file: http://bugs.python.org/file38471/fast_bottom-up-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Fri Mar 13 13:19:32 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Mar 2015 12:19:32 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1426249172.06.0.988278624954.issue23605@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

You fast_bottom-up looks awesome, but much more correct. This is what I meant when warned that correct implementations with scandir() will be complex.

Could you please add a test based on my example (i.e. converting symlinks to a directory during walking) and may be other (creating new directory and adding it to the dirs list)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Fri Mar 13 13:48:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Mar 2015 12:48:15 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <1426250895.56.0.845426638915.issue23539@psf.upfronthosting.co.za>


R. David Murray added the comment:

It would...I've started twice to do the commit and gotten interrupted both times.  Having a patch I can just apply would help.  If you would be willing to also generate a patch for python3, that would be a help as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23539>
_______________________________________

From report at bugs.python.org  Fri Mar 13 13:53:30 2015
From: report at bugs.python.org (Ben Hoyt)
Date: Fri, 13 Mar 2015 12:53:30 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1426251210.7.0.567034720947.issue23605@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

> I don't understand your benchmark. Do you mean that os.walk() is slower
> with fast_bottom-up.patch because islink() is called or because I replaced
> "for entry in scandir(top):" with "entry = next(scandir_it)"?

No, sorry, I was making two separate comments: 1) the code's gotten quite a bit more complex (and if it needs to be that way for correctness, I'm okay with that), and 2) I'm surprised at how fast it still is.

> Are you testing the top-bottom or bottom-up?

My benchmark.py calls os.walk() with topdown=True, which is the default. I was testing the Python 3.4 version of os.walk() via listdir against your fast_bottom-up.patch.

I'm keen to look into this a bit further, but it won't be today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Fri Mar 13 14:16:56 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 Mar 2015 13:16:56 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1426252616.94.0.281492247258.issue23605@psf.upfronthosting.co.za>


STINNER Victor added the comment:

>> Are you testing the top-bottom or bottom-up?
> My benchmark.py calls os.walk() with topdown=True, which is the default.

Is it worth to mention in the os.walk() doc that topdown=False can be faster?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Fri Mar 13 15:42:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Mar 2015 14:42:18 +0000
Subject: [issue23491] PEP 441 - Improving Python Zip Application Support
In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za>
Message-ID: <20150313144213.32073.70414@psf.io>


Roundup Robot added the comment:

New changeset d1e9f337fea1 by Brett Cannon in branch 'default':
Issue #23491: Implement PEP 441: Improving Python Zip Application Support
https://hg.python.org/cpython/rev/d1e9f337fea1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23491>
_______________________________________

From report at bugs.python.org  Fri Mar 13 15:45:26 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Mar 2015 14:45:26 +0000
Subject: [issue23491] PEP 441 - Improving Python Zip Application Support
In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za>
Message-ID: <1426257926.1.0.955885075994.issue23491@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the patch, Paul! I touched up the formatting to be more PEP 8 compliant and fixed the tests as they initially failed for me (TESTFN didn't exist prior to you trying to make a directory, so it just failed; switched to tempfile.TemporaryDirectory instead).

----------
nosy: +brett.cannon
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23491>
_______________________________________

From report at bugs.python.org  Fri Mar 13 15:50:10 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Mar 2015 14:50:10 +0000
Subject: [issue23657] Don't do isinstance checks in zipapp
Message-ID: <1426258210.85.0.503105299924.issue23657@psf.upfronthosting.co.za>


New submission from Brett Cannon:

As it stand, zipapp's code checks for str and then otherwise assumes an object is a file-like object. It might work out better to do some duck typing and simply check if an object has 'read' and 'readline' attributes then it's a file-like object and otherwise that it's a path.

Doing this would then potentially make it easier to use pathlib.Path through the module rather than the os module.

----------
assignee: pmoore
components: Library (Lib)
messages: 238030
nosy: brett.cannon, pmoore
priority: normal
severity: normal
stage: needs patch
status: open
title: Don't do isinstance checks in zipapp
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23657>
_______________________________________

From report at bugs.python.org  Fri Mar 13 16:04:53 2015
From: report at bugs.python.org (Paul Moore)
Date: Fri, 13 Mar 2015 15:04:53 +0000
Subject: [issue23657] Don't do isinstance checks in zipapp
In-Reply-To: <1426258210.85.0.503105299924.issue23657@psf.upfronthosting.co.za>
Message-ID: <1426259093.2.0.337001925484.issue23657@psf.upfronthosting.co.za>


Paul Moore added the comment:

That sounds reasonable. I'll have a look at this. The code was originally based on a similar pattern in the zipfile module, so maybe zipfile should be changed in the same way?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23657>
_______________________________________

From report at bugs.python.org  Fri Mar 13 16:06:38 2015
From: report at bugs.python.org (Paul Moore)
Date: Fri, 13 Mar 2015 15:06:38 +0000
Subject: [issue23491] PEP 441 - Improving Python Zip Application Support
In-Reply-To: <1424436771.29.0.353849461373.issue23491@psf.upfronthosting.co.za>
Message-ID: <1426259198.91.0.854163899275.issue23491@psf.upfronthosting.co.za>


Paul Moore added the comment:

Thanks Brett! Apologies about the TESTFN issue - I changed it (from TemporaryDirectory, in fact) based on one of the review comments - it looks like I didn't test the change properly. My mistake, thanks for catching it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23491>
_______________________________________

From report at bugs.python.org  Fri Mar 13 16:12:23 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Mar 2015 15:12:23 +0000
Subject: [issue23657] Don't do isinstance checks in zipapp
In-Reply-To: <1426258210.85.0.503105299924.issue23657@psf.upfronthosting.co.za>
Message-ID: <1426259543.11.0.411538009822.issue23657@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Here is a proposed patch that does what I was thinking. What do you think?

As for updating zipfile, it's possible but slightly risky because of backwards-compatibility. Since this is all-new code there is no worry about breaking someone's pre-existing code because they were relying on str being treated in a special way instead of the file-like object case.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file38472/duck_typed_zipapp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23657>
_______________________________________

From report at bugs.python.org  Fri Mar 13 16:15:44 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Mar 2015 15:15:44 +0000
Subject: [issue23643] Segmentation Fault with Large Simple Function
In-Reply-To: <1426094044.96.0.525794841659.issue23643@psf.upfronthosting.co.za>
Message-ID: <1426259744.36.0.455077978475.issue23643@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23643>
_______________________________________

From report at bugs.python.org  Fri Mar 13 16:22:22 2015
From: report at bugs.python.org (Dan Nawrocki)
Date: Fri, 13 Mar 2015 15:22:22 +0000
Subject: [issue23658] multiprocessing: string arg to SystemExit
Message-ID: <1426260142.17.0.720553845147.issue23658@psf.upfronthosting.co.za>


New submission from Dan Nawrocki:

It seems that the fix for 13854 (http://bugs.python.org/issue13854) actually tried to solve 2 issues:

1. handle non-integer, non-string arg to SystemExit
2. use exit code of 0 when the arg was a string

The change involved for #2 seems to go against the documentation for sys.exit:

"...In particular, sys.exit("some error message") is a quick way to exit a program when an error occurs."

Indeed, python 2.7.5 appears to follow this behavior:

[me at localhost ~]$ python -c 'raise SystemExit("bye")'; echo $?
bye
1

Shouldn't the return code from a subprocess when using multiprocessing match the return code when called w/o the multiprocessing module?

----------
components: Library (Lib)
messages: 238034
nosy: Dan Nawrocki
priority: normal
severity: normal
status: open
title: multiprocessing: string arg to SystemExit
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23658>
_______________________________________

From report at bugs.python.org  Fri Mar 13 16:31:25 2015
From: report at bugs.python.org (Vladimir Ulupov)
Date: Fri, 13 Mar 2015 15:31:25 +0000
Subject: [issue23659] csv.register_dialect  doc string
Message-ID: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>


New submission from Vladimir Ulupov:

I use PyCharm. This IDE checks the signature functions.
When I used the extra arguments to the function register_dialect - IDE reported error.

This is what has generated IDE for this function.
http://dumpz.org/1347592/

Apparently error here
https://hg.python.org/cpython/file/44c1c0cbdc06/Modules/_csv.c#l1547
https://hg.python.org/cpython/file/c1abcbcfefab/Modules/_csv.c#l1590


https://docs.python.org/2/library/csv.html?highlight=csv#csv.register_dialect
https://docs.python.org/3/library/csv.html?highlight=csv#csv.register_dialect

----------
assignee: docs at python
components: Documentation
messages: 238035
nosy: Vladimir Ulupov, docs at python
priority: normal
severity: normal
status: open
title: csv.register_dialect  doc string
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23659>
_______________________________________

From report at bugs.python.org  Fri Mar 13 16:33:12 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Mar 2015 15:33:12 +0000
Subject: [issue23659] csv.register_dialect  doc string
In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>
Message-ID: <1426260792.19.0.368120964979.issue23659@psf.upfronthosting.co.za>


R. David Murray added the comment:

Could you clarify what bug in python you are reporting?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23659>
_______________________________________

From report at bugs.python.org  Fri Mar 13 16:37:39 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 13 Mar 2015 15:37:39 +0000
Subject: [issue23659] csv.register_dialect  doc string
In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>
Message-ID: <1426261059.1.0.225687893818.issue23659@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23659>
_______________________________________

From report at bugs.python.org  Fri Mar 13 16:42:52 2015
From: report at bugs.python.org (Andre Roberge)
Date: Fri, 13 Mar 2015 15:42:52 +0000
Subject: [issue23660] Turtle left/right inverted when using different
 coordinates orientation
Message-ID: <1426261372.66.0.413514291582.issue23660@psf.upfronthosting.co.za>


New submission from Andre Roberge:

The turtle module using screen coordinates such that the vertical coordinate increases vertically on the screen. This orientation is different from the traditional orientation for graphics programs.

It is possible to set coordinates with the "normal" orientation using the setworldcoordinates function, e.g.

    >>> from turtle import *
    >>> setworldcoordinates(0, 400, 400, 0)

With the above choice, the y coordinate increases as the turtle moves down on the screen.  However, doing so inverts the role of left() and right().

I have attached a "diff" file which introduces a change needed so that left() and right() behave correctly with this different orientation.

----------
files: turtle_diff.txt
messages: 238037
nosy: aroberge
priority: normal
severity: normal
status: open
title: Turtle left/right inverted when using different coordinates orientation
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file38473/turtle_diff.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23660>
_______________________________________

From report at bugs.python.org  Fri Mar 13 16:43:03 2015
From: report at bugs.python.org (Paul Moore)
Date: Fri, 13 Mar 2015 15:43:03 +0000
Subject: [issue23657] Don't do isinstance checks in zipapp
In-Reply-To: <1426258210.85.0.503105299924.issue23657@psf.upfronthosting.co.za>
Message-ID: <1426261383.63.0.975617858717.issue23657@psf.upfronthosting.co.za>


Paul Moore added the comment:

Looks good. Would it be worth adding tests for providing pathlib.Path objects, or is that overkill?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23657>
_______________________________________

From report at bugs.python.org  Fri Mar 13 17:49:36 2015
From: report at bugs.python.org (Nathan Cox)
Date: Fri, 13 Mar 2015 16:49:36 +0000
Subject: [issue16318] FTP_TLS in ftplib not supporting prot_p storlines in
 FTP7.5
In-Reply-To: <1351120164.32.0.969400884781.issue16318@psf.upfronthosting.co.za>
Message-ID: <1426265376.84.0.949988887322.issue16318@psf.upfronthosting.co.za>


Nathan Cox added the comment:

I have this issue intermittently with a server that I connect to, but the issue (at least for me) seems to be the minBytesPerSecond configuration triggering a remote disconnect of the connection.

----------
nosy: +Nathan Cox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16318>
_______________________________________

From report at bugs.python.org  Fri Mar 13 18:02:36 2015
From: report at bugs.python.org (James Rutherford)
Date: Fri, 13 Mar 2015 17:02:36 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <1426266156.69.0.497555427074.issue23539@psf.upfronthosting.co.za>


James Rutherford added the comment:

Ok I'll have a go at a consolidated python3 patch tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23539>
_______________________________________

From report at bugs.python.org  Fri Mar 13 18:22:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Mar 2015 17:22:27 +0000
Subject: [issue23658] multiprocessing: string arg to SystemExit
In-Reply-To: <1426260142.17.0.720553845147.issue23658@psf.upfronthosting.co.za>
Message-ID: <1426267347.02.0.342120427881.issue23658@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23658>
_______________________________________

From report at bugs.python.org  Fri Mar 13 18:25:56 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Mar 2015 17:25:56 +0000
Subject: [issue23628] See if os.scandir() could help speed up importlib
In-Reply-To: <1425998502.08.0.152155367822.issue23628@psf.upfronthosting.co.za>
Message-ID: <1426267556.48.0.153404418481.issue23628@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The answer is no.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23628>
_______________________________________

From report at bugs.python.org  Fri Mar 13 18:29:54 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Mar 2015 17:29:54 +0000
Subject: [issue23642] Interaction of ModuleSpec and C Extension Modules
In-Reply-To: <1426086531.98.0.531682777516.issue23642@psf.upfronthosting.co.za>
Message-ID: <1426267794.75.0.801782334614.issue23642@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The PEP is now live: https://www.python.org/dev/peps/pep-0489/ . If you want to participate in the discussion it will probably happen on the import-sig.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23642>
_______________________________________

From report at bugs.python.org  Fri Mar 13 18:33:16 2015
From: report at bugs.python.org (Chris Rebert)
Date: Fri, 13 Mar 2015 17:33:16 +0000
Subject: [issue23622] Deprecate unrecognized backslash+letter escapes
In-Reply-To: <1425907707.07.0.452600036872.issue23622@psf.upfronthosting.co.za>
Message-ID: <1426267996.88.0.437448535618.issue23622@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23622>
_______________________________________

From report at bugs.python.org  Fri Mar 13 18:57:35 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Mar 2015 17:57:35 +0000
Subject: [issue23614] Opaque error message on UTF-8 decoding to surrogates
In-Reply-To: <1425850595.48.0.491367645605.issue23614@psf.upfronthosting.co.za>
Message-ID: <1426269455.76.0.231217505884.issue23614@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The Table 3-7 of http://www.unicode.org/versions/Unicode5.2.0/ch03.pdf (page 93 of the book, or 40 of the pdf) shows that if the start byte is ED the continuation byte must be in range 80..9F.  This means that, in order to decode a sequence starting with ED, you need two more valid continuation bytes.  Since the following byte (B4) is not in allowed range 80..9F and is thus an invalid continuation byte, the decoder doesn't know how to decode the byte in position 0 (i.e. ED).

It is also true that this particular sequence, if allowed, would result in a surrogate.  However, by looking at the first two bytes only, you don't have enough information to be sure about that (e.g. ED B4 00 begins doesn't decode to a surrogate, so Pike's error message is imprecise).

If handling this special case doesn't require too much extra code, it would be ok with me to have something like:
>>> b"\xed\xb4\x80".decode("utf-8")
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position 0: invalid continuation byte (possible start of a surrogate)

----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23614>
_______________________________________

From report at bugs.python.org  Fri Mar 13 18:59:42 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Mar 2015 17:59:42 +0000
Subject: [issue23623] Python 3.5 docs need to clarify how to set PATH, etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1426269582.48.0.757906290739.issue23623@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23623>
_______________________________________

From report at bugs.python.org  Fri Mar 13 19:03:34 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Mar 2015 18:03:34 +0000
Subject: [issue23622] Deprecate unrecognized backslash+letter escapes in re
In-Reply-To: <1425907707.07.0.452600036872.issue23622@psf.upfronthosting.co.za>
Message-ID: <1426269814.44.0.310906582837.issue23622@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
title: Deprecate unrecognized backslash+letter escapes -> Deprecate unrecognized backslash+letter escapes in re

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23622>
_______________________________________

From report at bugs.python.org  Fri Mar 13 19:06:05 2015
From: report at bugs.python.org (Wei Wu)
Date: Fri, 13 Mar 2015 18:06:05 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>
Message-ID: <1426269965.68.0.579317814874.issue23566@psf.upfronthosting.co.za>


Wei Wu added the comment:

The last approach I proposed requires some change in "template code" of check_xxx methods. To make it better, we can add a bool parameter to the check_xxx functions, True value indicating a fd test. If a filename is given at the same time, then a fd can get from that file. Otherwise the fd should be sys.stderr.fileno().

e.g.
file = None
fp = None
if filename:
    fp = open(filename, "wb")
    # Must use a different name to prevent the file from closing...
    file = fp
if fd:
    if fp is not None:
        file = fp.fileno()
    else:
        file = sys.stderr.fileno()

# file can be file-object, fd or None
(use_the_file_to_function...)


The fd-passing approach can co-exist with this one. However it will make "template code" more complex. So I suggest just use one approach to write these fd tests.

I will work on a patch(based on tip) at this weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23566>
_______________________________________

From report at bugs.python.org  Fri Mar 13 19:09:09 2015
From: report at bugs.python.org (Matt Frank)
Date: Fri, 13 Mar 2015 18:09:09 +0000
Subject: [issue23654] infinite loop in faulthandler._stack_overflow
In-Reply-To: <1426200687.84.0.455927631723.issue23654@psf.upfronthosting.co.za>
Message-ID: <1426270149.17.0.656682554122.issue23654@psf.upfronthosting.co.za>


Matt Frank added the comment:

Yes, this is currently only a problem with the Intel compiler.

The writes to buffer[] are dead (provably won't be ever used) at the point that the recursive call occurs.  Actually gcc and llvm can figure this out.  Thus all the space allocated for the first call can be reused by every subsequent call.

The analysis that icc is doing that gcc and clang are not yet doing has to do with the pointer to depth.  I believe icc is able to determine that depth doesn't point into buffer where gcc and clang aren't sure that this is the case.  (If you change stack_overflow() so that depth is passed in and returned by value then gcc also does the tail optimization.)

volatile doesn't disable the optimization.  I think in this case it is too easy to determine that buffer is on the stack, and both buffer and sp are dead by the time of the recursive call.

It occurs to me that the right way to deal with this is with

__attribute__ ((optimize ("no-optimize-sibling-calls")))

on the function where it matters (stack_overflow()).

I'm working on a solution (need to test whether the compiler supports attributes and etc.) and will post it ASAP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23654>
_______________________________________

From report at bugs.python.org  Fri Mar 13 19:17:36 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Mar 2015 18:17:36 +0000
Subject: [issue23637] Warnings error with non-ascii chars.
In-Reply-To: <1426062904.63.0.0951614232281.issue23637@psf.upfronthosting.co.za>
Message-ID: <1426270656.82.0.0244998303981.issue23637@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I think that the problem is actually with the file.write() in _show_warning().
If any of the arguments of formatwarning() are unicode, the result will be unicode, and if "file" (default sys.stderr) is opened in binary mode, Python will try to encode the unicode result with the ASCII codec and fail with a UnicodeEncodeError:

>>> warnings.showwarning(u'??', DeprecationWarning, 'foo.py', 10)
foo.py:10: DeprecationWarning: ??
>>> with open('err.log', 'wb') as f:
...     warnings.showwarning(u'??', DeprecationWarning, 'foo.py', 10, file=f)
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/usr/lib/python2.7/warnings.py", line 30, in _show_warning
    file.write(formatwarning(message, category, filename, lineno, line))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 31-32: ordinal not in range(128)

----------
nosy: +ezio.melotti
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23637>
_______________________________________

From report at bugs.python.org  Fri Mar 13 19:20:26 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Mar 2015 18:20:26 +0000
Subject: [issue23645] Incorrect doc for __getslice__
In-Reply-To: <1426173876.09.0.220076074076.issue23645@psf.upfronthosting.co.za>
Message-ID: <1426270826.42.0.748557716353.issue23645@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> patch review
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23645>
_______________________________________

From report at bugs.python.org  Fri Mar 13 19:48:19 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Mar 2015 18:48:19 +0000
Subject: [issue23637] Warnings error with non-ascii chars.
In-Reply-To: <1426062904.63.0.0951614232281.issue23637@psf.upfronthosting.co.za>
Message-ID: <1426272499.83.0.985827448581.issue23637@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The problem is not only with the file.write(). If one of arguments is unicode (even if it doesn't contain non-ascii characters) and other argument is non-ascii string, we get this error.

>>> warnings.showwarning(u'', DeprecationWarning, 'fil?.py', 10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython-2.7/Lib/warnings.py", line 33, in _show_warning
    file.write(formatwarning(message, category, filename, lineno, line))
  File "/home/serhiy/py/cpython-2.7/Lib/warnings.py", line 42, in formatwarning
    s =  "%s:%s: %s: %s\n" % (filename, lineno, category.__name__, message)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3: ordinal not in range(128)

Non-ascii file names are rare, and unicode warnings are rare, that is why this bug was not fixed before. I think it is worth to fix. It is better to output modified warning (e.g. backslashescaped) than fail without clear diagnostic.

----------
nosy: +serhiy.storchaka
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23637>
_______________________________________

From report at bugs.python.org  Fri Mar 13 20:33:06 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Mar 2015 19:33:06 +0000
Subject: [issue23645] Incorrect doc for __getslice__
In-Reply-To: <1426173876.09.0.220076074076.issue23645@psf.upfronthosting.co.za>
Message-ID: <20150313193236.13203.50941@psf.io>


Roundup Robot added the comment:

New changeset 3b91d834160f by Benjamin Peterson in branch '2.7':
the default is sys.maxsize not sys.maxint (closes #23645)
https://hg.python.org/cpython/rev/3b91d834160f

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23645>
_______________________________________

From report at bugs.python.org  Fri Mar 13 20:48:31 2015
From: report at bugs.python.org (John Nagle)
Date: Fri, 13 Mar 2015 19:48:31 +0000
Subject: [issue23655] Memory corruption using pickle over pipe to subprocess
In-Reply-To: <1426229235.01.0.332656133041.issue23655@psf.upfronthosting.co.za>
Message-ID: <1426276111.16.0.0539155867263.issue23655@psf.upfronthosting.co.za>


John Nagle added the comment:

> Or just use pickle._Pickler instead of pickle.Pickler and like 
> (implementation detail!).

Tried that.  Changed my own code as follows:

25a26
> 
71,72c72,73
<         self.reader = pickle.Unpickler(self.proc.stdout)    # set up reader
<         self.writer = pickle.Pickler(self.proc.stdin,kpickleprotocolversion)
---
>         self.reader = pickle._Unpickler(self.proc.stdout)    # set up reader
>         self.writer = pickle._Pickler(self.proc.stdin,kpickleprotocolversion
125,126c126,127
<         self.reader = pickle.Unpickler(self.datain)     # set up reader
<         self.writer = pickle.Pickler(self.dataout,kpickleprotocolversion)   
---
>         self.reader = pickle._Unpickler(self.datain)     # set up reader
>         self.writer = pickle._Pickler(self.dataout,kpickleprotocolversion)  

Program runs after those changes.

So it looks like CPickle has a serious memory corruption problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23655>
_______________________________________

From report at bugs.python.org  Fri Mar 13 20:50:32 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 13 Mar 2015 19:50:32 +0000
Subject: [issue2052] Allow changing difflib._file_template character encoding.
In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za>
Message-ID: <1426276232.31.0.0304751674518.issue2052@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Here is an updated patch. Thanks for the review, Serhiy. I will open a new issue for the HTML 5 part of the patch.

----------
Added file: http://bugs.python.org/file38474/issue2052_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2052>
_______________________________________

From report at bugs.python.org  Fri Mar 13 21:22:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Mar 2015 20:22:36 +0000
Subject: [issue23637] Warnings error with non-ascii chars.
In-Reply-To: <1426062904.63.0.0951614232281.issue23637@psf.upfronthosting.co.za>
Message-ID: <1426278156.84.0.102363774391.issue23637@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that tries to coerce non-ascii filename and line to unicode using appropriate encoding if it is needed and possible. If it is not possible, the warning just gets lost, as in the case of IO error.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file38475/warnings_unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23637>
_______________________________________

From report at bugs.python.org  Fri Mar 13 21:33:44 2015
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 13 Mar 2015 20:33:44 +0000
Subject: [issue21518] Expose RegUnLoadKey in winreg
In-Reply-To: <1400346760.52.0.0203244636304.issue21518@psf.upfronthosting.co.za>
Message-ID: <1426278824.15.0.998313345297.issue21518@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

The naming of the function needs discussion. I think it should be UnLoadKey, as the API function behind it is RegUnLoadKey (not RegUnloadKey). It may be illogical(*) that the function is called that way in the API, but it would add confusion if Python called it differently.

(*) It's UnlockFile that pairs LockFile, and UnmapViewOfFile that matches MapViewOfFile. OTOH, (undocumented) UTRegister is paired with UTUnRegister, and GlobalWire with GlobalUnWire.

----------
nosy: +loewis
title: Expose RegUnloadKey in winreg -> Expose RegUnLoadKey in winreg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21518>
_______________________________________

From report at bugs.python.org  Fri Mar 13 21:42:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 Mar 2015 20:42:42 +0000
Subject: [issue23655] Memory corruption using pickle over pipe to subprocess
In-Reply-To: <1426229235.01.0.332656133041.issue23655@psf.upfronthosting.co.za>
Message-ID: <1426279362.92.0.374328126376.issue23655@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please try to minimize you data and try to reproduce an issue without using third-party modules if this is possible?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23655>
_______________________________________

From report at bugs.python.org  Fri Mar 13 22:18:23 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 13 Mar 2015 21:18:23 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426281503.04.0.474850641743.issue2211@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


Added file: http://bugs.python.org/file38476/issue2211_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Fri Mar 13 22:21:04 2015
From: report at bugs.python.org (Davin Potts)
Date: Fri, 13 Mar 2015 21:21:04 +0000
Subject: [issue23658] multiprocessing: string arg to SystemExit
In-Reply-To: <1426260142.17.0.720553845147.issue23658@psf.upfronthosting.co.za>
Message-ID: <1426281664.86.0.519376926536.issue23658@psf.upfronthosting.co.za>


Davin Potts added the comment:

Are you looking at the current code in the 2.7 branch or just at the code committed in https://hg.python.org/cpython/rev/da5b370f41a1 (done as part of issue13854)?

The code in 2.7 has since been updated and appears to use an exitcode of 1 whenever a str is provided as the arg to SystemExit.

Are you observing something different in practice?

----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23658>
_______________________________________

From report at bugs.python.org  Fri Mar 13 22:30:32 2015
From: report at bugs.python.org (John Nagle)
Date: Fri, 13 Mar 2015 21:30:32 +0000
Subject: [issue23655] Memory corruption using pickle over pipe to subprocess
In-Reply-To: <1426229235.01.0.332656133041.issue23655@psf.upfronthosting.co.za>
Message-ID: <1426282232.05.0.661358734723.issue23655@psf.upfronthosting.co.za>


John Nagle added the comment:

"minimize you data" - that's a big job here. Where are the tests for "pickle"?  Is there one that talks to a subprocess over a pipe? Maybe I can adapt that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23655>
_______________________________________

From report at bugs.python.org  Fri Mar 13 22:38:01 2015
From: report at bugs.python.org (Ned Deily)
Date: Fri, 13 Mar 2015 21:38:01 +0000
Subject: [issue23643] Segmentation Fault with Large Simple Function
In-Reply-To: <1426094044.96.0.525794841659.issue23643@psf.upfronthosting.co.za>
Message-ID: <1426282681.0.0.340944417199.issue23643@psf.upfronthosting.co.za>


Ned Deily added the comment:

(Closed by submitter.)

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> resolved
superseder:  -> stack overflow evaluating eval("()" * 30000)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23643>
_______________________________________

From report at bugs.python.org  Fri Mar 13 22:53:27 2015
From: report at bugs.python.org (Chris Angelico)
Date: Fri, 13 Mar 2015 21:53:27 +0000
Subject: [issue23614] Opaque error message on UTF-8 decoding to surrogates
In-Reply-To: <1425850595.48.0.491367645605.issue23614@psf.upfronthosting.co.za>
Message-ID: <1426283607.48.0.685234730526.issue23614@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Nice document. Is that actually how Python's decoder checks things? Does the decoder have different definitions of "valid continuation byte" based on the lead byte? If that's the case... well, ten out of ten for complying with the spec, to be sure, but unfortunately it leads to some opaque error messages!

I haven't looked into the code even a little bit, but would it be possible to have a specific error message attached to certain "invalid continuation bytes"?

* E0 followed by 80..9F: "non-shortest form"
* ED followed by A0..BF: "surrogate"
* F4 followed by 90..BF: "outside defined range"

If that's too hard, it'd at least be helpful to point out that the "invalid continuation byte" is not the same as the "byte 0x?? in position ?" - the rejection here is actually of the B4 that follows it. How does this look?

UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position 0: invalid continuation byte 0xb4 for this start byte

(BTW, I think Pike's decoder just always emits two bytes, no matter what the actual errant stream (after all, there's no way to know how many bytes "ought to have been" one character, when there's an error in it). So it's incomplete, yes, but when you're dealing with wrong data, completeness isn't all that possible anyway.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23614>
_______________________________________

From report at bugs.python.org  Fri Mar 13 23:16:35 2015
From: report at bugs.python.org (Danya Alexeyevsky)
Date: Fri, 13 Mar 2015 22:16:35 +0000
Subject: [issue23042] Python 2.7.9 ctypes module doesn't build on FreeBSD x86
In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za>
Message-ID: <1426284995.82.0.436542246905.issue23042@psf.upfronthosting.co.za>


Danya Alexeyevsky added the comment:

Faced the same problem on FreeBSD.

I confirm: applying the reversed patch fixed it.

Thanks!

----------
nosy: +Danya.Alexeyevsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23042>
_______________________________________

From report at bugs.python.org  Fri Mar 13 23:24:52 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Mar 2015 22:24:52 +0000
Subject: [issue23614] Opaque error message on UTF-8 decoding to surrogates
In-Reply-To: <1425850595.48.0.491367645605.issue23614@psf.upfronthosting.co.za>
Message-ID: <1426285492.53.0.728871893418.issue23614@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Nice document. Is that actually how Python's decoder checks things?

Yes, Python follows the Unicode standard.

> * E0 followed by 80..9F: "non-shortest form"
> * ED followed by A0..BF: "surrogate"
> * F4 followed by 90..BF: "outside defined range"

If you get a decode error while using UTF-8, it means that you are trying to decode something that is not (valid) UTF-8.  I can see 3 situations where this might happen:
1) the input is using a different encoding;
2) the input is corrupted;
3) the input is using an encoding similar to UTF-8 (e.g. CESU-8);

In the first two cases additional information about continuation bytes are meaningless and misleading (there's no such thing as short form or surrogates in e.g. ASCII).  In the third case (which is actually a special case of 1), mentioning surrogates and perhaps non-shortest form might be useful if the developer is intimately familiar with UTF-8 and Unicode since he might suspect that the input is actually CESU-8 or the text has been encoded by an outdated encoder that follows the RFC 2044 specs from 1996.

> How does this look?
>
> UnicodeDecodeError: 'utf-8' codec can't decode byte 0xed in position 0:
> invalid continuation byte 0xb4 for this start byte

Something similar would be ok with me, assuming is easy to implement in the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23614>
_______________________________________

From report at bugs.python.org  Fri Mar 13 23:27:27 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 13 Mar 2015 22:27:27 +0000
Subject: [issue9679] unicode DNS names in urllib, urlopen
In-Reply-To: <1282721968.42.0.723881796109.issue9679@psf.upfronthosting.co.za>
Message-ID: <1426285647.56.0.932890944234.issue9679@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Here's a simple patch that adds functionality matching that in http.client to urllib.request. As pointed out by John, I see no reason why urllib and http.client shouldn't have consistent handling if IDNs independent of IRIs (although IRI encoding would be a nice addition as well).

----------
keywords: +patch
Added file: http://bugs.python.org/file38477/issue9679.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9679>
_______________________________________

From report at bugs.python.org  Fri Mar 13 23:27:48 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 13 Mar 2015 22:27:48 +0000
Subject: [issue9679] unicode DNS names in urllib, urlopen
In-Reply-To: <1282721968.42.0.723881796109.issue9679@psf.upfronthosting.co.za>
Message-ID: <1426285668.86.0.160028957382.issue9679@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9679>
_______________________________________

From report at bugs.python.org  Fri Mar 13 23:32:09 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 13 Mar 2015 22:32:09 +0000
Subject: [issue9679] unicode DNS names in urllib, urlopen
In-Reply-To: <1282721968.42.0.723881796109.issue9679@psf.upfronthosting.co.za>
Message-ID: <1426285929.17.0.557190516851.issue9679@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
versions: +Python 3.5 -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9679>
_______________________________________

From report at bugs.python.org  Fri Mar 13 23:40:12 2015
From: report at bugs.python.org (Michael Goldish)
Date: Fri, 13 Mar 2015 22:40:12 +0000
Subject: [issue23187] Segmentation fault, possibly asyncio related
In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za>
Message-ID: <1426286412.75.0.548052363314.issue23187@psf.upfronthosting.co.za>


Michael Goldish added the comment:

> Why do you consider that it's the same issue?

Because it's a very similar stack trace, the crash itself is in subtype_dealloc(), it happens once every few days, asyncio is involved, and the issue is relatively new - I couldn't find another bug report with a similar description.

> I have core dumps if you're interested but am not sure where to upload them.

> You can try to use faulthandler to write the traceback of all Python threads where the crash occurred

I've enabled faulthandler, the program crashed, and nothing was written to the file. For reference, I caused an artificial crash in the same Python program (using ctypes) and the stack traces *were* written. I verified this several times, both with the real crash and the artificial one, and the real crash always left the file empty.

> I guess that Visual Studio can load such minidump files.

I've already looked at one of my dumps in Visual Studio but couldn't make sense of what was going on. The structures involved seemed to contain data that made no sense to me (e.g. some pointers had values like 0x10, which usually makes no sense for a pointer and seems to indicate memory corruption).

> Did you see some errors or warnings when running your application with asyncio in debug mode?

No, but I'll try. I doubt the problem is in asyncio itself because it's mostly written in Python. This looks like a garbage collection issue.

> Can you maybe send me the source code of your application?

I'll ask to see if that's permissible, but either way you will probably have a hard time reproducing the crash - the program is a server which maintains active TCP connections to more than 1000 client instances, writes large text files in background threads, pickles large objects... The frequency of the crash seems to be correlated to how busy the server is. Without a proper setup it'll be difficult to make it busy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23187>
_______________________________________

From report at bugs.python.org  Sat Mar 14 01:02:05 2015
From: report at bugs.python.org (Michael Clerx)
Date: Sat, 14 Mar 2015 00:02:05 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1426291325.56.0.499850016148.issue12641@psf.upfronthosting.co.za>


Michael Clerx added the comment:

I'm seeing this bug in 2.7.9. The reason seems to be that the version detection doesn't work...

This snippet:

  out = os.popen(gcc_exe + ' -dumpversion', 'r')
  out_string = out.read()

returns an empty out_string, causing gcc_version = None < '4'

Maybe the < '4' check could be restructured to see None as "probably modern" instead of "probably very out of date" ?

----------
nosy: +Michael.Clerx

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Sat Mar 14 01:05:19 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Mar 2015 00:05:19 +0000
Subject: [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1426291519.85.0.443432334258.issue23639@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Idlelib.rpc uses the somewhat arbitrary *strings* '__methods__' and '__attributes__' as private signals in its protocol.  They are not object or attribute names, special or otherwise, in the sense used here.

The use of '__methods__' in idlelib.rpc (line 176) harkens back to pre 2.2 days when __methods__ was officially used in the type introspection api.  That class attribute was "a list of method names supported by the object.".  See PEP 252.  Its complement was __members__, a list of non-method attributes (other than itself, I presume).  rpc uses '__attributes__' instead.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23639>
_______________________________________

From report at bugs.python.org  Sat Mar 14 01:13:44 2015
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 14 Mar 2015 00:13:44 +0000
Subject: [issue23556] Scope for raise without argument is different in Python
 2 and 3
In-Reply-To: <1425212072.31.0.66074782686.issue23556@psf.upfronthosting.co.za>
Message-ID: <1426292024.13.0.337160686485.issue23556@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23556>
_______________________________________

From report at bugs.python.org  Sat Mar 14 01:45:40 2015
From: report at bugs.python.org (Ignacio Rossi)
Date: Sat, 14 Mar 2015 00:45:40 +0000
Subject: [issue23661] Setting a exception side_effect on a mock from
 create_autospec does not work
Message-ID: <1426293940.15.0.253058774664.issue23661@psf.upfronthosting.co.za>


New submission from Ignacio Rossi:

The following fails on python 3.4.2, 3.4.3 and 3.5.0a2 (downloaded from python.org and compiled on Ubuntu 14.04). 
The same happens when using mock.patch with autospec=True.

>>> from unittest.mock import create_autospec
>>> def function():
...     pass
... 
>>> mock = create_autospec(function)
>>> mock.side_effect = ValueError('MyError')
>>> mock()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 3, in function
  File "/usr/local/lib/python3.5/unittest/mock.py", line 910, in __call__
    return _mock_self._mock_call(*args, **kwargs)
  File "/usr/local/lib/python3.5/unittest/mock.py", line 963, in _mock_call
    effect = self.side_effect
  File "/usr/local/lib/python3.5/unittest/mock.py", line 510, in __get_side_effect
    sf = _MockIter(sf)
  File "/usr/local/lib/python3.5/unittest/mock.py", line 351, in __init__
    self.obj = iter(obj)
TypeError: 'ValueError' object is not iterable

But, on Python 3.3.5, 3.4.0, or when the mock is created via Mock(), for  instance, the exception is raised as expected:

[...]
>>> mock()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 3, in function
  File "/usr/lib/python3.4/unittest/mock.py", line 885, in __call__
    return _mock_self._mock_call(*args, **kwargs)
  File "/usr/lib/python3.4/unittest/mock.py", line 941, in _mock_call
    raise effect
ValueError: MyError

----------
components: Library (Lib)
messages: 238064
nosy: Ignacio Rossi
priority: normal
severity: normal
status: open
title: Setting a exception side_effect on a mock from create_autospec does not work
type: behavior
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23661>
_______________________________________

From report at bugs.python.org  Sat Mar 14 01:48:23 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 14 Mar 2015 00:48:23 +0000
Subject: [issue23187] Segmentation fault, possibly asyncio related
In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za>
Message-ID: <1426294103.47.0.86771388343.issue23187@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Are we all in agreement that it's probably somehow running out of memory?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23187>
_______________________________________

From report at bugs.python.org  Sat Mar 14 02:32:53 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Mar 2015 01:32:53 +0000
Subject: [issue23624] str.center inconsistent with format "^"
In-Reply-To: <1425966835.2.0.36838695627.issue23624@psf.upfronthosting.co.za>
Message-ID: <1426296773.52.0.623321197487.issue23624@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23624>
_______________________________________

From report at bugs.python.org  Sat Mar 14 02:41:39 2015
From: report at bugs.python.org (Michael Goldish)
Date: Sat, 14 Mar 2015 01:41:39 +0000
Subject: [issue23187] Segmentation fault, possibly asyncio related
In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za>
Message-ID: <1426297299.07.0.985559985058.issue23187@psf.upfronthosting.co.za>


Michael Goldish added the comment:

I don't see a reason to assume the machine was running out of memory. After each crash the process was kept alive by one of those Windows crash dialogs - "the process terminated unexpectedly" or similar. I could see exactly how much memory was occupied by the process and it was never a significant percentage of the machine's total memory. It sometimes exceeded 2GB but I'm using a 64 bit build so this shouldn't be a problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23187>
_______________________________________

From report at bugs.python.org  Sat Mar 14 02:46:04 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 14 Mar 2015 01:46:04 +0000
Subject: [issue12641] Remove -mno-cygwin from distutils
In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za>
Message-ID: <1426297564.97.0.801859317325.issue12641@psf.upfronthosting.co.za>


Ned Deily added the comment:

Michael, this issue is closed and the changes have long since been released.  Comments here will likely be ignored.  Please open a new issue describing the problem you are seeing and under what environment, with exact steps to reproduce it.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________

From report at bugs.python.org  Sat Mar 14 02:55:54 2015
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 14 Mar 2015 01:55:54 +0000
Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++
 Compiler for Python
In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za>
Message-ID: <1426298154.24.0.378223054878.issue23246@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

The setuptools code is licensed under the ZPL and PSF licenses. If either of those licenses are insufficient, I'm happy to release my contribution in that file to the public domain.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23246>
_______________________________________

From report at bugs.python.org  Sat Mar 14 03:27:46 2015
From: report at bugs.python.org (Michael Goldish)
Date: Sat, 14 Mar 2015 02:27:46 +0000
Subject: [issue23187] Segmentation fault, possibly asyncio related
In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za>
Message-ID: <1426300066.98.0.817778770992.issue23187@psf.upfronthosting.co.za>


Michael Goldish added the comment:

I caught another crash just now, this time in update_refs(). A stack trace is attached below. I still think this is the same issue.

static void
update_refs(PyGC_Head *containers)
{
    PyGC_Head *gc = containers->gc.gc_next;
0000000067382D60  mov         rdx,qword ptr [rcx]  
    for (; gc != containers; gc = gc->gc.gc_next) {
0000000067382D63  cmp         rdx,rcx  
0000000067382D66  je          update_refs+28h (67382D88h)  
0000000067382D68  nop         dword ptr [rax+rax]  
        assert(_PyGCHead_REFS(gc) == GC_REACHABLE);
        _PyGCHead_SET_REFS(gc, Py_REFCNT(FROM_GC(gc)));
0000000067382D70  and         qword ptr [rdx+10h],1  

Here rdx is 0, which means we're writing to 0x10, probably because the member gc_refs is at offset 0x10 of struct PyGC_Head.gc. So I suppose containers->gc.gc_next was NULL.

(In case this is helpful: somehow, possibly due to compiler optimizations, Visual Studio claims that containers->gc.gc_next is 0x34. I'm not sure what to make of this. It also claims that containers->gc.gc_prev->gc.gc_next is 0x3e, and that containers->gc.gc_prev->gc.gc_prev->gc.gc_next is 0x3e, and so on... gc_prev always seems fine and gc_next is always 0x3e, except for the first one which is 0x34. I'm attaching a screenshot to make this clearer.)

Stack trace (Python 3.4.2, 64 bit, Windows):

python34.dll!update_refs(_gc_head * containers=0x00000000676af8e0)  Line 345
python34.dll!collect(int generation=-290088656, __int64 * n_collected=0x00000000f166e920, __int64 * n_uncollectable=0x0000000000000000, int nofail=0)  Line 969
python34.dll!collect_with_callback(int generation=-290088656)  Line 1141
python34.dll!_PyObject_GC_Malloc(unsigned __int64 basicsize=4046951880)  Line 1739
python34.dll!_PyObject_GC_New(_typeobject * tp=0x0000000001c624f0)  Line 1749
python34.dll!PyList_New(__int64 size=0)  Line 159 + 0xc bytes
python34.dll!PyEval_EvalFrameEx(_frame * f=0x00000000bab65b08, int throwflag=-244913096)  Line 2346
python34.dll!fast_function(_object * func=0x0000000000000003, _object * * * pp_stack=0x00000000f77684e0, int n=102445400, int na=1732453353, int nk=0)  Line 4332
python34.dll!call_function(_object * * * pp_stack=0x00000000f166ec29, int oparg=131)  Line 4260
python34.dll!PyEval_EvalFrameEx(_frame * f=0x00000000601cbd68, int throwflag=-244912600)  Line 2838
python34.dll!fast_function(_object * func=0x0000000000000003, _object * * * pp_stack=0x00000000f7768f28, int n=56017240, int na=1732453353, int nk=0)  Line 4332
python34.dll!call_function(_object * * * pp_stack=0x00000000f166ee19, int oparg=131)  Line 4260
python34.dll!PyEval_EvalFrameEx(_frame * f=0x00000000c65ff8f8, int throwflag=0)  Line 2838
python34.dll!PyEval_EvalCodeEx(_object * _co=0x0000000000000002, _object * globals=0x0000000000000002, _object * locals=0x0000000000000000, _object * * args=0x000000000358d248, int argcount=2, _object * * kws=0x0000000001c50060, int kwcount=0, _object * * defs=0x0000000000000000, int defcount=0, _object * kwdefs=0x0000000000000000, _object * closure=0x0000000000000000)  Line 3585 + 0xa bytes
python34.dll!function_call(_object * func=0x000000000355f048, _object * arg=0x00000000f12f7688, _object * kw=0x0000000000000000)  Line 638 + 0x45 bytes
python34.dll!PyObject_Call(_object * func=0x00000000f12f7688, _object * arg=0x00000000f11c4d08, _object * kw=0x00000000f4e9ba58)  Line 2068
python34.dll!ext_do_call(_object * func=0x000000000355f048, _object * * * pp_stack=0x00000000f166f0d9, int flags=-200649216, int na=1, int nk=0)  Line 4558 + 0xe bytes
python34.dll!PyEval_EvalFrameEx(_frame * f=0x00000000f40a5458, int throwflag=-244911400)  Line 2879
python34.dll!fast_function(_object * func=0x0000000000000001, _object * * * pp_stack=0x00000000f1380f98, int n=45993224, int na=1732453353, int nk=0)  Line 4332
python34.dll!call_function(_object * * * pp_stack=0x00000000f166f2c9, int oparg=131)  Line 4260
python34.dll!PyEval_EvalFrameEx(_frame * f=0x00000000d6922548, int throwflag=0)  Line 2838
python34.dll!PyEval_EvalCodeEx(_object * _co=0x0000000000000002, _object * globals=0x0000000000000002, _object * locals=0x0000000000000000, _object * * args=0x0000000002334200, int argcount=2, _object * * kws=0x0000000001c50060, int kwcount=0, _object * * defs=0x0000000000000000, int defcount=0, _object * kwdefs=0x0000000000000000, _object * closure=0x0000000000000000)  Line 3585 + 0xa bytes
python34.dll!function_call(_object * func=0x0000000002bdcbf8, _object * arg=0x00000000e41ef808, _object * kw=0x0000000000000000)  Line 638 + 0x45 bytes
python34.dll!PyObject_Call(_object * func=0x00000000e41ef808, _object * arg=0x00000000ef4ad308, _object * kw=0x00000000deda7148)  Line 2068
python34.dll!ext_do_call(_object * func=0x0000000002bdcbf8, _object * * * pp_stack=0x00000000f166f589, int flags=-280305184, int na=0, int nk=0)  Line 4558 + 0xe bytes
python34.dll!PyEval_EvalFrameEx(_frame * f=0x00000000ef4ae048, int throwflag=-244910200)  Line 2879
python34.dll!fast_function(_object * func=0x0000000000000001, _object * * * pp_stack=0x00000000ef4a7c50, int n=44825728, int na=1732453353, int nk=0)  Line 4332
python34.dll!call_function(_object * * * pp_stack=0x00000000f166f779, int oparg=131)  Line 4260
python34.dll!PyEval_EvalFrameEx(_frame * f=0x00000000db168948, int throwflag=-244909704)  Line 2838
python34.dll!fast_function(_object * func=0x0000000000000001, _object * * * pp_stack=0x00000000ef4a7c50, int n=44826272, int na=1732453353, int nk=0)  Line 4332
python34.dll!call_function(_object * * * pp_stack=0x00000000f166f969, int oparg=131)  Line 4260
python34.dll!PyEval_EvalFrameEx(_frame * f=0x00000000ef4ab418, int throwflag=0)  Line 2838
python34.dll!PyEval_EvalCodeEx(_object * _co=0x0000000000000001, _object * globals=0x0000000000000001, _object * locals=0x0000000000000000, _object * * args=0x0000000000000000, int argcount=1, _object * * kws=0x0000000000000000, int kwcount=0, _object * * defs=0x0000000000000000, int defcount=0, _object * kwdefs=0x0000000000000000, _object * closure=0x0000000000000000)  Line 3585 + 0xa bytes
python34.dll!function_call(_object * func=0x0000000002abfd08, _object * arg=0x00000000e22ebef0, _object * kw=0x0000000000000000)  Line 638 + 0x45 bytes
python34.dll!PyObject_Call(_object * func=0x00000000e22ebef0, _object * arg=0x0000000000000000, _object * kw=0x0000000001c50048)  Line 2068
python34.dll!method_call(_object * func=0x0000000002d36148, _object * arg=0x0000000001c50048, _object * kw=0x0000000000000000)  Line 348
python34.dll!PyObject_Call(_object * func=0x0000000001c50048, _object * arg=0x0000000000000000, _object * kw=0x0000000002d36148)  Line 2068
python34.dll!PyEval_CallObjectWithKeywords(_object * func=0x00000000c0a69f40, _object * arg=0x00000000673b1100, _object * kw=0x0000000000000000)  Line 4112
python34.dll!t_bootstrap(void * boot_raw=0x00000000dacc7d00)  Line 1000 + 0x17 bytes
python34.dll!bootstrap(void * call=0x00000000dacc7d00)  Line 177
msvcr100.dll!_callthreadstartex()  Line 314 + 0xd bytes
msvcr100.dll!_threadstartex(void * ptd=0x0000000000000000)  Line 292 + 0x5 bytes
kernel32.dll!0000000076eb5a4d() 	
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	
ntdll.dll!00000000775aba01()

----------
Added file: http://bugs.python.org/file38478/gc_next.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23187>
_______________________________________

From report at bugs.python.org  Sat Mar 14 04:41:07 2015
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 14 Mar 2015 03:41:07 +0000
Subject: [issue23529] Limit decompressed data when reading from LZMAFile and
 BZ2File
In-Reply-To: <1425712723.97.0.267984627537.issue23529@psf.upfronthosting.co.za>
 (Martin Panter's message of "Sat, 07 Mar 2015 07:18:45 +0000")
Message-ID: <87k2yk8cvm.fsf@vostro.rath.org>


Nikolaus Rath added the comment:

On Mar 06 2015, Martin Panter <report at bugs.python.org> wrote:
> Still to do: Need to find a better home for the _DecompressReader and
> _BaseStream classes. Currently it lives in ?lzma?, but apparently it
> is possible for any of the gzip, bz2, lzma modules to not be
> importable, so it would have to live elsewhere.

Yes.

> Possible options are
> the io module, or a brand new internal module
> (e.g. Lib/_compression.py). Thoughts?

I think a new internal module would be the right choice, but I don't
know what needs to be done to properly add it to the build system. So
for now I'd just put it in the io module and wait for a core committer
to complain :-).

Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

----------
title: Limit decompressed data when reading from LZMAFile, BZ2File, GzipFile -> Limit decompressed data when reading from LZMAFile and BZ2File

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23529>
_______________________________________

From report at bugs.python.org  Sat Mar 14 05:19:33 2015
From: report at bugs.python.org (Ignacio Rossi)
Date: Sat, 14 Mar 2015 04:19:33 +0000
Subject: [issue23661] Setting a exception side_effect on a mock from
 create_autospec does not work
In-Reply-To: <1426293940.15.0.253058774664.issue23661@psf.upfronthosting.co.za>
Message-ID: <1426306773.6.0.983342092418.issue23661@psf.upfronthosting.co.za>


Ignacio Rossi added the comment:

The problem only affects autospecced functions.

Apparently, the problem lies here (all code excerpts from Lib/unittest/mock.py):

- When autospeccing functions, the Mock._mock_delegate field is populated at the end of _setup_func (and its the only place I found where the delegate is set):

197 def _setup_func(funcopy, mock):
[...]
237     mock._mock_delegate = funcopy

- Mock.side_effect is a property, and proxies the get/set to _mock_delegate when it exists, and on the way out does not detect the exception and tries to make an _IterMock out of it and everything explodes.

 504     def __get_side_effect(self):
 505         delegated = self._mock_delegate
 506         if delegated is None:
 507             return self._mock_side_effect
 508         sf = delegated.side_effect
 509         if sf is not None and not callable(sf) and not isinstance(sf, _MockIter):
 510             sf = _MockIter(sf)

I've attached a patch which adds a test for this use case, and a proposed fix. Hope it helps :)

----------
keywords: +patch
Added file: http://bugs.python.org/file38479/autospec_exception.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23661>
_______________________________________

From report at bugs.python.org  Sat Mar 14 05:42:42 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 14 Mar 2015 04:42:42 +0000
Subject: [issue23187] Segmentation fault, possibly asyncio related
In-Reply-To: <1426300066.98.0.817778770992.issue23187@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKods0vYghY9Xb2Ay7-eVijjnBnLyzM3svd92--OXRHWw@mail.gmail.com>


Guido van Rossum added the comment:

So what do you make of this?

PyObject_GC_Malloc(unsigned __int64 basicsize=4046951880)

That's nearly 4 GB. I somehow doubt your app is actually trying to allocate
that much memory -- maybe the type object a few lines below in the stack is
overwritten, or maybe the compiler is lying about everything. Is there any
chance you can run an unoptimized build?

On Fri, Mar 13, 2015 at 7:27 PM, Michael Goldish <report at bugs.python.org>
wrote:

>
> Michael Goldish added the comment:
>
> I caught another crash just now, this time in update_refs(). A stack trace
> is attached below. I still think this is the same issue.
>
> static void
> update_refs(PyGC_Head *containers)
> {
>     PyGC_Head *gc = containers->gc.gc_next;
> 0000000067382D60  mov         rdx,qword ptr [rcx]
>     for (; gc != containers; gc = gc->gc.gc_next) {
> 0000000067382D63  cmp         rdx,rcx
> 0000000067382D66  je          update_refs+28h (67382D88h)
> 0000000067382D68  nop         dword ptr [rax+rax]
>         assert(_PyGCHead_REFS(gc) == GC_REACHABLE);
>         _PyGCHead_SET_REFS(gc, Py_REFCNT(FROM_GC(gc)));
> 0000000067382D70  and         qword ptr [rdx+10h],1
>
> Here rdx is 0, which means we're writing to 0x10, probably because the
> member gc_refs is at offset 0x10 of struct PyGC_Head.gc. So I suppose
> containers->gc.gc_next was NULL.
>
> (In case this is helpful: somehow, possibly due to compiler optimizations,
> Visual Studio claims that containers->gc.gc_next is 0x34. I'm not sure what
> to make of this. It also claims that containers->gc.gc_prev->gc.gc_next is
> 0x3e, and that containers->gc.gc_prev->gc.gc_prev->gc.gc_next is 0x3e, and
> so on... gc_prev always seems fine and gc_next is always 0x3e, except for
> the first one which is 0x34. I'm attaching a screenshot to make this
> clearer.)
>
> Stack trace (Python 3.4.2, 64 bit, Windows):
>
> python34.dll!update_refs(_gc_head * containers=0x00000000676af8e0)  Line
> 345
> python34.dll!collect(int generation=-290088656, __int64 *
> n_collected=0x00000000f166e920, __int64 *
> n_uncollectable=0x0000000000000000, int nofail=0)  Line 969
> python34.dll!collect_with_callback(int generation=-290088656)  Line 1141
> python34.dll!_PyObject_GC_Malloc(unsigned __int64 basicsize=4046951880)
> Line 1739
> python34.dll!_PyObject_GC_New(_typeobject * tp=0x0000000001c624f0)  Line
> 1749
> python34.dll!PyList_New(__int64 size=0)  Line 159 + 0xc bytes
> python34.dll!PyEval_EvalFrameEx(_frame * f=0x00000000bab65b08, int
> throwflag=-244913096)  Line 2346
> python34.dll!fast_function(_object * func=0x0000000000000003, _object * *
> * pp_stack=0x00000000f77684e0, int n=102445400, int na=1732453353, int
> nk=0)  Line 4332
> python34.dll!call_function(_object * * * pp_stack=0x00000000f166ec29, int
> oparg=131)  Line 4260
> python34.dll!PyEval_EvalFrameEx(_frame * f=0x00000000601cbd68, int
> throwflag=-244912600)  Line 2838
> python34.dll!fast_function(_object * func=0x0000000000000003, _object * *
> * pp_stack=0x00000000f7768f28, int n=56017240, int na=1732453353, int
> nk=0)  Line 4332
> python34.dll!call_function(_object * * * pp_stack=0x00000000f166ee19, int
> oparg=131)  Line 4260
> python34.dll!PyEval_EvalFrameEx(_frame * f=0x00000000c65ff8f8, int
> throwflag=0)  Line 2838
> python34.dll!PyEval_EvalCodeEx(_object * _co=0x0000000000000002, _object *
> globals=0x0000000000000002, _object * locals=0x0000000000000000, _object *
> * args=0x000000000358d248, int argcount=2, _object * *
> kws=0x0000000001c50060, int kwcount=0, _object * * defs=0x0000000000000000,
> int defcount=0, _object * kwdefs=0x0000000000000000, _object *
> closure=0x0000000000000000)  Line 3585 + 0xa bytes
> python34.dll!function_call(_object * func=0x000000000355f048, _object *
> arg=0x00000000f12f7688, _object * kw=0x0000000000000000)  Line 638 + 0x45
> bytes
> python34.dll!PyObject_Call(_object * func=0x00000000f12f7688, _object *
> arg=0x00000000f11c4d08, _object * kw=0x00000000f4e9ba58)  Line 2068
> python34.dll!ext_do_call(_object * func=0x000000000355f048, _object * * *
> pp_stack=0x00000000f166f0d9, int flags=-200649216, int na=1, int nk=0)
> Line 4558 + 0xe bytes
> python34.dll!PyEval_EvalFrameEx(_frame * f=0x00000000f40a5458, int
> throwflag=-244911400)  Line 2879
> python34.dll!fast_function(_object * func=0x0000000000000001, _object * *
> * pp_stack=0x00000000f1380f98, int n=45993224, int na=1732453353, int
> nk=0)  Line 4332
> python34.dll!call_function(_object * * * pp_stack=0x00000000f166f2c9, int
> oparg=131)  Line 4260
> python34.dll!PyEval_EvalFrameEx(_frame * f=0x00000000d6922548, int
> throwflag=0)  Line 2838
> python34.dll!PyEval_EvalCodeEx(_object * _co=0x0000000000000002, _object *
> globals=0x0000000000000002, _object * locals=0x0000000000000000, _object *
> * args=0x0000000002334200, int argcount=2, _object * *
> kws=0x0000000001c50060, int kwcount=0, _object * * defs=0x0000000000000000,
> int defcount=0, _object * kwdefs=0x0000000000000000, _object *
> closure=0x0000000000000000)  Line 3585 + 0xa bytes
> python34.dll!function_call(_object * func=0x0000000002bdcbf8, _object *
> arg=0x00000000e41ef808, _object * kw=0x0000000000000000)  Line 638 + 0x45
> bytes
> python34.dll!PyObject_Call(_object * func=0x00000000e41ef808, _object *
> arg=0x00000000ef4ad308, _object * kw=0x00000000deda7148)  Line 2068
> python34.dll!ext_do_call(_object * func=0x0000000002bdcbf8, _object * * *
> pp_stack=0x00000000f166f589, int flags=-280305184, int na=0, int nk=0)
> Line 4558 + 0xe bytes
> python34.dll!PyEval_EvalFrameEx(_frame * f=0x00000000ef4ae048, int
> throwflag=-244910200)  Line 2879
> python34.dll!fast_function(_object * func=0x0000000000000001, _object * *
> * pp_stack=0x00000000ef4a7c50, int n=44825728, int na=1732453353, int
> nk=0)  Line 4332
> python34.dll!call_function(_object * * * pp_stack=0x00000000f166f779, int
> oparg=131)  Line 4260
> python34.dll!PyEval_EvalFrameEx(_frame * f=0x00000000db168948, int
> throwflag=-244909704)  Line 2838
> python34.dll!fast_function(_object * func=0x0000000000000001, _object * *
> * pp_stack=0x00000000ef4a7c50, int n=44826272, int na=1732453353, int
> nk=0)  Line 4332
> python34.dll!call_function(_object * * * pp_stack=0x00000000f166f969, int
> oparg=131)  Line 4260
> python34.dll!PyEval_EvalFrameEx(_frame * f=0x00000000ef4ab418, int
> throwflag=0)  Line 2838
> python34.dll!PyEval_EvalCodeEx(_object * _co=0x0000000000000001, _object *
> globals=0x0000000000000001, _object * locals=0x0000000000000000, _object *
> * args=0x0000000000000000, int argcount=1, _object * *
> kws=0x0000000000000000, int kwcount=0, _object * * defs=0x0000000000000000,
> int defcount=0, _object * kwdefs=0x0000000000000000, _object *
> closure=0x0000000000000000)  Line 3585 + 0xa bytes
> python34.dll!function_call(_object * func=0x0000000002abfd08, _object *
> arg=0x00000000e22ebef0, _object * kw=0x0000000000000000)  Line 638 + 0x45
> bytes
> python34.dll!PyObject_Call(_object * func=0x00000000e22ebef0, _object *
> arg=0x0000000000000000, _object * kw=0x0000000001c50048)  Line 2068
> python34.dll!method_call(_object * func=0x0000000002d36148, _object *
> arg=0x0000000001c50048, _object * kw=0x0000000000000000)  Line 348
> python34.dll!PyObject_Call(_object * func=0x0000000001c50048, _object *
> arg=0x0000000000000000, _object * kw=0x0000000002d36148)  Line 2068
> python34.dll!PyEval_CallObjectWithKeywords(_object *
> func=0x00000000c0a69f40, _object * arg=0x00000000673b1100, _object *
> kw=0x0000000000000000)  Line 4112
> python34.dll!t_bootstrap(void * boot_raw=0x00000000dacc7d00)  Line 1000 +
> 0x17 bytes
> python34.dll!bootstrap(void * call=0x00000000dacc7d00)  Line 177
> msvcr100.dll!_callthreadstartex()  Line 314 + 0xd bytes
> msvcr100.dll!_threadstartex(void * ptd=0x0000000000000000)  Line 292 + 0x5
> bytes
> kernel32.dll!0000000076eb5a4d()
> [Frames below may be incorrect and/or missing, no symbols loaded for
> kernel32.dll]
> ntdll.dll!00000000775aba01()
>
> ----------
> Added file: http://bugs.python.org/file38478/gc_next.png
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue23187>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23187>
_______________________________________

From report at bugs.python.org  Sat Mar 14 07:40:20 2015
From: report at bugs.python.org (Wei Wu)
Date: Sat, 14 Mar 2015 06:40:20 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>
Message-ID: <1426315220.54.0.395091787504.issue23566@psf.upfronthosting.co.za>


Wei Wu added the comment:

I attached a patch that implements the solution described above.

----------
Added file: http://bugs.python.org/file38480/issue23566_fd_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23566>
_______________________________________

From report at bugs.python.org  Sat Mar 14 09:29:58 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 14 Mar 2015 08:29:58 +0000
Subject: [issue23187] Segmentation fault, possibly asyncio related
In-Reply-To: <CAP7+vJKods0vYghY9Xb2Ay7-eVijjnBnLyzM3svd92--OXRHWw@mail.gmail.com>
Message-ID: <CAMpsgwaayjRPhkYDp6aB3XieF32CiuZKLo1rQ+QzHL62PBC-Wg@mail.gmail.com>


STINNER Victor added the comment:

It looks like you are running your app on Windows. Are you using the
proactor event loop? I guess yes since you have more than 1000 clients and
select() is limited to 500 sockets.

In Python 3.4.3, I fixed a *lot* of crashes and race conditions in the
proactor event loop. There are maybe more race conditions. Are you running
subprocesses with asyncio?

Le 14 mars 2015 05:42, "Guido van Rossum" <report at bugs.python.org> a ?crit :
> PyObject_GC_Malloc(unsigned __int64 basicsize=4046951880)
>
> That's nearly 4 GB. I somehow doubt your app is actually trying to
allocate
> that much memory

The caller is PyList_New(0).

When using a debugger on an optimized build, you should not trust the
debugger. For example, variables can be stored in registers. Displaying
values in the old frames can just display junk. In gdb, you see
<optimized>. The fast call convention uses registers to pass first
parameters to functions. I'm not sure that debuggers handle this case
correctly. Etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23187>
_______________________________________

From report at bugs.python.org  Sat Mar 14 09:54:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Mar 2015 08:54:53 +0000
Subject: [issue23655] Memory corruption using pickle over pipe to subprocess
In-Reply-To: <1426229235.01.0.332656133041.issue23655@psf.upfronthosting.co.za>
Message-ID: <1426323293.53.0.686938660793.issue23655@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

No, there are no subprocess specific tests for pickle. Pickle tests are in Lib/test/pickletester.py  and Lib/test/test_pickle.py.

First try dump pickled data to a file and then load it in other process. Is it still failed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23655>
_______________________________________

From report at bugs.python.org  Sat Mar 14 11:23:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Mar 2015 10:23:28 +0000
Subject: [issue23500] Argument Clinic: multiple macro definition
In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za>
Message-ID: <1426328608.58.0.39977732435.issue23500@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be first commit this non-perfect solution? Generated code is correct, it is just not optimal. This issue is a dependency of issue23501, that is a dependency of issue23492, that is a dependency of my patch for optimizing argument parsing in 1-argument functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23500>
_______________________________________

From report at bugs.python.org  Sat Mar 14 12:09:53 2015
From: report at bugs.python.org (Liam Marsh)
Date: Sat, 14 Mar 2015 11:09:53 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1426331393.8.0.378397877728.issue23546@psf.upfronthosting.co.za>


Liam Marsh added the comment:

in fact, the idlelib.__main__ file exists in the 3.4 version...
the question is: is it possible to make it exist on older versions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sat Mar 14 12:38:11 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Sat, 14 Mar 2015 11:38:11 +0000
Subject: [issue21518] Expose RegUnLoadKey in winreg
In-Reply-To: <1400346760.52.0.0203244636304.issue21518@psf.upfronthosting.co.za>
Message-ID: <1426333091.18.0.198522927975.issue21518@psf.upfronthosting.co.za>


Claudiu Popa added the comment:

Thank you for the review. The new patch uses the name UnLoadKey for the API.

----------
Added file: http://bugs.python.org/file38481/issue21518_6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21518>
_______________________________________

From report at bugs.python.org  Sat Mar 14 12:41:03 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Sat, 14 Mar 2015 11:41:03 +0000
Subject: [issue21574] Port image types detections from PIL to the imghdr module
In-Reply-To: <1401010621.11.0.919611847501.issue21574@psf.upfronthosting.co.za>
Message-ID: <1426333263.65.0.698644515472.issue21574@psf.upfronthosting.co.za>


Claudiu Popa added the comment:

Well, we should have test files for each format imghdr supports. Doesn't PIL have test files for them?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21574>
_______________________________________

From report at bugs.python.org  Sat Mar 14 13:14:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Mar 2015 12:14:55 +0000
Subject: [issue14904] test_unicode_repr_oflw (in test_bigmem) crashes
In-Reply-To: <1337903212.58.0.439916347295.issue14904@psf.upfronthosting.co.za>
Message-ID: <1426335295.7.0.707722815554.issue14904@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Unfortunately original logs are not available.

test_unicode_repr_oflw incorrectly declares required memory usage. It declares only 6.4 GiB, but actually needs 10.4 GiB only on narrow build (and at least 13.4 on wide build).

Proposed patch fixes memuse parameters in test_unicode_repr_oflw and other bigmem tests. It also changes test_unicode_repr_oflw so it no more uses eval(), is much faster, and requires only 5.33 GiB on narrow build (6.67 GiB on wide build) (based on Python 3 tests).

Please test.

----------
keywords: +patch
nosy: +serhiy.storchaka
stage:  -> patch review
Added file: http://bugs.python.org/file38482/issue14904.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14904>
_______________________________________

From report at bugs.python.org  Sat Mar 14 13:17:48 2015
From: report at bugs.python.org (Vladimir Ulupov)
Date: Sat, 14 Mar 2015 12:17:48 +0000
Subject: [issue23659] csv.register_dialect  doc string
In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>
Message-ID: <1426335468.81.0.76307068345.issue23659@psf.upfronthosting.co.za>


Vladimir Ulupov added the comment:

Incorrect docstring(PyDoc_STRVAR) for function csv.register_dialect

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23659>
_______________________________________

From report at bugs.python.org  Sat Mar 14 13:25:36 2015
From: report at bugs.python.org (Michael Goldish)
Date: Sat, 14 Mar 2015 12:25:36 +0000
Subject: [issue23187] Segmentation fault, possibly asyncio related
In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za>
Message-ID: <1426335936.27.0.872959744847.issue23187@psf.upfronthosting.co.za>


Michael Goldish added the comment:

> That's nearly 4 GB. I somehow doubt your app is actually trying to allocate that much memory

There's no reason for the app to allocate that much memory in a single call. It's using almost 4 GB of memory in total today, but that makes sense given its load today.

> Is there any you can run an unoptimized build?

I'll try doing that now. I suppose I should build it myself with Py_DEBUG enabled.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23187>
_______________________________________

From report at bugs.python.org  Sat Mar 14 14:02:51 2015
From: report at bugs.python.org (Michael Goldish)
Date: Sat, 14 Mar 2015 13:02:51 +0000
Subject: [issue23187] Segmentation fault, possibly asyncio related
In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za>
Message-ID: <1426338171.8.0.0361093098894.issue23187@psf.upfronthosting.co.za>


Michael Goldish added the comment:

> It looks like you are running your app on Windows. Are you using the proactor event loop?

Yes.

> In Python 3.4.3, I fixed a *lot* of crashes and race conditions in the proactor event loop. There are maybe more race conditions.

I've already tried Python 3.4.3 and got the same crash. The one described in my long message with the stack trace is from 3.4.2, but I got that same stack trace (or a very similar one) with 3.4.3. I have a core dump from that crash as well so I can provide the exact stack trace if necessary.

> Are you running subprocesses with asyncio?

I can't recall running any subprocesses in the server program. The clients do that very often, but they're not the ones crashing...

> The caller is PyList_New(0).

I suppose this creates an empty list?

I managed to get a stack trace from faulthandler somehow and it points to this line in one of the threads:

d = rg.item_counts_by_params.setdefault(params, {})

This runs in a thread (managed by a ThreadPoolExecutor) that computes stuff and writes it to a file. It's in a loop that runs ~200000 times per job. Several lines above there's a similar line that passes an empty list as the 2nd parameter to setdefault().

The other threads are all in threading.wait(), probably doing nothing interesting. One thread is in _run_once().

Unfortunately I don't have any additional information about this particular crash (no dump or stack trace), but it's not unreasonable to assume other crashes occurred during creation of new lists/dicts in a similar manner.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23187>
_______________________________________

From report at bugs.python.org  Sat Mar 14 14:43:03 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 14 Mar 2015 13:43:03 +0000
Subject: [issue23657] Don't do isinstance checks in zipapp
In-Reply-To: <1426258210.85.0.503105299924.issue23657@psf.upfronthosting.co.za>
Message-ID: <1426340583.25.0.463078718646.issue23657@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Depends on whether you want to support pathlib.Path objects explicitly. =) If so then yes, we should add tests.

Which reminds me, it might be time for you to request commit privileges so you can commit patches like this yourself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23657>
_______________________________________

From report at bugs.python.org  Sat Mar 14 14:47:18 2015
From: report at bugs.python.org (Paul Moore)
Date: Sat, 14 Mar 2015 13:47:18 +0000
Subject: [issue23657] Don't do isinstance checks in zipapp
In-Reply-To: <1426258210.85.0.503105299924.issue23657@psf.upfronthosting.co.za>
Message-ID: <1426340838.18.0.709330447707.issue23657@psf.upfronthosting.co.za>


Paul Moore added the comment:

Cool, I'll look at sorting it out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23657>
_______________________________________

From report at bugs.python.org  Sat Mar 14 15:40:12 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Mar 2015 14:40:12 +0000
Subject: [issue23659] csv.register_dialect  doc string
In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>
Message-ID: <1426344012.11.0.0873342177023.issue23659@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, you are trying to point out that the docstring doesn't mention fmtparams, or that the dialect object is optional. Sure, that should be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23659>
_______________________________________

From report at bugs.python.org  Sat Mar 14 16:01:20 2015
From: report at bugs.python.org (Malcolm Smith)
Date: Sat, 14 Mar 2015 15:01:20 +0000
Subject: [issue23662] Cookie.domain is undocumented
Message-ID: <1426345280.31.0.365548742215.issue23662@psf.upfronthosting.co.za>


New submission from Malcolm Smith:

This is a fundamental attribute of a cookie, which will be set even if the server doesn't specify it, yet it doesn't appear in the documentation either of 2.x cookielib or 3.x http.cookiejar.

----------
assignee: docs at python
components: Documentation
messages: 238087
nosy: Malcolm Smith, docs at python
priority: normal
severity: normal
status: open
title: Cookie.domain is undocumented
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23662>
_______________________________________

From report at bugs.python.org  Sat Mar 14 16:12:56 2015
From: report at bugs.python.org (Vladimir Ulupov)
Date: Sat, 14 Mar 2015 15:12:56 +0000
Subject: [issue23659] csv.register_dialect  doc string
In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>
Message-ID: <1426345976.89.0.524545133327.issue23659@psf.upfronthosting.co.za>


Vladimir Ulupov added the comment:

Yes, sorry for my bad English.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23659>
_______________________________________

From report at bugs.python.org  Sat Mar 14 16:32:44 2015
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Sat, 14 Mar 2015 15:32:44 +0000
Subject: [issue23551] IDLE to provide menu options for using PIP
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1426347164.75.0.130245184374.issue23551@psf.upfronthosting.co.za>


Saimadhav Heblikar added the comment:

The proof of concept is almost ready.
I have a couple of questions to anyone familiar with pip api (and on windows for question 2)

1. Is a restart of the interpreter absolutely required for pip.operations.freeze.freeze() to reflect changes?(install/uninstall)?

2. (Windows particular) Is a permission similar to sudo required to install packages using pip? If not, would it be OK to install only to user home director in *nix? Doing so would be allow code to be same across platforms. It would also prevent asking the end user where they want the package to be installed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23551>
_______________________________________

From report at bugs.python.org  Sat Mar 14 16:59:14 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 14 Mar 2015 15:59:14 +0000
Subject: [issue23551] IDLE to provide menu options for using PIP
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1426348754.35.0.254301462031.issue23551@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I think that on Windows you might have to assume that the user has the rights to install to site-packages, regardless of where the Python version is installed.  Please see https://docs.python.org/dev/using/windows.html for the installation screen for 3.5.  If this is not the case Raymond's final requirement "Change default install directory" would not help as the user still needs to change the environment to get Python working, or have I missed something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23551>
_______________________________________

From report at bugs.python.org  Sat Mar 14 18:08:49 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 14 Mar 2015 17:08:49 +0000
Subject: [issue2052] Allow changing difflib._file_template character encoding.
In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za>
Message-ID: <1426352929.06.0.103232499801.issue2052@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


Added file: http://bugs.python.org/file38483/issue2052_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2052>
_______________________________________

From report at bugs.python.org  Sat Mar 14 18:37:09 2015
From: report at bugs.python.org (William Schwartz)
Date: Sat, 14 Mar 2015 17:37:09 +0000
Subject: [issue21112] 3.4 regression: unittest.expectedFailure no longer works
 on TestCase subclasses
In-Reply-To: <1410162164.03.0.888469660105.issue21112@psf.upfronthosting.co.za>
Message-ID: <CA+46e5zKnkd_izbWtxHvU0upooV0NA4i1PYkZRcj2T5PpKc7pQ@mail.gmail.com>


William Schwartz added the comment:

3.4.3 has been released, it seems, without this getting fixed.

3.4.4 then?

-- 
William Schwartz

On Mon, Sep 8, 2014 at 3:42 AM, Michael Foord <report at bugs.python.org>
wrote:

>
> Michael Foord added the comment:
>
> The patch looks good to me.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue21112>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21112>
_______________________________________

From report at bugs.python.org  Sat Mar 14 18:50:11 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 14 Mar 2015 17:50:11 +0000
Subject: [issue2052] Allow changing difflib._file_template character encoding.
In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za>
Message-ID: <1426355411.22.0.00510756897773.issue2052@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


Added file: http://bugs.python.org/file38484/issue2052_v4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2052>
_______________________________________

From report at bugs.python.org  Sat Mar 14 19:14:32 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Mar 2015 18:14:32 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1426356872.93.0.192920913777.issue23546@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Liam, your question was answered in the technical sense in my two previous messages.  However, being able to type 'python -m idlelib' instead of 'python -m idlelib.idle' is a separate issue from 'Edit with Idle' on the right context menu.

Steve, is it possible to add "Edit with Idle x.y" on the context menu for each x.y" installed?  Or even "Edit with Idle x.y (nn)"? in case both 32 and 64 bit versions are installed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sat Mar 14 19:25:39 2015
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 14 Mar 2015 18:25:39 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <1426357539.67.0.443643453087.issue23632@psf.upfronthosting.co.za>


Stefan Krah added the comment:

It turns out that msg237933 was too simplistic: There are some
intricacies of numpy array indexing that *are* very complex:

  http://docs.scipy.org/doc/numpy/reference/arrays.indexing.html


In particular, x[::2, 1, ::2] is not necessarily equal to
x[::2][1][::2].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Sat Mar 14 19:28:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Mar 2015 18:28:20 +0000
Subject: [issue21818] cookielib documentation references Cookie module,
 not cookielib.Cookie class
In-Reply-To: <1403306887.99.0.626699628104.issue21818@psf.upfronthosting.co.za>
Message-ID: <1426357700.63.0.30839397627.issue21818@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Georg, this looks as a bug in Sphinx configuration. Why module takes priority on class when the role is explicitly specified? I have counted about two hundreds of similar bugs in the documentation.

----------
nosy: +georg.brandl, serhiy.storchaka
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21818>
_______________________________________

From report at bugs.python.org  Sat Mar 14 19:49:22 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Mar 2015 18:49:22 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <20150314184919.28817.14564@psf.io>


Roundup Robot added the comment:

New changeset fabbe6093567 by Steve Dower in branch 'default':
Issue #23606: Temporarily suppress test for CRT name.
https://hg.python.org/cpython/rev/fabbe6093567

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23606>
_______________________________________

From report at bugs.python.org  Sat Mar 14 20:28:05 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 14 Mar 2015 19:28:05 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1426361285.01.0.236002175394.issue23546@psf.upfronthosting.co.za>


Steve Dower added the comment:

It's possible, though personally I wouldn't like it (but I don't use IDLE, so I guess that makes the difference). I'd prefer to be able to list them all under the Open With menu, since that also allows users to easily make any of them the default if that's what they'd like. Unfortunately, to do that we need to start shipping an EXE launcher, probably with a unique name (e.g. idle35-32.exe).

Alternatively, if IDLE provided a selection of installed versions within the program, then it would make sense to always open with the most recent version (or more likely, the most recently installed version, due to how file associations have to be set up when you don't have separate .EXEs).

Currently the 3.5 installer doesn't add any commands for IDLE, so when I fix that I'll include the version information. It may require that the py launcher is also installed, since the launcher owns the file association.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sat Mar 14 20:37:49 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Mar 2015 19:37:49 +0000
Subject: [issue2052] Allow changing difflib._file_template character encoding.
In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za>
Message-ID: <1426361869.89.0.879463833139.issue2052@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM

----------
assignee:  -> berker.peksag
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2052>
_______________________________________

From report at bugs.python.org  Sat Mar 14 20:45:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Mar 2015 19:45:59 +0000
Subject: [issue21818] cookielib documentation references Cookie module,
 not cookielib.Cookie class
In-Reply-To: <1403306887.99.0.626699628104.issue21818@psf.upfronthosting.co.za>
Message-ID: <1426362359.35.0.0890466939408.issue21818@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch for 2.7 that fixes above a hundred of broken class references. But may be even more broken function references. I think it would be better to fix Sphinx rules.

----------
keywords: +patch
priority: normal -> high
Added file: http://bugs.python.org/file38485/docs_class_links-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21818>
_______________________________________

From report at bugs.python.org  Sat Mar 14 20:49:14 2015
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 14 Mar 2015 19:49:14 +0000
Subject: [issue23467] Improve byte formatting compatibility between Py2 and Py3
In-Reply-To: <1424025207.37.0.294145986044.issue23467@psf.upfronthosting.co.za>
Message-ID: <1426362554.21.0.788842272488.issue23467@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Added in
https://hg.python.org/peps/rev/7fe79194a4f2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23467>
_______________________________________

From report at bugs.python.org  Sat Mar 14 21:51:00 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Mar 2015 20:51:00 +0000
Subject: [issue21818] cookielib documentation references Cookie module,
 not cookielib.Cookie class
In-Reply-To: <1403306887.99.0.626699628104.issue21818@psf.upfronthosting.co.za>
Message-ID: <1426366260.79.0.712125143778.issue21818@psf.upfronthosting.co.za>


R. David Murray added the comment:

This happens because the role is pretty much ignored by Sphinx for linking purposes.  I remember Georg talking about the reason for this, but I forget what it was.  Perhaps it would be possible to, as you suggest, have the roll affect the priority...but it may be the case that the references don't currently retain the needed information.  Regardless, that would be an issue for the Sphinx tracker.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21818>
_______________________________________

From report at bugs.python.org  Sat Mar 14 22:59:10 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 Mar 2015 21:59:10 +0000
Subject: [issue23662] Cookie.domain is undocumented
In-Reply-To: <1426345280.31.0.365548742215.issue23662@psf.upfronthosting.co.za>
Message-ID: <1426370350.88.0.098597024741.issue23662@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23662>
_______________________________________

From report at bugs.python.org  Sat Mar 14 23:04:29 2015
From: report at bugs.python.org (David Macek)
Date: Sat, 14 Mar 2015 22:04:29 +0000
Subject: [issue23663] Crash on failure in ctypes on Cygwin
Message-ID: <1426370668.97.0.493459472376.issue23663@psf.upfronthosting.co.za>


New submission from David Macek:

Two Cygwin-specific sections in `Modules/_ctypes/_ctypes.c` cause a crash due to bad call to `PyErr_Format`. I'm not sure if there's one extra format specifier, or one argument is missing. Patches assuming the former case for v2.7 and v3.3:

https://github.com/Alexpux/MSYS2-packages/blob/master/python3/3.3-wrong-parameters.patch

https://github.com/Alexpux/MSYS2-packages/blob/master/python2/0260-wrong-parameters.patch

----------
components: ctypes
files: 3.3-wrong-parameters.patch
keywords: patch
messages: 238101
nosy: elieux
priority: normal
severity: normal
status: open
title: Crash on failure in ctypes on Cygwin
type: crash
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file38486/3.3-wrong-parameters.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23663>
_______________________________________

From report at bugs.python.org  Sat Mar 14 23:32:58 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 14 Mar 2015 22:32:58 +0000
Subject: [issue23661] Setting a exception side_effect on a mock from
 create_autospec does not work
In-Reply-To: <1426293940.15.0.253058774664.issue23661@psf.upfronthosting.co.za>
Message-ID: <1426372378.19.0.808993021643.issue23661@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +berker.peksag, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23661>
_______________________________________

From report at bugs.python.org  Sat Mar 14 23:40:19 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 14 Mar 2015 22:40:19 +0000
Subject: [issue23663] Crash on failure in ctypes on Cygwin
In-Reply-To: <1426370668.97.0.493459472376.issue23663@psf.upfronthosting.co.za>
Message-ID: <1426372819.6.0.976490852131.issue23663@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
stage:  -> patch review
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23663>
_______________________________________

From report at bugs.python.org  Sat Mar 14 23:58:23 2015
From: report at bugs.python.org (Martin Sekera)
Date: Sat, 14 Mar 2015 22:58:23 +0000
Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces
In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za>
Message-ID: <1426373903.03.0.748118842726.issue23441@psf.upfronthosting.co.za>


Martin Sekera added the comment:

Is it necessary to force a predefined tab width (4) onto the user here? I prefer 2-character tabs for example, and have all my terminals set up accordingly (setterm --regtabs 2). I presume many people prefer 8-column tabs, hence the default width in most software.

Additionally, the user shouldn't have to backspace 4 characters to remove one level of indentation. Not only is it annoying, it is also prone to errors if the user miscounts (and ends up with an IndentationError).

I've been using the attached patch (just 5 lines) to emulate the behavior familiar from unix shells: pressing tab activates the completion function, but indents if the line is empty (i.e. '' or all whitespace). It also indents properly if the cursor is moved to whitespace in front of a line, as one would expect.

----------
nosy: +Martin Sekera
Added file: http://bugs.python.org/file38487/rlcompleter-tab.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23441>
_______________________________________

From report at bugs.python.org  Sat Mar 14 23:59:13 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 14 Mar 2015 22:59:13 +0000
Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces
In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za>
Message-ID: <1426373953.28.0.525044311524.issue23441@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

4 spaces is the recommended indent width in PEP 8. That's what most Python users will expect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23441>
_______________________________________

From report at bugs.python.org  Sun Mar 15 00:18:50 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Mar 2015 23:18:50 +0000
Subject: [issue2052] Allow changing difflib._file_template character encoding.
In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za>
Message-ID: <20150314231846.88858.84758@psf.io>


Roundup Robot added the comment:

New changeset e058423d3ca4 by Berker Peksag in branch 'default':
Issue #2052: Add charset parameter to HtmlDiff.make_file().
https://hg.python.org/cpython/rev/e058423d3ca4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2052>
_______________________________________

From report at bugs.python.org  Sun Mar 15 00:19:45 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 14 Mar 2015 23:19:45 +0000
Subject: [issue2052] Allow changing difflib._file_template character encoding.
In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za>
Message-ID: <1426375185.93.0.169954087182.issue2052@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks Serhiy.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2052>
_______________________________________

From report at bugs.python.org  Sun Mar 15 00:22:54 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 14 Mar 2015 23:22:54 +0000
Subject: [issue23664] Modernize HTML output of difflib.HtmlDiff.make_file()
Message-ID: <1426375374.93.0.948523072227.issue23664@psf.upfronthosting.co.za>


New submission from Berker Peksag:

This is a split off from issue 2052. issue2052_html5_v2.diff (from issue 2052) needs to be updated.

----------
assignee: berker.peksag
components: Library (Lib)
messages: 238106
nosy: berker.peksag
priority: normal
severity: normal
stage: needs patch
status: open
title: Modernize HTML output of difflib.HtmlDiff.make_file()
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23664>
_______________________________________

From report at bugs.python.org  Sun Mar 15 00:26:01 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 14 Mar 2015 23:26:01 +0000
Subject: [issue19541] ast.dump(indent=True) prettyprinting
In-Reply-To: <1384060618.33.0.960245227555.issue19541@psf.upfronthosting.co.za>
Message-ID: <1426375561.65.0.182556464156.issue19541@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19541>
_______________________________________

From report at bugs.python.org  Sun Mar 15 00:30:47 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 Mar 2015 23:30:47 +0000
Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces
In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za>
Message-ID: <1426375847.62.0.835592979388.issue23441@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

+1 for 4 spaces.

Smart backspace would be nice too, but I agree it's a separate issue (unless it's trivial to implement).  Deeply-nested code in the interactive interpreter is uncommon, and the lack of smart backspace never bothered me.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23441>
_______________________________________

From report at bugs.python.org  Sun Mar 15 00:33:44 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Mar 2015 23:33:44 +0000
Subject: [issue23665] Provide IDLE menu option to set command-line arguments
Message-ID: <1426376024.32.0.301061562538.issue23665@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

A number of IDEs support menu options to set the execution environment for programs under development and testing.  In particular, it would be nice if IDLE let the user set command line arguments to be passed into sys.argv when running a script by pressing F5.

Here are some existing implementations for reference:
* Wing-IDE: https://wingware.com/doc/intro/tutorial-debugging-launch
* Visual Studio: https://www.youtube.com/watch?v=IgbQCRHKV-Y
* PyCharm: https://www.jetbrains.com/pycharm/help/run-debug-configuration-python.html

This feature will help users interactively develop and test command-line tools while retaining all the nice features of the IDE.   I would personally find it useful when teaching students about how sys.argv works.

I suggest adding an option under the Run menu for Set Command Line arguments.  It would trigger a dialog box that lets a user set a string such as "somefile.txt -r 10".  The user string would be run through shlex to break it into separate fields.  When F5 is pressed, the sys.argv list would be repopulated to include the script name and the lexed arguments.

A little more elaborate option is to add a Run menu entry for Set Execution Enviroment that let's the user 1) set the command-line  2) specify the start-up directory (using os.chdir), 3) and edit the environment variables (from os.environ) or at least be able to set PYTHONPATH.

----------
components: IDLE
messages: 238108
nosy: rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Provide IDLE menu option to set command-line arguments
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23665>
_______________________________________

From report at bugs.python.org  Sun Mar 15 00:38:05 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Mar 2015 23:38:05 +0000
Subject: [issue23666] Add shell session logging option to IDLE
Message-ID: <1426376285.32.0.372835851361.issue23666@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

IDLE's interactive shell supports File / Save to save an interactive session.  However, if a user restarts a session or accidentally exits without saving, all is lost.

In Python courses I've taught, there has been a recurring request for an auto-logging feature (save the session at some regular interval).  This would help user's record everything they type during a Python class.

I suggest an addition to the File menu (for the interactive shell only): Session Logging Enable/Disable.

----------
components: IDLE
messages: 238109
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Add shell session logging option to IDLE
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23666>
_______________________________________

From report at bugs.python.org  Sun Mar 15 00:43:04 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Mar 2015 23:43:04 +0000
Subject: [issue23667] IDLE to provide option for making trailing whitespace
 visible
Message-ID: <1426376584.28.0.267295855034.issue23667@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

We have an option to clear trailing whitespace (Format / Strip trailing whitespace) but it isn't always clear when to use it (because the trailing whitespace is invisible).

One thing the can be done is to colorize trailing white space to make it more visible (this idea is inspired by a similar feature in mercurial's colorized diffs).

Another option is put a hook on File / Save to scan for trailing whitespace and offer to remove it (this idea is inspired by the whitespace commit hook used in Python's own source code management).

----------
components: IDLE
messages: 238110
nosy: rhettinger
priority: normal
severity: normal
status: open
title: IDLE to provide option for making trailing whitespace visible
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23667>
_______________________________________

From report at bugs.python.org  Sun Mar 15 00:57:44 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Mar 2015 23:57:44 +0000
Subject: [issue23568] unittest.mock.MagicMock doesn't support __rdivmod__
In-Reply-To: <1425371785.99.0.969035398065.issue23568@psf.upfronthosting.co.za>
Message-ID: <20150314235741.1837.91438@psf.io>


Roundup Robot added the comment:

New changeset 35a780a9a3b4 by Berker Peksag in branch '3.4':
Issue #23568: Add rdivmod support to MagicMock() objects.
https://hg.python.org/cpython/rev/35a780a9a3b4

New changeset 90f08e7fbdc3 by Berker Peksag in branch 'default':
Issue #23568: Add rdivmod support to MagicMock() objects.
https://hg.python.org/cpython/rev/90f08e7fbdc3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23568>
_______________________________________

From report at bugs.python.org  Sun Mar 15 01:02:16 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 15 Mar 2015 00:02:16 +0000
Subject: [issue23568] unittest.mock.MagicMock doesn't support __rdivmod__
In-Reply-To: <1425371785.99.0.969035398065.issue23568@psf.upfronthosting.co.za>
Message-ID: <1426377736.03.0.99206858392.issue23568@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks to both of you for the report and the patch.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.4, Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23568>
_______________________________________

From report at bugs.python.org  Sun Mar 15 02:41:38 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 15 Mar 2015 01:41:38 +0000
Subject: [issue23668] Support os.[f]truncate on Windows
Message-ID: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za>


New submission from Steve Dower:

With _chsize_s (which supports 64-bit sizes, unlike _chsize), this seems fairly trivial to do, but I'll put a patch up for it in case there's something I've missed.

----------
assignee: steve.dower
components: Windows
messages: 238113
nosy: steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Support os.[f]truncate on Windows
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23668>
_______________________________________

From report at bugs.python.org  Sun Mar 15 02:55:53 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 15 Mar 2015 01:55:53 +0000
Subject: [issue23668] Support os.[f]truncate on Windows
In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za>
Message-ID: <1426384553.2.0.522897439909.issue23668@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at microsoft.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file38488/23668_1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23668>
_______________________________________

From report at bugs.python.org  Sun Mar 15 02:58:45 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 15 Mar 2015 01:58:45 +0000
Subject: [issue22351] NNTP constructor exception leaves socket for garbage
 collector
In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za>
Message-ID: <1426384725.82.0.0809446205226.issue22351@psf.upfronthosting.co.za>


Martin Panter added the comment:

Posting issue22351_nntp_fail_4.patch; changes:

* Merge mixin and main TestCase class; mixins like this are sometimes useful to work around Issue 22351, but not necessary in this case, because there is only one TestCase class involved.
* Turn the local server in the background thread into mock socket object, with makefile() returning a duplex stream object, reusing the existing _NNTPServerIO and NNTPv1Handler classes.
* Test socket closure by checking mock socket and stream objects directly, rather than relying on a lack of ResourceWarning.

----------
Added file: http://bugs.python.org/file38489/issue22351_nntp_fail_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22351>
_______________________________________

From report at bugs.python.org  Sun Mar 15 03:06:57 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 15 Mar 2015 02:06:57 +0000
Subject: [issue22351] NNTP constructor exception leaves socket for garbage
 collector
In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za>
Message-ID: <1426385217.34.0.253266211212.issue22351@psf.upfronthosting.co.za>


Martin Panter added the comment:

Oops, meant to link to Issue 14534 about the test case mixing hack.

BTW this new patch also tests NNTP_SSL, by bypassing the encryption step and repeating the non-SSL tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22351>
_______________________________________

From report at bugs.python.org  Sun Mar 15 03:19:52 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 15 Mar 2015 02:19:52 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1426385992.77.0.49223646769.issue23524@psf.upfronthosting.co.za>


Steve Dower added the comment:

New patch.

* Includes the _Py_fstat fix so that callers can use GetLastError for accurate info or errno for approximate info
* Reverts the _Py_VERIFY_FD proposal and just makes _PyVerify_fd a no-op except on VS 2010, 2012 and 2013. (After VS 2015 RC is released, I'm willing to remove _PyVerify_fd completely.)
* Still uses _Py_BEGIN/END_SUPPRESS_IPH to protect calls into the CRT where we can't ensure valid parameters in advance. (Chances are I haven't got all of these yet, but currently the test suite isn't revealing any others for me.)

----------
Added file: http://bugs.python.org/file38490/23524_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23524>
_______________________________________

From report at bugs.python.org  Sun Mar 15 04:17:21 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Mar 2015 03:17:21 +0000
Subject: [issue23549] heapq docs should be more precise about how to access
 the smallest element
In-Reply-To: <1425141461.42.0.47354110207.issue23549@psf.upfronthosting.co.za>
Message-ID: <20150315031718.88866.83656@psf.io>


Roundup Robot added the comment:

New changeset 8ddda7d1f8e3 by Eli Bendersky in branch '3.4':
Issue #23549: Clarify confusion in heapq doc - accessing the mininmal element
https://hg.python.org/cpython/rev/8ddda7d1f8e3

New changeset 642247a536d5 by Eli Bendersky in branch 'default':
Issue #23549: Clarify confusion in heapq doc - accessing the mininmal element
https://hg.python.org/cpython/rev/642247a536d5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23549>
_______________________________________

From report at bugs.python.org  Sun Mar 15 04:20:17 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Mar 2015 03:20:17 +0000
Subject: [issue23549] heapq docs should be more precise about how to access
 the smallest element
In-Reply-To: <1425141461.42.0.47354110207.issue23549@psf.upfronthosting.co.za>
Message-ID: <20150315032014.86357.40631@psf.io>


Roundup Robot added the comment:

New changeset b61578bb5014 by Eli Bendersky in branch '2.7':
Issue #23549: Clarify confusion in heapq doc - accessing the mininmal element
https://hg.python.org/cpython/rev/b61578bb5014

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23549>
_______________________________________

From report at bugs.python.org  Sun Mar 15 04:20:33 2015
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Mar 2015 03:20:33 +0000
Subject: [issue23549] heapq docs should be more precise about how to access
 the smallest element
In-Reply-To: <1425141461.42.0.47354110207.issue23549@psf.upfronthosting.co.za>
Message-ID: <1426389633.36.0.984885363234.issue23549@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23549>
_______________________________________

From report at bugs.python.org  Sun Mar 15 05:20:56 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 15 Mar 2015 04:20:56 +0000
Subject: [issue23500] Argument Clinic: multiple macro definition
In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za>
Message-ID: <1426393256.6.0.0933201896198.issue23500@psf.upfronthosting.co.za>


Larry Hastings added the comment:

How about this approach?  Only ever emit the #ifndef stanza once per symbol.

----------
Added file: http://bugs.python.org/file38491/larry.ac_multiple_macro_definitions.diff.1.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23500>
_______________________________________

From report at bugs.python.org  Sun Mar 15 05:21:19 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 15 Mar 2015 04:21:19 +0000
Subject: [issue23500] Argument Clinic: multiple macro definition
In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za>
Message-ID: <1426393279.36.0.194597564001.issue23500@psf.upfronthosting.co.za>


Larry Hastings added the comment:

(see larry.ac_multiple_macro_definitions.diff.1.txt posted above)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23500>
_______________________________________

From report at bugs.python.org  Sun Mar 15 05:23:48 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 15 Mar 2015 04:23:48 +0000
Subject: [issue23669] test_socket.NonBlockingTCPTests failing due to race
 condition
Message-ID: <1426393428.29.0.286141594262.issue23669@psf.upfronthosting.co.za>


New submission from Steve Dower:

The test at Lib/test/test_socket.py:3883 is failing intermittently (but more often than not) due to a race condition between the two threads involved in the test.

======================================================================
FAIL: testRecv (test.test_socket.NonBlockingTCPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\build\cpython\lib\test\test_socket.py", line 3883, in testRecv
    self.fail("Error trying to do non-blocking recv.")
AssertionError: Error trying to do non-blocking recv.

----------------------------------------------------------------------

The message in this case means the recv succeeded when it should have failed due to lack of data. But the second thread just delays briefly before sending data, and apparently the main thread can stall long enough for the data to be available in the first part of the test.

A quick check using an Event rather than the sleep shows that the race condition can be fixed, but it seems like this may affect more tests as a lot seem to involve sleep-based timing.

(I've only seen this on Windows, but I see no reason why it shouldn't affect other platforms as well.)

----------
components: Tests
messages: 238121
nosy: pitrou, steve.dower
priority: normal
severity: normal
status: open
title: test_socket.NonBlockingTCPTests failing due to race condition
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23669>
_______________________________________

From report at bugs.python.org  Sun Mar 15 05:25:07 2015
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 15 Mar 2015 04:25:07 +0000
Subject: [issue23500] Argument Clinic: multiple macro definition
In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za>
Message-ID: <1426393507.66.0.373299396816.issue23500@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Oops, I should have run "make clinic", so you could see all the changes that result from this patch.

----------
Added file: http://bugs.python.org/file38492/larry.ac_multiple_macro_definitions.diff.2.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23500>
_______________________________________

From report at bugs.python.org  Sun Mar 15 05:34:43 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 15 Mar 2015 04:34:43 +0000
Subject: [issue23621] Uninstalling Python 3.5 removes a "py.exe" that was
 installed with Python 3.4
In-Reply-To: <1425903612.32.0.843947786812.issue23621@psf.upfronthosting.co.za>
Message-ID: <1426394083.32.0.892909653646.issue23621@psf.upfronthosting.co.za>


Steve Dower added the comment:

This is already fixed for 3.5 and later, since the launcher now has a consistent component ID regardless of which version/architecture of Python is installed.

It's too late to go back and make equivalent changes to the installer for 3.4 - running a Repair on a 3.4 installation is the best way to get it back.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23621>
_______________________________________

From report at bugs.python.org  Sun Mar 15 06:02:26 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 15 Mar 2015 05:02:26 +0000
Subject: [issue23529] Limit decompressed data when reading from LZMAFile and
 BZ2File
In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za>
Message-ID: <1426395746.57.0.624030991708.issue23529@psf.upfronthosting.co.za>


Martin Panter added the comment:

Well my last patch just added the _compression.py file without doing anything special, and it seems to be installed properly with ?make install? so I will assume nothing else needs to be done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23529>
_______________________________________

From report at bugs.python.org  Sun Mar 15 07:25:47 2015
From: report at bugs.python.org (Russell Keith-Magee)
Date: Sun, 15 Mar 2015 06:25:47 +0000
Subject: [issue23670] Modifications to support iOS as a development platform
Message-ID: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za>


New submission from Russell Keith-Magee:

Proposal: iOS should be a supported platform for Python development.

The attached patch is a first pass at a patch to achieve this. It is a single patch against Python 3.4.2 sources, and requires no pre- or post-configure modifications. 

Supporting iOS requires multiple builds - one for each of the hardware platforms that iOS supports (x86_64 simulator, ARMv7 and ARM64). These separate builds must then be merged into a single "fat" framework. The patch contains an iOS directory with a "meta" Makefile that manages this build-and-merge process. See the README in the iOS directory for details on usage.

The patch also introduces a new 'ios' platform type.

A sample XCode project for an iOS app is also provided as part of the patch.

iOS/README contains a couple of other notes about the build and the approach taken.

There are some known problems/limitations with this patch:

 * It's a patch against 3.4.2, not hg trunk

 * The code doesn't currently compile for ARMv7. In order to support ARM64, it has been necessary to use an unreleased trunk version of libffi; however, this version is currently broken for ARMv7. Older versions of libffi (including the formal 3.2.1 release) *do* work.

 * The patch doesn't currently provide any way to run the test suite on the target platform. Testing is currently based on a simple smoke test of some basic features.

So - the patch isn't ready for commit to trunk. I'm presenting it for the purposes of getting feedback on the broad approach while I continue to resolve the known issues.

----------
components: Build, Cross-Build
files: 20150314.diff
keywords: patch
messages: 238125
nosy: freakboy3742
priority: normal
severity: normal
status: open
title: Modifications to support iOS as a development platform
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file38493/20150314.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23670>
_______________________________________

From report at bugs.python.org  Sun Mar 15 07:35:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Mar 2015 06:35:09 +0000
Subject: [issue23500] Argument Clinic: multiple macro definition
In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za>
Message-ID: <1426401309.54.0.634319922085.issue23500@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It doesn't fix the issue, because the #ifndef stanza is emitted before second definition. Try to run clinic.py with your patch on sample.c. But may be this idea can be used with my patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23500>
_______________________________________

From report at bugs.python.org  Sun Mar 15 08:06:13 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Mar 2015 07:06:13 +0000
Subject: [issue23670] Modifications to support iOS as a development platform
In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za>
Message-ID: <1426403173.45.0.853591295731.issue23670@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Russell, just checking before I change the issue title: do you mean supporting iOS as a cross-compilation target? "Development" is ambiguous here, as you could mean development *of* CPython, rather than *in* Python, and I assume development *for* iOS largely takes place on x86_64 Mac OS X, Windows and Linux systems.

Slavek, Robert - assuming my understanding of the change is correct, I think would be a very interesting CPython enhancement from a Fedora Workstation perspective.

----------
nosy: +bkabrda, ncoghlan, rkuska

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23670>
_______________________________________

From report at bugs.python.org  Sun Mar 15 08:22:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Mar 2015 07:22:30 +0000
Subject: [issue23500] Argument Clinic: multiple macro definition
In-Reply-To: <1426401309.54.0.634319922085.issue23500@psf.upfronthosting.co.za>
Message-ID: <109724985.qfhVJrS6SS@raxxla>


Serhiy Storchaka added the comment:

Yes, this works. Here is combined patch and proceeded sample file.

----------
Added file: http://bugs.python.org/file38494/clinic_append_2.patch
Added file: http://bugs.python.org/file38495/sample.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23500>
_______________________________________
-------------- next part --------------
diff -r 642247a536d5 Modules/clinic/spwdmodule.c.h
--- a/Modules/clinic/spwdmodule.c.h	Sat Mar 14 20:17:38 2015 -0700
+++ b/Modules/clinic/spwdmodule.c.h	Sun Mar 15 09:18:13 2015 +0200
@@ -36,10 +36,6 @@ exit:
 
 #endif /* defined(HAVE_GETSPNAM) */
 
-#ifndef SPWD_GETSPNAM_METHODDEF
-    #define SPWD_GETSPNAM_METHODDEF
-#endif /* !defined(SPWD_GETSPNAM_METHODDEF) */
-
 #if defined(HAVE_GETSPENT)
 
 PyDoc_STRVAR(spwd_getspall__doc__,
@@ -64,7 +60,11 @@ spwd_getspall(PyModuleDef *module, PyObj
 
 #endif /* defined(HAVE_GETSPENT) */
 
+#ifndef SPWD_GETSPNAM_METHODDEF
+    #define SPWD_GETSPNAM_METHODDEF
+#endif /* !defined(SPWD_GETSPNAM_METHODDEF) */
+
 #ifndef SPWD_GETSPALL_METHODDEF
     #define SPWD_GETSPALL_METHODDEF
 #endif /* !defined(SPWD_GETSPALL_METHODDEF) */
-/*[clinic end generated code: output=41fec4a15b0cd2a0 input=a9049054013a1b77]*/
+/*[clinic end generated code: output=ab16125c5e5f2b1b input=a9049054013a1b77]*/
diff -r 642247a536d5 Modules/clinic/zlibmodule.c.h
--- a/Modules/clinic/zlibmodule.c.h	Sat Mar 14 20:17:38 2015 -0700
+++ b/Modules/clinic/zlibmodule.c.h	Sun Mar 15 09:18:13 2015 +0200
@@ -314,10 +314,6 @@ zlib_Compress_copy(compobject *self, PyO
 
 #endif /* defined(HAVE_ZLIB_COPY) */
 
-#ifndef ZLIB_COMPRESS_COPY_METHODDEF
-    #define ZLIB_COMPRESS_COPY_METHODDEF
-#endif /* !defined(ZLIB_COMPRESS_COPY_METHODDEF) */
-
 #if defined(HAVE_ZLIB_COPY)
 
 PyDoc_STRVAR(zlib_Decompress_copy__doc__,
@@ -340,10 +336,6 @@ zlib_Decompress_copy(compobject *self, P
 
 #endif /* defined(HAVE_ZLIB_COPY) */
 
-#ifndef ZLIB_DECOMPRESS_COPY_METHODDEF
-    #define ZLIB_DECOMPRESS_COPY_METHODDEF
-#endif /* !defined(ZLIB_DECOMPRESS_COPY_METHODDEF) */
-
 PyDoc_STRVAR(zlib_Decompress_flush__doc__,
 "flush($self, length=zlib.DEF_BUF_SIZE, /)\n"
 "--\n"
@@ -450,4 +442,8 @@ exit:
 
     return return_value;
 }
-/*[clinic end generated code: output=bc9473721ca7c962 input=a9049054013a1b77]*/
+
+#ifndef ZLIB_COMPRESS_COPY_METHODDEF
+    #define ZLIB_COMPRESS_COPY_METHODDEF
+#endif /* !defined(ZLIB_COMPRESS_COPY_METHODDEF) */
+/*[clinic end generated code: output=901c18189767dc08 input=a9049054013a1b77]*/
diff -r 642247a536d5 Modules/posixmodule.c
--- a/Modules/posixmodule.c	Sat Mar 14 20:17:38 2015 -0700
+++ b/Modules/posixmodule.c	Sun Mar 15 09:18:13 2015 +0200
@@ -17212,10 +17212,6 @@ dump buffer
     #define OS_SYSTEM_METHODDEF
 #endif /* !defined(OS_SYSTEM_METHODDEF) */
 
-#ifndef OS_SYSTEM_METHODDEF
-    #define OS_SYSTEM_METHODDEF
-#endif /* !defined(OS_SYSTEM_METHODDEF) */
-
 #ifndef OS_UNAME_METHODDEF
     #define OS_UNAME_METHODDEF
 #endif /* !defined(OS_UNAME_METHODDEF) */
@@ -17388,10 +17384,6 @@ dump buffer
     #define OS_WAITPID_METHODDEF
 #endif /* !defined(OS_WAITPID_METHODDEF) */
 
-#ifndef OS_WAITPID_METHODDEF
-    #define OS_WAITPID_METHODDEF
-#endif /* !defined(OS_WAITPID_METHODDEF) */
-
 #ifndef OS_WAIT_METHODDEF
     #define OS_WAIT_METHODDEF
 #endif /* !defined(OS_WAIT_METHODDEF) */
@@ -17492,10 +17484,6 @@ dump buffer
     #define OS_PUTENV_METHODDEF
 #endif /* !defined(OS_PUTENV_METHODDEF) */
 
-#ifndef OS_PUTENV_METHODDEF
-    #define OS_PUTENV_METHODDEF
-#endif /* !defined(OS_PUTENV_METHODDEF) */
-
 #ifndef OS_UNSETENV_METHODDEF
     #define OS_UNSETENV_METHODDEF
 #endif /* !defined(OS_UNSETENV_METHODDEF) */
@@ -17603,7 +17591,7 @@ dump buffer
 #ifndef OS_SET_HANDLE_INHERITABLE_METHODDEF
     #define OS_SET_HANDLE_INHERITABLE_METHODDEF
 #endif /* !defined(OS_SET_HANDLE_INHERITABLE_METHODDEF) */
-/*[clinic end generated code: output=52a6140b0b052ce6 input=524ce2e021e4eba6]*/
+/*[clinic end generated code: output=b788c2d6010113e8 input=524ce2e021e4eba6]*/
 
 
 static PyMethodDef posix_methods[] = {
diff -r 642247a536d5 Tools/clinic/clinic.py
--- a/Tools/clinic/clinic.py	Sat Mar 14 20:17:38 2015 -0700
+++ b/Tools/clinic/clinic.py	Sun Mar 15 09:18:13 2015 +0200
@@ -820,7 +820,8 @@ class CLanguage(Language):
             cpp_if = "#if " + conditional
             cpp_endif = "#endif /* " + conditional + " */"
 
-            if methoddef_define:
+            if methoddef_define and f.name not in clinic.ifndef_symbols:
+                clinic.ifndef_symbols.add(f.name)
                 methoddef_ifndef = normalize_snippet("""
                     #ifndef {methoddef_name}
                         #define {methoddef_name}
@@ -1408,10 +1409,10 @@ class Destination:
         self.name = name
         self.type = type
         self.clinic = clinic
-        valid_types = ('buffer', 'file', 'suppress', 'two-pass')
+        valid_types = ('buffer', 'file', 'suppress', 'two-pass', 'append')
         if type not in valid_types:
             fail("Invalid destination type " + repr(type) + " for " + name + " , must be " + ', '.join(valid_types))
-        extra_arguments = 1 if type == "file" else 0
+        extra_arguments = 1 if type in ('file', 'append') else 0
         if len(args) < extra_arguments:
             fail("Not enough arguments for destination " + name + " new " + type)
         if len(args) > extra_arguments:
@@ -1427,8 +1428,10 @@ class Destination:
             d['basename'] = basename
             d['basename_root'], d['basename_extension'] = os.path.splitext(filename)
             self.filename = args[0].format_map(d)
-        if type == 'two-pass':
+        elif type == 'two-pass':
             self.id = None
+        elif type == 'append':
+            self.target, = args
 
         self.text, self.append, self._dump = _text_accumulator()
 
@@ -1508,6 +1511,7 @@ everything file
 docstring_prototype suppress
 parser_prototype suppress
 impl_definition block
+methoddef_ifndef append-file
 
 preset buffer
 everything buffer
@@ -1515,6 +1519,7 @@ docstring_prototype suppress
 impl_prototype suppress
 parser_prototype suppress
 impl_definition block
+methoddef_ifndef append-buffer
 
 preset partial-buffer
 everything buffer
@@ -1523,6 +1528,7 @@ impl_prototype suppress
 methoddef_define block
 parser_prototype block
 impl_definition block
+methoddef_ifndef append-buffer
 
 preset two-pass
 everything buffer
@@ -1531,6 +1537,7 @@ impl_prototype suppress
 methoddef_define two-pass
 parser_prototype two-pass
 impl_definition block
+methoddef_ifndef append-buffer
 
 """
 
@@ -1555,9 +1562,11 @@ impl_definition block
         self.add_destination("block", "buffer")
         self.add_destination("suppress", "suppress")
         self.add_destination("buffer", "buffer")
+        self.add_destination('append-buffer', 'append', 'buffer')
         self.add_destination("two-pass", "two-pass")
         if filename:
             self.add_destination("file", "file", "{dirname}/clinic/{basename}.h")
+            self.add_destination('append-file', 'append', 'file')
 
         d = self.destinations.get
         self.field_destinations = collections.OrderedDict((
@@ -1569,11 +1578,12 @@ impl_definition block
             ('parser_prototype', d('suppress')),
             ('parser_definition', d('block')),
             ('cpp_endif', d('suppress')),
-            ('methoddef_ifndef', d('buffer')),
+            ('methoddef_ifndef', d('append-buffer')),
             ('impl_definition', d('block')),
         ))
 
         self.field_destinations_stack = []
+        self.ifndef_symbols = set()
 
         self.presets = {}
         preset = None
@@ -1632,6 +1642,11 @@ impl_definition block
         second_pass_replacements = {}
 
         for name, destination in self.destinations.items():
+            if destination.type == 'append':
+                target = self.destinations[destination.target]
+                target.append(destination._dump())
+
+        for name, destination in self.destinations.items():
             if destination.type == 'suppress':
                 continue
             output = destination._dump()
@@ -3144,6 +3159,9 @@ class DSLParser:
 
     def directive_dump(self, name):
         self.block.output.append(self.clinic.get_destination(name).dump())
+        for destination in self.clinic.destinations.values():
+            if destination.type == 'append' and destination.target == name:
+                self.block.output.append(destination._dump())
 
     def directive_print(self, *args):
         self.block.output.append(' '.join(args))
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sample.c
Type: text/x-csrc
Size: 1835 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20150315/8cacd6f1/attachment-0001.c>

From report at bugs.python.org  Sun Mar 15 08:43:43 2015
From: report at bugs.python.org (Ned Deily)
Date: Sun, 15 Mar 2015 07:43:43 +0000
Subject: [issue23670] Modifications to support iOS as a cross-compilation
 target
In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za>
Message-ID: <1426405423.79.0.614557695709.issue23670@psf.upfronthosting.co.za>


Ned Deily added the comment:

As a cross-compilation target.  From a first quick look at it, it appears the patch requires a current Mac OS X system to build for iOS; the necessary standard build tools and SDKs for iOS are only available on OS X. These are the same build tools used for OS X builds.  We already support universal builds for multiple architectures on OS X directly in one pass; unfortunately, the iOS builds require two different SDKs, one for running on the OS X-based simulator and one for the native platform archs which, I assume, is why Russell has gone for the separate builds for each arch and lipo-ed them together.  I don't have an opinion yet about the use of the Setup.local configurations rather than modifying setup.py.  I appreciate trying to keep the changes for a patch like this as isolated as possible.  But, long term, that might not be the best approach assuming there is eventually agreement to fully support iOS as a standard platform (via cross-compilation).  The bulk of the patch is the new version of libffi; presumably that will eventually be released upstream in the standard version of libffi so that having a separate copy wouldn't be required?  In any case, as a work-in-progress, the patch is certainly nicely done.

----------
nosy: +ned.deily, ronaldoussoren
title: Modifications to support iOS as a development platform -> Modifications to support iOS as a cross-compilation target

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23670>
_______________________________________

From report at bugs.python.org  Sun Mar 15 09:06:33 2015
From: report at bugs.python.org (Liam Marsh)
Date: Sun, 15 Mar 2015 08:06:33 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1426406793.27.0.383080520912.issue23546@psf.upfronthosting.co.za>


Liam Marsh added the comment:

"""to do that we need to start shipping an EXE launcher, probably with a unique name (e.g. idle35-32.exe)."""
nope, the windows packages already include an "idle.bat" launcher next to the "idle.py" and "idle.pyw" files. However, this launcher is (strangely enough) not used in the "edit with idle" command.
Is it, by the way, possible to have that, instead? (you can click on the menu button, OR select an idle)

----------
Added file: http://bugs.python.org/file38496/dd.bmp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sun Mar 15 09:07:18 2015
From: report at bugs.python.org (Liam Marsh)
Date: Sun, 15 Mar 2015 08:07:18 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1426406838.5.0.332606073611.issue23546@psf.upfronthosting.co.za>


Liam Marsh added the comment:

(uploaded file: dd.bmp)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sun Mar 15 09:21:34 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Mar 2015 08:21:34 +0000
Subject: [issue23671] string.Template doesn't work with the self keyword
 argument
Message-ID: <1426407694.34.0.298286807857.issue23671@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

string.Template doesn't allow to specify the self substitute parameter as keyword argument.

>>> import string
>>> string.Template('the self is $self').substitute(self='bozo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: substitute() got multiple values for argument 'self'
>>> string.Template('the self is $self').safe_substitute(self='bozo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: safe_substitute() got multiple values for argument 'self'

The same issue is with string.Formatter.format:

>>> string.Formatter().format('the self is {self}', self='bozo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: format() got multiple values for argument 'self'

Proposed patch fixes these issues.

----------
components: Library (Lib)
files: string_formatting_self.patch
keywords: patch
messages: 238132
nosy: georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: string.Template doesn't work with the self keyword argument
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38497/string_formatting_self.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23671>
_______________________________________

From report at bugs.python.org  Sun Mar 15 09:26:25 2015
From: report at bugs.python.org (Russell Keith-Magee)
Date: Sun, 15 Mar 2015 08:26:25 +0000
Subject: [issue23670] Modifications to support iOS as a cross-compilation
 target
In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za>
Message-ID: <1426407985.98.0.268041589046.issue23670@psf.upfronthosting.co.za>


Russell Keith-Magee added the comment:

Nick: you are correct - these are changes to support iOS as a cross-compilation target, so you can run your Python code on an iOS device. Apologies for the confusion in nomenclature.

Ned: You're correct that the build needs to be run on an OS/X machine, and needs to be done in multiple passes because of the need for multiple SDKs.

I've taken the approach of using Setup.local for two reasons. 

Firstly, iOS requires a "fully embedded" Python, because Apple doesn't approve of the use of dynamic loading in apps. Setup.local was the best way I found to force modules to be statically linked into the main library.

Secondly, because of the nature of the end-deployment, I imagine it's inevitable that serious end-users will want to customise their Python build for specific applications. AppStore submission rules prohibit running code that wasn't shipped with the app (i.e., Apple won't let you do an end-run around their app approval processes), so the set of modules you're actually using will be a known quantity. Since a "full" iOS Python build is 34MB or so, much of that bulk will be for binary support of modules that you aren't using, providing an easily configurable way to prune out unused modules from the built product seemed like a useful facility. There's also the issue of providing support for the standard library modules (like SSL) that have dependencies that can't be easily provided or specified out-of-the-box. 

If there's a better/more palatable approach than using Setup.local, I'm happy to look into it.

The libffi code is a direct copy from the current (as of a week or so ago) libffi trunk. There have been some bug fixes applied since 3.2.1 was released in november that are necessary to support ctypes on ARM64 (but, as I flagged in my original comment, introduces bugs for ARMv7). The libffi repo suggests the next version will be 4.0, but I have no idea when that will be finalised. I'm currently trying to get their release plans confirmed. 

As with OS/X libffi support, the source code needs to be generated, rather than just "./configure && make"'d. That said, the libffi_darwin code could be re-used, as the x86_64 components are the same for Darwin as the iOS simulator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23670>
_______________________________________

From report at bugs.python.org  Sun Mar 15 09:33:48 2015
From: report at bugs.python.org (Ned Deily)
Date: Sun, 15 Mar 2015 08:33:48 +0000
Subject: [issue23670] Modifications to support iOS as a cross-compilation
 target
In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za>
Message-ID: <1426408428.64.0.396740240864.issue23670@psf.upfronthosting.co.za>


Ned Deily added the comment:

Ack, much to consider.  Adding doko as I believe he has been most closely following developments with libffi releases.

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23670>
_______________________________________

From report at bugs.python.org  Sun Mar 15 09:40:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Mar 2015 08:40:36 +0000
Subject: [issue23668] Support os.[f]truncate on Windows
In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za>
Message-ID: <1426408836.34.0.797915977174.issue23668@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Rietveld doesn't accept patches in git format.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23668>
_______________________________________

From report at bugs.python.org  Sun Mar 15 09:51:42 2015
From: report at bugs.python.org (Kamisky)
Date: Sun, 15 Mar 2015 08:51:42 +0000
Subject: [issue23672] IDLE for osx 10.8.5 won't run
Message-ID: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>


New submission from Kamisky:

I could run the IDLE in the past time.But today,when I try and launch IDLE, the icon appears on the dock for a second and then disappears and the application doesn't run.Moreover,When I run IDLE3 in Terminal,it says:
bogon:~ Kamisky$ idle3
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/bin/idle3", line 5, in <module>
    main()
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/PyShell.py", line 1560, in main
    shell = flist.open_shell()
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/PyShell.py", line 315, in open_shell
    self.pyshell = PyShell(self)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/PyShell.py", line 866, in __init__
    OutputWindow.__init__(self, flist, None, None)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/OutputWindow.py", line 16, in __init__
    EditorWindow.__init__(self, *args)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/EditorWindow.py", line 301, in __init__
    self.update_recent_files_list()
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/idlelib/EditorWindow.py", line 927, in update_recent_files_list
    underline=0)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/__init__.py", line 2719, in add_command
    self.add('command', cnf or kw)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/tkinter/__init__.py", line 2710, in add
    self._options(cnf, kw))
_tkinter.TclError: character U+1f393 is above the range (U+0000-U+FFFF) allowed by Tcl

Thanks.

----------
components: IDLE
messages: 238136
nosy: kamisky
priority: normal
severity: normal
status: open
title: IDLE for osx 10.8.5 won't run
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23672>
_______________________________________

From report at bugs.python.org  Sun Mar 15 09:54:20 2015
From: report at bugs.python.org (Ned Deily)
Date: Sun, 15 Mar 2015 08:54:20 +0000
Subject: [issue23672] IDLE for osx 10.8.5 won't run
In-Reply-To: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>
Message-ID: <1426409660.92.0.126899840477.issue23672@psf.upfronthosting.co.za>


Ned Deily added the comment:

Try removing IDLE's recently-used file list:

rm ~/.idlerc/recent-files.lst

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23672>
_______________________________________

From report at bugs.python.org  Sun Mar 15 10:35:37 2015
From: report at bugs.python.org (Ned Deily)
Date: Sun, 15 Mar 2015 09:35:37 +0000
Subject: [issue23670] Modifications to support iOS as a cross-compilation
 target
In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za>
Message-ID: <1426412137.87.0.774213644674.issue23670@psf.upfronthosting.co.za>


Ned Deily added the comment:

A thought, primarily as a note to myself for further investigation: the current OS X framework build support and, to a lesser extent, universal build support have added a fair amount of special-case cruft to the build process, primarily in configure.ac and the main Makefile.  Over the years, the build tools have evolved and gotten smarter (and more general) about SDK support and arch support using xcrun, as they were generalized to support iOS vs OS X builds.  But, if it is necessary to do separate compile/link steps to support iOS framework builds because of the multiple SDKs, it *might* make sense to integrate those into the main Makefile and to isolate the framework build steps (for both OS X and iOS) to be more of an add-on step.  The potential positive impact might be to simplify the current main Makefile and configure.ac by centralizing much of the framework build specific steps scattered throughout the Makefile *and* it could also simplify and speed up the iOS builds by not duplicating the platform-independent build steps.  It might even be a useful abstraction for other non-Apple multiple-arch or cross-compilation builds.

Another factor to consider is support for building third-party extension modules standalone as opposed to building as part of the interpreter itself.  It would be nice to be able to just use the traditional Distutils-based process for third-party extension modules.  For OS X universal builds, we get that essentially for free because of the tool chain support for multiple archs.  To do it automatically across multiple SDKs would require adding smarts to Distutils to do multiple compile/links and lipo merges.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23670>
_______________________________________

From report at bugs.python.org  Sun Mar 15 11:13:29 2015
From: report at bugs.python.org (Michael Goldish)
Date: Sun, 15 Mar 2015 10:13:29 +0000
Subject: [issue23187] Segmentation fault, possibly asyncio related
In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za>
Message-ID: <1426414409.96.0.919433317858.issue23187@psf.upfronthosting.co.za>


Michael Goldish added the comment:

OK, I caught the crash with a debug build of Python 3.4.3.

I have a core dump and even the process itself still alive in memory. I can provide any information you need. I can also explain how to debug a core dump with Visual Studio, if necessary.

This time the crash was here:

static void
update_refs(PyGC_Head *containers)
{
    PyGC_Head *gc = containers->gc.gc_next;
    for (; gc != containers; gc = gc->gc.gc_next) {
        assert(_PyGCHead_REFS(gc) == GC_REACHABLE);
        _PyGCHead_SET_REFS(gc, Py_REFCNT(FROM_GC(gc)));
        /* Python's cyclic gc should never see an incoming refcount
         * of 0:  if something decref'ed to 0, it should have been
         * deallocated immediately at that time.
         * Possible cause (if the assert triggers):  a tp_dealloc
         * routine left a gc-aware object tracked during its teardown
         * phase, and did something-- or allowed something to happen --
         * that called back into Python.  gc can trigger then, and may
         * see the still-tracked dying object.  Before this assert
         * was added, such mistakes went on to allow gc to try to
         * delete the object again.  In a debug build, that caused
         * a mysterious segfault, when _Py_ForgetReference tried
         * to remove the object from the doubly-linked list of all
         * objects a second time.  In a release build, an actual
         * double deallocation occurred, which leads to corruption
         * of the allocator's internal bookkeeping pointers.  That's
         * so serious that maybe this should be a release-build
         * check instead of an assert?
         */
------> assert(_PyGCHead_REFS(gc) != 0); <------- crash
    }
}

In the calling frame I can see that update_refs() is called with a PyGC_Head object whose gc_refs is 0, and according to the paragraph above that shouldn't happen. A screenshot is attached.

Stack trace:

msvcr100d.dll!_NMSG_WRITE(int rterrnum=10)  Line 217
msvcr100d.dll!abort()  Line 71
msvcr100d.dll!_wassert(const wchar_t * expr=0x0000000063220618, const wchar_t * filename=0x00000000632205e0, unsigned int lineno=364)  Line 153
python34_d.dll!update_refs(_gc_head * containers=0x000000006338cfc0)  Line 364 + 0x2b bytes
python34_d.dll!collect(int generation=0, __int64 * n_collected=0x000000012beee530, __int64 * n_uncollectable=0x000000012beee520, int nofail=0)  Line 969
python34_d.dll!collect_with_callback(int generation=0)  Line 1140 + 0x16 bytes
python34_d.dll!collect_generations()  Line 1163 + 0x9 bytes
python34_d.dll!_PyObject_GC_Malloc(unsigned __int64 basicsize=56)  Line 1739
python34_d.dll!_PyObject_GC_New(_typeobject * tp=0x00000000633ce280)  Line 1748 + 0xe bytes
python34_d.dll!PyList_New(__int64 size=0)  Line 159 + 0xc bytes
python34_d.dll!PyEval_EvalFrameEx(_frame * f=0x000000010f387658, int throwflag=3)  Line 2347 + 0x8 bytes
python34_d.dll!fast_function(_object * func=0x0000000000000003, _object * * * pp_stack=0x0000000129e69948, int n=737077536, int na=1661137695, int nk=0)  Line 4335
python34_d.dll!call_function(_object * * * pp_stack=0x000000012beee919, int oparg=131)  Line 4263
python34_d.dll!PyEval_EvalFrameEx(_frame * f=0x000000011c077528, int throwflag=3)  Line 2840
python34_d.dll!fast_function(_object * func=0x0000000000000003, _object * * * pp_stack=0x0000000089a53190, int n=737078048, int na=1661137695, int nk=0)  Line 4335
python34_d.dll!call_function(_object * * * pp_stack=0x000000012beeeb19, int oparg=131)  Line 4263
python34_d.dll!PyEval_EvalFrameEx(_frame * f=0x000000010369f2a8, int throwflag=0)  Line 2840
python34_d.dll!PyEval_EvalCodeEx(_object * _co=0x0000000100000002, _object * globals=0x0000000100000002, _object * locals=0x000000001fa5e218, _object * * args=0x0000000000730088, int argcount=2, _object * * kws=0x0000000000730080, int kwcount=0, _object * * defs=0x0000000000000000, int defcount=0, _object * kwdefs=0x0000000000000000, _object * closure=0x0000000000000000)  Line 3588 + 0xf bytes
python34_d.dll!function_call(_object * func=0x0000000003c10058, _object * arg=0x000000001fa5e218, _object * kw=0x00000001296360c8)  Line 638 + 0x8a bytes
python34_d.dll!PyObject_Call(_object * func=0x0000000003c10058, _object * arg=0x000000001fa5e218, _object * kw=0x00000001296360c8)  Line 2040 + 0x13 bytes
python34_d.dll!ext_do_call(_object * func=0x00000000c42c25a0, _object * * * pp_stack=0x000000012beeee49, int flags=62980184, int na=1, int nk=0)  Line 4561 + 0xe bytes
python34_d.dll!PyEval_EvalFrameEx(_frame * f=0x00000000fa4eab18, int throwflag=1)  Line 2880
python34_d.dll!fast_function(_object * func=0x0000000000000001, _object * * * pp_stack=0x000000003b42f398, int n=737079376, int na=1661137695, int nk=0)  Line 4335
python34_d.dll!call_function(_object * * * pp_stack=0x000000012beef049, int oparg=131)  Line 4263
python34_d.dll!PyEval_EvalFrameEx(_frame * f=0x000000010f38ec28, int throwflag=0)  Line 2840
python34_d.dll!PyEval_EvalCodeEx(_object * _co=0x0000000100000002, _object * globals=0x0000000100000002, _object * locals=0x000000012a1e5d78, _object * * args=0x0000000000730088, int argcount=2, _object * * kws=0x0000000000730080, int kwcount=0, _object * * defs=0x0000000000000000, int defcount=0, _object * kwdefs=0x0000000000000000, _object * closure=0x0000000000000000)  Line 3588 + 0xf bytes
python34_d.dll!function_call(_object * func=0x00000000036d2d48, _object * arg=0x000000012a1e5d78, _object * kw=0x000000012a1f1918)  Line 638 + 0x8a bytes
python34_d.dll!PyObject_Call(_object * func=0x00000000036d2d48, _object * arg=0x000000012a1e5d78, _object * kw=0x000000012a1f1918)  Line 2040 + 0x13 bytes
python34_d.dll!ext_do_call(_object * func=0x00000000033f6040, _object * * * pp_stack=0x000000012beef379, int flags=57486664, int na=0, int nk=0)  Line 4561 + 0xe bytes
python34_d.dll!PyEval_EvalFrameEx(_frame * f=0x000000010f80f118, int throwflag=1)  Line 2880
python34_d.dll!fast_function(_object * func=0x0000000000000001, _object * * * pp_stack=0x000000012a1ee878, int n=737080704, int na=1661137695, int nk=0)  Line 4335
python34_d.dll!call_function(_object * * * pp_stack=0x000000012beef579, int oparg=131)  Line 4263
python34_d.dll!PyEval_EvalFrameEx(_frame * f=0x000000010f1c8b98, int throwflag=1)  Line 2840
python34_d.dll!fast_function(_object * func=0x0000000000000001, _object * * * pp_stack=0x000000012a1ee878, int n=737081216, int na=1661137695, int nk=0)  Line 4335
python34_d.dll!call_function(_object * * * pp_stack=0x000000012beef779, int oparg=131)  Line 4263
python34_d.dll!PyEval_EvalFrameEx(_frame * f=0x000000010f80ee88, int throwflag=0)  Line 2840
python34_d.dll!PyEval_EvalCodeEx(_object * _co=0x0000000000000001, _object * globals=0x0000000100000001, _object * locals=0x0000000000730058, _object * * args=0x0000000000000000, int argcount=1, _object * * kws=0x0000000000000000, int kwcount=0, _object * * defs=0x0000000000000000, int defcount=0, _object * kwdefs=0x0000000000000000, _object * closure=0x0000000000000000)  Line 3588 + 0xf bytes
python34_d.dll!function_call(_object * func=0x0000000003404058, _object * arg=0x000000012a1ee058, _object * kw=0x0000000000000000)  Line 638 + 0x8a bytes
python34_d.dll!PyObject_Call(_object * func=0x0000000003404058, _object * arg=0x000000012a1ee058, _object * kw=0x0000000000000000)  Line 2040 + 0x13 bytes
python34_d.dll!method_call(_object * func=0x0000000003404058, _object * arg=0x000000012a1ee058, _object * kw=0x0000000000000000)  Line 347 + 0x1d bytes
python34_d.dll!PyObject_Call(_object * func=0x0000000003826fa8, _object * arg=0x0000000000730058, _object * kw=0x0000000000000000)  Line 2040 + 0x13 bytes
python34_d.dll!PyEval_CallObjectWithKeywords(_object * func=0x0000000000000000, _object * arg=0x0000000000000000, _object * kw=0x0000000000000000)  Line 4115
python34_d.dll!t_bootstrap(void * boot_raw=0x00000000e2e0df70)  Line 1000 + 0x20 bytes
python34_d.dll!bootstrap(void * call=0x000000000070ef20)  Line 176
msvcr100d.dll!_callthreadstartex()  Line 314 + 0x17 bytes
msvcr100d.dll!_threadstartex(void * ptd=0x000000007be2d110)  Line 297
kernel32.dll!0000000076eb5a4d()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
ntdll.dll!00000000775aba01()

----------
Added file: http://bugs.python.org/file38498/gc_refs.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23187>
_______________________________________

From report at bugs.python.org  Sun Mar 15 11:27:22 2015
From: report at bugs.python.org (Ned Deily)
Date: Sun, 15 Mar 2015 10:27:22 +0000
Subject: [issue23672] IDLE can crash if file name contains non-BMP Unicode
 characters
In-Reply-To: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>
Message-ID: <1426415242.79.0.124129393568.issue23672@psf.upfronthosting.co.za>


Ned Deily added the comment:

At least on some platforms (e.g. OS X), it is easy to create files with legitimate names containing code points above the BMP limit (<= U+FFFF) currently imposed by Tcl/Tk.  For IDLE 3, I suspect _filename_to_unicode() in EditorWindow could be modified to check for such cases to prevent problems if such file names end up in recent-files.lst.  That might not be sufficient: there may be other problematic places.  I also was able to crash a current IDLE 2.7 just opening a file with such a name.

----------
stage:  -> needs patch
title: IDLE for osx 10.8.5 won't run -> IDLE can crash if file name contains non-BMP Unicode characters
versions: +Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23672>
_______________________________________

From report at bugs.python.org  Sun Mar 15 11:27:51 2015
From: report at bugs.python.org (Ned Deily)
Date: Sun, 15 Mar 2015 10:27:51 +0000
Subject: [issue23672] IDLE can crash if file name contains non-BMP Unicode
 characters
In-Reply-To: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>
Message-ID: <1426415271.65.0.354933148868.issue23672@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +roger.serwy, terry.reedy -ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23672>
_______________________________________

From report at bugs.python.org  Sun Mar 15 13:24:29 2015
From: report at bugs.python.org (eryksun)
Date: Sun, 15 Mar 2015 12:24:29 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1426422269.69.0.921761485776.issue23546@psf.upfronthosting.co.za>


eryksun added the comment:

> I'd prefer to be able to list them all under the Open With menu, 
> since that also allows users to easily make any of them the 
> default if that's what they'd like. Unfortunately, to do that 
> we need to start shipping an EXE launcher, probably with a 
> unique name (e.g. idle35-32.exe).

Can't you just create a ProgID, e.g. IDLE_3.5, that defines the "open" verb, and add this to the OpenWithProgIds subkey for .py and .pyw?

https://msdn.microsoft.com/en-us/library/windows/desktop/hh127445%28v=vs.85%29.aspx

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sun Mar 15 14:18:33 2015
From: report at bugs.python.org (eryksun)
Date: Sun, 15 Mar 2015 13:18:33 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1426425513.46.0.308278807257.issue23546@psf.upfronthosting.co.za>


eryksun added the comment:

> the windows packages already include an "idle.bat" launcher next 
> to the "idle.py" and "idle.pyw" files. However, this launcher 
> is (strangely enough) not used in the "edit with idle" command.

Why run a batch file instead of directly running the .pyw script via pythonw.exe? A batch file is executed by cmd.exe, which is a console application. 

I believe the batch was included as a convenient way to start IDLE from the command line with the correct version instead of the default system Python. Nowadays idle.pyw should have an explicit shebang and be installed into Scripts, including a Windows .exe wrapper to make it runnable via CreateProcess. This would already be the case if IDLE were bundled in the same way as setuptools and pip, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sun Mar 15 14:38:01 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 15 Mar 2015 13:38:01 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1426426681.67.0.266661204599.issue23546@psf.upfronthosting.co.za>


Steve Dower added the comment:

Setting up a progid is my intent, but it will be linked very closely to the executable. Currently it will show up as "pythonw.exe" and not idle.

I didn't try with the batch file, but I'm fairly sure that's failed in the past too. I like the idea of (approximately) using pip to install it though. The generated idle3.5.exe in that case is only going to conflict between the 32/64-bit versions at least.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sun Mar 15 14:40:12 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 15 Mar 2015 13:40:12 +0000
Subject: [issue23668] Support os.[f]truncate on Windows
In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za>
Message-ID: <1426426812.64.0.505006747403.issue23668@psf.upfronthosting.co.za>


Steve Dower added the comment:

It normally does... I'll regenerate the patch when I get a chance later today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23668>
_______________________________________

From report at bugs.python.org  Sun Mar 15 14:54:14 2015
From: report at bugs.python.org (Liam Marsh)
Date: Sun, 15 Mar 2015 13:54:14 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1426427654.38.0.264093603546.issue23546@psf.upfronthosting.co.za>


Liam Marsh added the comment:

>Why run a batch file instead of directly running the .pyw script via >pythonw.exe? A batch file is executed by cmd.exe, which is a console >application.
the strange thing is that it exists

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sun Mar 15 15:23:00 2015
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 15 Mar 2015 14:23:00 +0000
Subject: [issue20680] Pickle socket enums by names
In-Reply-To: <1392758039.35.0.851373733794.issue20680@psf.upfronthosting.co.za>
Message-ID: <1426429379.99.0.49394233277.issue20680@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Serhiy, sorry for taking so long to get back to this -- we spent so much time making sure pickling worked I had no idea that unpickling didn't work in prior versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20680>
_______________________________________

From report at bugs.python.org  Sun Mar 15 16:02:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 Mar 2015 15:02:51 +0000
Subject: [issue23187] Segmentation fault, possibly asyncio related
In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za>
Message-ID: <1426431771.14.0.16566788648.issue23187@psf.upfronthosting.co.za>


STINNER Victor added the comment:

(Since you chose to comment this closed issue instead of opening a new one, I reopen this issue.)

----------
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23187>
_______________________________________

From report at bugs.python.org  Sun Mar 15 16:10:45 2015
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 15 Mar 2015 15:10:45 +0000
Subject: [issue23673] IntEnum is unpicklable by previous Python versions
Message-ID: <1426432245.83.0.265780672947.issue23673@psf.upfronthosting.co.za>


New submission from Ethan Furman:

IntEnum is advertised as being a drop-in replacement for integer contants; however this fails in the case of unpickling on previous Python versions.

This occurs because when a pickle is created the module, class, and value are stored -- but those don't exist prior to Python 3.4.

One solution is to modify IntEnum to pickle just like a plain int would, but this has the serious disadvantage of losing the benefits of IntEnum on Python versions that support it.

Another solution is to use Serhiy's idea of pickling by name; this would store the module and name to look up in that madule, and this works on all Python versions that have that constant: on Python 3.3 socket.AF_INET returns an integerer (2, I think), and on Python 3.4+ it returns the AF_INET AddressFamily member.

----------
assignee: ethan.furman
keywords: 3.4regression
messages: 238148
nosy: barry, eli.bendersky, ethan.furman, serhiy.storchaka
priority: normal
severity: normal
stage: test needed
status: open
title: IntEnum is unpicklable by previous Python versions
type: behavior
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23673>
_______________________________________

From report at bugs.python.org  Sun Mar 15 16:18:16 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 15 Mar 2015 15:18:16 +0000
Subject: [issue23668] Support os.[f]truncate on Windows
In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za>
Message-ID: <1426432696.89.0.474664054899.issue23668@psf.upfronthosting.co.za>


Steve Dower added the comment:

Regenerated the patch file. Rietveld may not have liked that the parent changeset in the previous patch doesn't exist (I pulled this out of my patch queue).

----------
Added file: http://bugs.python.org/file38499/23668_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23668>
_______________________________________

From report at bugs.python.org  Sun Mar 15 16:25:52 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 Mar 2015 15:25:52 +0000
Subject: [issue23187] Segmentation fault, possibly asyncio related
In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za>
Message-ID: <1426433152.45.0.35270259155.issue23187@psf.upfronthosting.co.za>


STINNER Victor added the comment:

>> Did you see some errors or warnings when running your application with asyncio in debug mode?

> No, but I'll try. I doubt the problem is in asyncio itself because it's mostly written in Python. This looks like a garbage collection issue.

Sorry, you're wrong: the proactor event loop heavily uses the _overlapped module which is implemented in C. A crash in the garbage collector is more likely a bug in asyncio/your application, than a bug in Python itself.

Please enable asyncio debug mode, ResourceWarning, enable DEBUG log level, and check if you get some errors. For example, "GetQueuedCompletionStatus() returned an unexpected event" usually means that you will quickly get a memory corruption...

If possible, write all asyncio logs at DEBUG log level and attach them to the issue. Using the logging module, it's possible to add a custom handler for "asyncio". Example:
---
import asyncio
import logging

logging.basicConfig()

logger = asyncio.log.logger
output = open("asyncio.log", "a")
handler = logging.StreamHandler(output)
handler.setLevel(logging.DEBUG)
logger.setLevel(logging.DEBUG)
logger.addHandler(handler)

asyncio.log.logger.debug("plop")
output.close()
---

> python34_d.dll!PyList_New(__int64 size=0)  Line 159 + 0xc bytes

So the crash occurred again during a call to PyList_New(0) which triggerred a garbage collection. The backtrace looks more reliable: _PyObject_GC_Malloc(56).

> msvcr100d.dll!_wassert(const wchar_t * expr=0x0000000063220618, const wchar_t * filename=0x00000000632205e0, unsigned int lineno=364)  Line 153
> python34_d.dll!update_refs(_gc_head * containers=0x000000006338cfc0)  Line 364 + 0x2b bytes

This assertion contains a long comment which explains when the assertion can fail.

        /* Python's cyclic gc should never see an incoming refcount
         * of 0:  if something decref'ed to 0, it should have been
         * deallocated immediately at that time.
         * Possible cause (if the assert triggers):  a tp_dealloc
         * routine left a gc-aware object tracked during its teardown
         * phase, and did something-- or allowed something to happen --
         * that called back into Python.  gc can trigger then, and may
         * see the still-tracked dying object.  Before this assert
         * was added, such mistakes went on to allow gc to try to
         * delete the object again.  In a debug build, that caused
         * a mysterious segfault, when _Py_ForgetReference tried
         * to remove the object from the doubly-linked list of all
         * objects a second time.  In a release build, an actual
         * double deallocation occurred, which leads to corruption
         * of the allocator's internal bookkeeping pointers.  That's
         * so serious that maybe this should be a release-build
         * check instead of an assert?
         */
        assert(_PyGCHead_REFS(gc) != 0);

To come back to asyncio and the proactor event loop: the implementations of the proactor event loop is still young and probably unstable. Would it be possible to test again with fewer clients (500 clients or less to not hit the select() limit on Windows) with selector event loop?

A crash in the garbage collector can be caused by a memory corruption. I fixed a lot of memory corruption caused by internal objects uesd in the proactor event loop.

Can you check if asyncio.windows_events._BaseWaitHandleFuture is used? This class is used by IocpProactor.wait_for_handle() which is called by _WindowsSubprocessTransport. But you wrote you the server (where the crash occurs) doesn't run subprocesses.

I never tried the proactor event loop with threads. Are you using asyncio code outside the main thread? asyncio is not thread-safe at all :-p Are you using a single event loop or one event loop per thread?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23187>
_______________________________________

From report at bugs.python.org  Sun Mar 15 16:26:31 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 Mar 2015 15:26:31 +0000
Subject: [issue23187] Segmentation fault, possibly asyncio related
In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za>
Message-ID: <1426433191.76.0.120436053465.issue23187@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Bugfixes of asyncio 3.4.3, a lot of them are related to the proactor event loop (and most of them leaded to crashes):
https://code.google.com/p/tulip/source/browse/ChangeLog#66

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23187>
_______________________________________

From report at bugs.python.org  Sun Mar 15 16:35:28 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 15 Mar 2015 15:35:28 +0000
Subject: [issue22928] HTTP header injection in
 urrlib2/urllib/httplib/http.client
In-Reply-To: <1416797425.29.0.948172439575.issue22928@psf.upfronthosting.co.za>
Message-ID: <1426433728.09.0.568393887854.issue22928@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22928>
_______________________________________

From report at bugs.python.org  Sun Mar 15 16:51:59 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 15 Mar 2015 15:51:59 +0000
Subject: [issue23668] Support os.[f]truncate on Windows
In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za>
Message-ID: <1426434719.82.0.330207632899.issue23668@psf.upfronthosting.co.za>


Steve Dower added the comment:

Hmm... doesn't even know that the issue has been changed. Reuploading with a different extension.

----------
Added file: http://bugs.python.org/file38500/23668_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23668>
_______________________________________

From report at bugs.python.org  Sun Mar 15 17:02:32 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 15 Mar 2015 16:02:32 +0000
Subject: [issue23668] Support os.[f]truncate on Windows
In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za>
Message-ID: <1426435352.93.0.166837347218.issue23668@psf.upfronthosting.co.za>


Steve Dower added the comment:

I get a 405 error if I try and upload the patch on http://bugs.python.org/review/23668/

My other patches from last night worked fine, so maybe Rietveld doesn't like this issue for some reason?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23668>
_______________________________________

From report at bugs.python.org  Sun Mar 15 17:02:56 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 Mar 2015 16:02:56 +0000
Subject: [issue23668] Support os.[f]truncate on Windows
In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za>
Message-ID: <1426435376.71.0.967630098047.issue23668@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23668>
_______________________________________

From report at bugs.python.org  Sun Mar 15 18:09:45 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 15 Mar 2015 17:09:45 +0000
Subject: [issue4896] Faster why variable manipulation in ceval.c
In-Reply-To: <18791.24525.745699.580609@montanaro.dyndns.org>
Message-ID: <1426439385.18.0.495899045897.issue4896@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I've finally remembered to attach the test output I got a week ago.  If you want me to run Antoine's test suite with any specific parameters please feel free to ask.

----------
Added file: http://bugs.python.org/file38501/unpatched.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4896>
_______________________________________

From report at bugs.python.org  Sun Mar 15 18:11:49 2015
From: report at bugs.python.org (Michael Goldish)
Date: Sun, 15 Mar 2015 17:11:49 +0000
Subject: [issue23187] Segmentation fault, possibly asyncio related
In-Reply-To: <1420674095.59.0.174426734655.issue23187@psf.upfronthosting.co.za>
Message-ID: <1426439509.15.0.0569868439265.issue23187@psf.upfronthosting.co.za>


Michael Goldish added the comment:

> Sorry, you're wrong: the proactor event loop heavily uses the _overlapped module which is implemented in C. A crash in the garbage collector is more likely a bug in asyncio/your application, than a bug in Python itself.

I'm aware of that. I assumed the original crash reported in this thread was the same as mine but I can't be sure of that. And that crash was on Linux, where asyncio is pure Python AFAIK.

> Please enable asyncio debug mode, ResourceWarning, enable DEBUG log level, and check if you get some errors. For example, "GetQueuedCompletionStatus() returned an unexpected event" usually means that you will quickly get a memory corruption...

I've already done that but admittedly not for very long because the server ran so slowly that it was unresponsive. I didn't see any error or warning messages, but I did see numerous "Executing <Handle _ProactorReadPipeTransport._loop_reading(<_OverlappedF...events.py:451>)" messages.

> Would it be possible to test again with fewer clients (500 clients or less to not hit the select() limit on Windows) with selector event loop?

I'll see if I can try that, but I guess reproducing the crash can take much longer with 500 clients.

> Can you check if asyncio.windows_events._BaseWaitHandleFuture is used? This class is used by IocpProactor.wait_for_handle() which is called by _WindowsSubprocessTransport. But you wrote you the server (where the crash occurs) doesn't run subprocesses.

It's not used. I put print statements and an exit() in the constructor of _BaseWaitHandleFuture and it wasn't triggered.

> Are you using asyncio code outside the main thread?

No.

> asyncio is not thread-safe at all :-p Are you using a single event loop or one event loop per thread?

A single event loop, and I've made sure that all code running outside the main thread doesn't call any asyncio functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23187>
_______________________________________

From report at bugs.python.org  Sun Mar 15 18:13:08 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Mar 2015 17:13:08 +0000
Subject: [issue23670] Modifications to support iOS as a cross-compilation
 target
In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za>
Message-ID: <1426439588.74.0.165880626209.issue23670@psf.upfronthosting.co.za>


R. David Murray added the comment:

Also remember that being a supported platform requires buildbots.  If I'm reading this right that means two: one for the simulator build, and one that actually runs on the device (once the run-the-test issues is solved).  I'm not sure what would need to be done to buildbot to support the scenario of building on one platform and running the tests on another after copying the binary, but I'm sure there must be some way to do it...buildbot is written in Python after all :)  And I'm sure that capability will be useful for more than just iOS...with Android we can probably run buildbot on the device eventually, but being able to test a cross compile build there as well will be helpful (once there is one).

----------
hgrepos: +300
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23670>
_______________________________________

From report at bugs.python.org  Sun Mar 15 20:40:51 2015
From: report at bugs.python.org (Tapani Kiiskinen)
Date: Sun, 15 Mar 2015 19:40:51 +0000
Subject: [issue23674] super() documentation isn't very clear
Message-ID: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za>


New submission from Tapani Kiiskinen:

https://docs.python.org/3/library/functions.html#super

There's no mention in the document which __mro__ is used in the case of a super(Type, obj) call. There's this mention 'The __mro__ attribute of the *type* lists the method resolution search order used by both getattr() and super().' but my understanding is that this only applies in the case of a super(type) call plus it doesn't state that it only applies in that case. (I'm fairly certain I'm not wrong; if only the __mro__ of the type was used then cooperative multiple inheritance (which is referenced three paragraphs down) could not work because the __mro__ of the type never has sibling types.)

Isn't this misleading due to a super(Type, obj) call (or just super() inside a class in 3k) being the more normal way to use the function? Even now I can't find a single resource to confirm which exact mro is used in the case of a super(Type, obj) call, I've only been able to deduce that it probably uses the type(obj).__mro__ then finds the Type and then tries the entries after Type.

Finally 'If the second argument is omitted, the super object returned is unbound. If the second argument is an object, isinstance(obj, type) must be true. If the second argument is a type, issubclass(type2, type) must be true (this is useful for classmethods).'

I'm interpreting this is essentially saying that if the second argument is given that the returned object will be bound, given an object the super call would return a bound instance method and given a type a bound class method? I feel like stating this explicitly would be more clear than implicitly.

----------
assignee: docs at python
components: Documentation
messages: 238157
nosy: Tapani Kiiskinen, docs at python
priority: normal
severity: normal
status: open
title: super() documentation isn't very clear
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23674>
_______________________________________

From report at bugs.python.org  Sun Mar 15 21:17:37 2015
From: report at bugs.python.org (John Nagle)
Date: Sun, 15 Mar 2015 20:17:37 +0000
Subject: [issue23655] Memory corruption using pickle over pipe to subprocess
In-Reply-To: <1426229235.01.0.332656133041.issue23655@psf.upfronthosting.co.za>
Message-ID: <1426450657.5.0.682659718042.issue23655@psf.upfronthosting.co.za>


John Nagle added the comment:

More info: the problem is on the "unpickle" side.  If I use _Unpickle and Pickle, so the unpickle side is in Python, but the pickle side is in C, no problem. If I use Unpickle and _Pickle, so the unpickle side is C, crashes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23655>
_______________________________________

From report at bugs.python.org  Sun Mar 15 22:06:39 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Mar 2015 21:06:39 +0000
Subject: [issue23674] super() documentation isn't very clear
In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za>
Message-ID: <1426453599.17.0.433297899381.issue23674@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23674>
_______________________________________

From report at bugs.python.org  Sun Mar 15 22:34:03 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Mar 2015 21:34:03 +0000
Subject: [issue23674] super() documentation isn't very clear
In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za>
Message-ID: <1426455243.73.0.214295024333.issue23674@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> There's this mention 'The __mro__ attribute of the *type* lists
> the method resolution search order used by both getattr() and super().

I think instead of *type* it should say *object-or-type*.  It is the "second argument" that supplied the MRO.  The "first arguments" determines where we are currently in that MRO so that the search can begin upstream from the current class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23674>
_______________________________________

From report at bugs.python.org  Sun Mar 15 22:50:26 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Mar 2015 21:50:26 +0000
Subject: [issue23624] str.center inconsistent with format "^"
In-Reply-To: <1425966835.2.0.36838695627.issue23624@psf.upfronthosting.co.za>
Message-ID: <1426456226.32.0.332221897272.issue23624@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

[Serhiy]
> The behavior of Python 2.7 is the same as Python 3.x.
>
> str.center() is very old method and changing it will change 
> formatted reports generated by third-party software in all world. 
> At least this will break many tests. And this will add yet one
> incompatibility between Python 2 and Python 3.

I concur with Serhiy.  Fixing this nuisance inconsistency would likely cause greater harm than it would relieve.  This ship has sailed.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23624>
_______________________________________

From report at bugs.python.org  Sun Mar 15 22:50:34 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Mar 2015 21:50:34 +0000
Subject: [issue23675] glossary entry for 'method resolution order' links to
 something with python 2.3 in the title
Message-ID: <1426456234.82.0.0903487839974.issue23675@psf.upfronthosting.co.za>


New submission from R. David Murray:

The link is correct; that document describes the new-style class method resolution order, which is what Python3 uses.  However, the title is a bit problematic, and either the title should be changed or the link from the Python3 docs should have a gloss explaining why the document is in fact the correct link.

----------
messages: 238161
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: glossary entry for 'method resolution order' links to something with python 2.3 in the title

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23675>
_______________________________________

From report at bugs.python.org  Sun Mar 15 22:51:28 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Mar 2015 21:51:28 +0000
Subject: [issue23672] IDLE can crash if file name contains non-BMP Unicode
 characters
In-Reply-To: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>
Message-ID: <1426456288.56.0.50031251863.issue23672@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23672>
_______________________________________

From report at bugs.python.org  Sun Mar 15 22:55:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Mar 2015 21:55:48 +0000
Subject: [issue23674] super() documentation isn't very clear
In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za>
Message-ID: <1426456548.08.0.430142046428.issue23674@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree with Tapani; what you just explained should be made explicit ("the type is skipped" isn't the same as "searching starts from the item after the type in the object's MRO").  Also, the docs imply by the phrasing that the getattr docs will explain the method resolution order, but those docs do not in fact address the topic.  Perhaps there should be a link to 'method resolution order' in the glossary?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23674>
_______________________________________

From report at bugs.python.org  Sun Mar 15 22:59:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Mar 2015 21:59:08 +0000
Subject: [issue23676] Add support of UnicodeTranslateError in standard error
 handlers
Message-ID: <1426456748.16.0.28109004659.issue23676@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds support of UnicodeTranslateError in standard error handlers "xmlcharrefreplace", "namereplace" and "surrogatepass". Support in "backslashreplace" was added in issue22286, support in "strict", "ignore" and "replace" was always, support in "surrogateescape" is unlikely possible.

This can be used with issue18814.

----------
components: Interpreter Core
files: translate_error_handlers.patch
keywords: patch
messages: 238163
nosy: doerwalter, lemburg, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add support of UnicodeTranslateError in standard error handlers
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38502/translate_error_handlers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23676>
_______________________________________

From report at bugs.python.org  Sun Mar 15 23:09:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 Mar 2015 22:09:04 +0000
Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate
 escaped strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1426457344.68.0.194111461542.issue18814@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +Add support of UnicodeTranslateError in standard error handlers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Mon Mar 16 00:12:10 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Mar 2015 23:12:10 +0000
Subject: [issue23672] IDLE can crash if file name contains non-BMP Unicode
 characters
In-Reply-To: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>
Message-ID: <1426461130.05.0.0519857952873.issue23672@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The full path of a file being edited also ends up in the title bar and the Window menu.  I do not know whether the title bar is displayed by tk or the OS (Windows obviously displays the title of taskbar icons) but the Window list is definitely by tk.  It seems to me that files need two names: the system name used to open (and re-open) a file (utf-8 bytes on *nix?) and a tk name (BMD unicode) for display in the various places.

The current limitation to BMP names is a limitation of the tcl/tk gui framework.  I would like to add a workaround but do not consider its absence a bug.  I am proposing on python-list the addition of some builtin means to replace non-BMP chars with \U000xxxxx escapes for display purposes.  This would be generally useful for tkinter programming.  The thread is "Add str.bmp() to only expand non-BMP chars, for tkinter use".

If this does not happen in 3.5, I would consider a patch to add a private function to EditorWindow.py to do the same.  It would be far less efficient, but fast enough for short path names.

The EditorWindow.py line numbers are slight different from those in 3.4.3 (and 3.4.2, I believe), so I presume this is with 3.4.0 or 3.4.1.  The result with 3.4.3 should be unchanged.

----------
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23672>
_______________________________________

From report at bugs.python.org  Mon Mar 16 00:22:52 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Mar 2015 23:22:52 +0000
Subject: [issue23672] IDLE can crash if file name contains non-BMP Unicode
 characters
In-Reply-To: <1426409502.49.0.177433961931.issue23672@psf.upfronthosting.co.za>
Message-ID: <1426461772.34.0.406552045262.issue23672@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thinking more, there are two issue here.  One is the fact that Idle stops when fed a filename with astral chars.  This *is* a bug and should be fixed in all versions, even if that fix is to display a message box saying that Idle cannot work properly with such files.

The second is the one I addressed in the first message, the inability to work properly with files.  Fixing that would obviate the need to display a message, but might be more work, especially on 2.7.

Kamisky, if you launch Idle and then try to open the file, do you see the name in the Open dialog?  I presume that if you do, and select it, Idle would stop just as it did in your report.

----------
type: enhancement -> behavior
versions: +Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23672>
_______________________________________

From report at bugs.python.org  Mon Mar 16 01:03:23 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 16 Mar 2015 00:03:23 +0000
Subject: [issue20962] Rather modest chunk size in gzip.GzipFile
In-Reply-To: <1395082726.87.0.730756156096.issue20962@psf.upfronthosting.co.za>
Message-ID: <1426464203.75.0.342347253283.issue20962@psf.upfronthosting.co.za>


Martin Panter added the comment:

See also the patch for Issue 23529, which changes over to using BufferedReader for GzipFile, BZ2File and LZMAFile. The current patch there also passes a buffer_size parameter through to BufferedReader, although it currently defaults to io.DEFAULT_BUFFER_SIZE.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20962>
_______________________________________

From report at bugs.python.org  Mon Mar 16 01:14:42 2015
From: report at bugs.python.org (Russell Keith-Magee)
Date: Mon, 16 Mar 2015 00:14:42 +0000
Subject: [issue23670] Modifications to support iOS as a cross-compilation
 target
In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za>
Message-ID: <1426464882.33.0.172218196459.issue23670@psf.upfronthosting.co.za>


Russell Keith-Magee added the comment:

Understood that buildbots are required. The subject has come up a couple of times on mobile-sig - however, I haven't got a good answer for exactly what this means in practice. Does build hardware need to be delivered to a specific build farm location, or can it just run in my home office? Does it need to be running 24/7, or just guarantee that at least X builds per week, or Y% of all builds are tested?

In terms of physical specifications - at a minimum, at least two iDevices will be required (an ARMv7 device, like a 5th Gen iPod, and an ARM64 device, like an iPhone 5S), tethered to a Mac that runs the simulator.

In terms of execution - there's definitely ways to remote-control the deployment and execution of apps, so I imagine buildbot integration is in the realm of the possible.

Android will have similar requirements, but Android also has an emulator which would allow testing without the existence of a physical device, which would provide an alternative approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23670>
_______________________________________

From report at bugs.python.org  Mon Mar 16 02:28:07 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 16 Mar 2015 01:28:07 +0000
Subject: [issue21112] 3.4 regression: unittest.expectedFailure no longer works
 on TestCase subclasses
In-Reply-To: <1396275626.74.0.920741880392.issue21112@psf.upfronthosting.co.za>
Message-ID: <1426469287.75.0.617402056905.issue21112@psf.upfronthosting.co.za>


Robert Collins added the comment:

Test looks good to me. Do you want to apply it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21112>
_______________________________________

From report at bugs.python.org  Mon Mar 16 02:29:06 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 16 Mar 2015 01:29:06 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1426469346.04.0.911448980209.issue17911@psf.upfronthosting.co.za>


Robert Collins added the comment:

Looking at the regression now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17911>
_______________________________________

From report at bugs.python.org  Mon Mar 16 02:31:22 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 16 Mar 2015 01:31:22 +0000
Subject: [issue23631] 3.5 (a2) traceback regression snarls Idle
In-Reply-To: <1426022728.67.0.0261421184633.issue23631@psf.upfronthosting.co.za>
Message-ID: <1426469482.82.0.39963950459.issue23631@psf.upfronthosting.co.za>


Robert Collins added the comment:

I suspect that this is due to a list being passed in that wasn't created by traceback, in the older tuple-only format. That was meant to work, but possibly is being short circuited somewhere. Shall fix asap.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23631>
_______________________________________

From report at bugs.python.org  Mon Mar 16 02:34:20 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 16 Mar 2015 01:34:20 +0000
Subject: [issue21112] 3.4 regression: unittest.expectedFailure no longer works
 on TestCase subclasses
In-Reply-To: <1396275626.74.0.920741880392.issue21112@psf.upfronthosting.co.za>
Message-ID: <1426469660.63.0.367114944919.issue21112@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
assignee:  -> berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21112>
_______________________________________

From report at bugs.python.org  Mon Mar 16 02:48:54 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 16 Mar 2015 01:48:54 +0000
Subject: [issue23631] 3.5 (a2) traceback regression snarls Idle
In-Reply-To: <1426022728.67.0.0261421184633.issue23631@psf.upfronthosting.co.za>
Message-ID: <1426470534.84.0.748401203761.issue23631@psf.upfronthosting.co.za>


Robert Collins added the comment:

Ah, idle is being somewhat naughty. It's taking the original traceback and then mangling the contents in-place, which is preserving the type information, and throwing off StackSummary.from_list. We can and should make the new code deal with this in case other folk are doing it. In future it would be good to subsume cleanup_traceback's guts into the traceback module, but we don't need to do that now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23631>
_______________________________________

From report at bugs.python.org  Mon Mar 16 02:59:20 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 16 Mar 2015 01:59:20 +0000
Subject: [issue23631] 3.5 (a2) traceback regression snarls Idle
In-Reply-To: <1426022728.67.0.0261421184633.issue23631@psf.upfronthosting.co.za>
Message-ID: <1426471160.9.0.477051105652.issue23631@psf.upfronthosting.co.za>


Robert Collins added the comment:

And here is a patch, since this is a regression I'll apply it tomorrow (or sooner if it gets reviews :))

----------
keywords: +patch
Added file: http://bugs.python.org/file38503/issue-23631-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23631>
_______________________________________

From report at bugs.python.org  Mon Mar 16 03:02:09 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Mar 2015 02:02:09 +0000
Subject: [issue23631] 3.5 (a2) traceback regression snarls Idle
In-Reply-To: <1426022728.67.0.0261421184633.issue23631@psf.upfronthosting.co.za>
Message-ID: <1426471329.3.0.819567951484.issue23631@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23631>
_______________________________________

From report at bugs.python.org  Mon Mar 16 03:15:03 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 16 Mar 2015 02:15:03 +0000
Subject: [issue8087] Unupdated source file in traceback
In-Reply-To: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>
Message-ID: <1426472103.09.0.775287873256.issue8087@psf.upfronthosting.co.za>


Robert Collins added the comment:

Oh, it may be clear to everyone already but its perhaps worth noting: there are two ways the cache can skew.

(older source): We may have a newer file compiled and in use and the older source in the cache.

e.g. someone calls linecache.getlines(foo.py), then imports foo, and in between the contents of foo.py changed.

(newer source) Or we may have an older file compiled and in use, and newer source in the cache.

e.g. someone imports foo, the contents of foo.py change, and then someone calls linecache.getlines(foo.py).

One way to address the older source case would be to make importing (also compile()) flush the imported file out of the cache. That doesn't need any special logic or handling - just a new parameter to clearcache() to specify  a file (or files?) to evict.

The newer source case is what needs some logic, and for that, as I said earlier, I think we need something opaque. Perhaps since we have importlib now, if we limit ourselves to considering actual python modules (linecache can technically cache anything with lines in it) we can rely on the import machinery get_source() to handle this: if the source has changed get_source should return None.

That way we don't need to change the data structure of modules at all - only packages for which there is no 302 loader will be able to suffer cache skew.

As far as informing callers that this situation has occurred, I think we'll need to think a bit about that, as linecache already signals 'source not available' by returning None, which doesn't leave much room to include an error message. We could start raising exceptions up the stack - which implies modifying PEP-302 (e.g. via a new PEP) and working up the stack.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8087>
_______________________________________

From report at bugs.python.org  Mon Mar 16 03:15:23 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 16 Mar 2015 02:15:23 +0000
Subject: [issue8087] Unupdated source file in traceback
In-Reply-To: <1267990809.73.0.116039880896.issue8087@psf.upfronthosting.co.za>
Message-ID: <1426472123.44.0.00565722540547.issue8087@psf.upfronthosting.co.za>


Robert Collins added the comment:

Oh, meant to add - we could just call logging.warning or something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8087>
_______________________________________

From report at bugs.python.org  Mon Mar 16 03:25:04 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Mar 2015 02:25:04 +0000
Subject: [issue23585] patchcheck doesn't depend on all
In-Reply-To: <1425512149.56.0.0578590803035.issue23585@psf.upfronthosting.co.za>
Message-ID: <1426472704.34.0.928315493166.issue23585@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Sounds fine to me.

This could be particularly useful for docs-only patches, where you may not have done a local "make test" first.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23585>
_______________________________________

From report at bugs.python.org  Mon Mar 16 03:27:34 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Mar 2015 02:27:34 +0000
Subject: [issue23631] 3.5 (a2) traceback regression snarls Idle
In-Reply-To: <1426022728.67.0.0261421184633.issue23631@psf.upfronthosting.co.za>
Message-ID: <20150316022731.27349.88492@psf.io>


Roundup Robot added the comment:

New changeset ea3cc128ce35 by Robert Collins in branch 'default':
Issue #23631: Fix traceback.format_list when a traceback has been mutated.
https://hg.python.org/cpython/rev/ea3cc128ce35

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23631>
_______________________________________

From report at bugs.python.org  Mon Mar 16 03:30:45 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Mar 2015 02:30:45 +0000
Subject: [issue23585] patchcheck doesn't depend on all
In-Reply-To: <1425512149.56.0.0578590803035.issue23585@psf.upfronthosting.co.za>
Message-ID: <20150316023042.86349.27467@psf.io>


Roundup Robot added the comment:

New changeset de093a1ec51b by Robert Collins in branch 'default':
Issue #23585: make patchcheck will ensure the interpreter is built.
https://hg.python.org/cpython/rev/de093a1ec51b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23585>
_______________________________________

From report at bugs.python.org  Mon Mar 16 03:33:44 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 16 Mar 2015 02:33:44 +0000
Subject: [issue23585] patchcheck doesn't depend on all
In-Reply-To: <1425512149.56.0.0578590803035.issue23585@psf.upfronthosting.co.za>
Message-ID: <1426473224.6.0.163542561062.issue23585@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23585>
_______________________________________

From report at bugs.python.org  Mon Mar 16 03:52:13 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 16 Mar 2015 02:52:13 +0000
Subject: [issue23310] MagicMock constructor configuration fails for magic
 methods
In-Reply-To: <1422120039.57.0.541541438715.issue23310@psf.upfronthosting.co.za>
Message-ID: <1426474333.1.0.747544669893.issue23310@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
stage:  -> needs patch
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23310>
_______________________________________

From report at bugs.python.org  Mon Mar 16 04:04:48 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 16 Mar 2015 03:04:48 +0000
Subject: [issue23310] MagicMock constructor configuration fails for magic
 methods
In-Reply-To: <1422120039.57.0.541541438715.issue23310@psf.upfronthosting.co.za>
Message-ID: <1426475088.98.0.231776466006.issue23310@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23310>
_______________________________________

From report at bugs.python.org  Mon Mar 16 04:19:32 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 16 Mar 2015 03:19:32 +0000
Subject: [issue22937] unittest errors can't show locals
In-Reply-To: <1416881182.95.0.816242293699.issue22937@psf.upfronthosting.co.za>
Message-ID: <1426475972.39.0.533231904387.issue22937@psf.upfronthosting.co.za>


Robert Collins added the comment:

Fixed (patch referenced 22936)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22937>
_______________________________________

From report at bugs.python.org  Mon Mar 16 07:45:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Mar 2015 06:45:11 +0000
Subject: [issue23676] Add support of UnicodeTranslateError in standard error
 handlers
In-Reply-To: <1426456748.16.0.28109004659.issue23676@psf.upfronthosting.co.za>
Message-ID: <1426488311.47.0.128854175448.issue23676@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed a bug in "surrogatepass" with translating and added the versionchanged directive.

----------
Added file: http://bugs.python.org/file38504/translate_error_handlers_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23676>
_______________________________________

From report at bugs.python.org  Mon Mar 16 08:08:01 2015
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Mon, 16 Mar 2015 07:08:01 +0000
Subject: [issue23649] tarfile not re-entrant for multi-threading
In-Reply-To: <1426178401.83.0.913984210908.issue23649@psf.upfronthosting.co.za>
Message-ID: <1426489681.66.0.0951272215219.issue23649@psf.upfronthosting.co.za>


Lars Gust?bel added the comment:

I agree with David that there is no need for tarfile to be thread-safe. There is nothing to be gained from distributing one TarFile object among multiple threads because it operates on a single resource which has to be accessed sequentially anyway. So, it seems best to me if we leave it like it is and let the user add locks around it as she/he sees fit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23649>
_______________________________________

From report at bugs.python.org  Mon Mar 16 08:12:52 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Mar 2015 07:12:52 +0000
Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate
 escaped strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1426489972.28.0.338956167091.issue18814@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed preliminary patch adds three functions in the codecs module:

convert_surrogates(data, errors) -- handle lone surrogates with specified error handler.

>>> codecs.convert_surrogates('a\u20ac\udca4', 'backslashreplace')
'a?\\udca4'

convert_surrogateescape(data, errors) -- handle surrogateescaped bytes with specified error handler

>>> codecs.convert_surrogateescape('a\u20ac\udca4', 'backslashreplace')
'a?\\xa4'

convert_astrals(data, errors) -- handle astral (non-BMP) characters with specified error handler.

>>> codecs.convert_astral('a\u20ac\U000e007f', 'backslashreplace')
'a?\\U000e007f'

Names are discussable.

I think also about adding two functions or error handlers (that can used with convert_surrogates and convert_astrals) for composing astral characters from surrogate pairs and vice versa.

----------
components: +Library (Lib)
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Mon Mar 16 09:10:39 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Mar 2015 08:10:39 +0000
Subject: [issue23668] Support os.[f]truncate on Windows
In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za>
Message-ID: <1426493439.03.0.063863039494.issue23668@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file38505/23668_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23668>
_______________________________________

From report at bugs.python.org  Mon Mar 16 09:39:52 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Mar 2015 08:39:52 +0000
Subject: [issue23649] tarfile not re-entrant for multi-threading
In-Reply-To: <1426489681.66.0.0951272215219.issue23649@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwavL25AFVpWk_YWxEZFmfsdLyD3GATiFRxALawx3Hp-eg@mail.gmail.com>


STINNER Victor added the comment:

Lars Gust?bel added the comment:
> I agree with David that there is no need for tarfile to be thread-safe. There is nothing to be gained from distributing one TarFile object among multiple threads because it operates on a single resource which has to be accessed sequentially anyway. So, it seems best to me if we leave it like it is and let the user add locks around it as she/he sees fit.

In asyncio, it was a design choice to not be thread-safe, to allow
more optimizations and support multiple implementations of asyncio,
without this important constraint.

I modified recently the asyncio doc to warn users in each class that
asyncio objects are *not* thread safe, with an explanation how to use
correctly asyncio with threads.

https://docs.python.org/dev/library/asyncio-eventloop.html#asyncio.BaseEventLoop
"This class is not thread safe."

Such change in tarfile doc is probably enough for tarfile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23649>
_______________________________________

From report at bugs.python.org  Mon Mar 16 09:45:39 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Mar 2015 08:45:39 +0000
Subject: [issue23668] Support os.[f]truncate on Windows
In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za>
Message-ID: <1426495539.11.0.4351677257.issue23668@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

At first glance the patch looks good, but I did not test it. Are there tests for truncate() with large files (> 4 GiB)?

ftruncate() is used also im mmap.resize(). Do you want to provide a patch also for mmap?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23668>
_______________________________________

From report at bugs.python.org  Mon Mar 16 09:48:35 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Mar 2015 08:48:35 +0000
Subject: [issue23668] Support os.[f]truncate on Windows
In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za>
Message-ID: <1426495715.71.0.496262057159.issue23668@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I reviewed 23668_2.patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23668>
_______________________________________

From report at bugs.python.org  Mon Mar 16 09:50:55 2015
From: report at bugs.python.org (Frank Millman)
Date: Mon, 16 Mar 2015 08:50:55 +0000
Subject: [issue23677] Mention dict and set comps in library reference
Message-ID: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za>


New submission from Frank Millman:

This is from the documentation at Section 4.6.4. Lists

"""
Lists may be constructed in several ways:

Using a pair of square brackets to denote the empty list: []
Using square brackets, separating items with commas: [a], [a, b, c]
Using a list comprehension: [x for x in iterable]
Using the type constructor: list() or list(iterable)
"""

Comprehensions are mentioned as a constructor.

This is from the documentation at Section 4.10. Mapping Types

"""
Dictionaries can be created by placing a comma-separated list of key: value pairs within braces, for example: {'jack': 4098, 'sjoerd': 4127} or {4098: 'jack', 4127: 'sjoerd'}, or by the dict constructor.

class dict(**kwarg) 
class dict(mapping, **kwarg) 
class dict(iterable, **kwarg) 
Return a new dictionary initialized from an optional positional argument and a possibly empty set of keyword arguments.
"""

There is no mention of dictionary comprehensions.

For consistency, I believe that the documentation for Dicts and Sets should mention comprehensions.

----------
assignee: docs at python
components: Documentation
messages: 238186
nosy: FrankMillman, docs at python
priority: normal
severity: normal
status: open
title: Mention dict and set comps in library reference
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23677>
_______________________________________

From report at bugs.python.org  Mon Mar 16 10:27:06 2015
From: report at bugs.python.org (Hiroaki Miyajima)
Date: Mon, 16 Mar 2015 09:27:06 +0000
Subject: [issue23656] shutil.copyfile (or built-in open) releases sqlite3's
 transaction lock
In-Reply-To: <1426234382.55.0.94867097951.issue23656@psf.upfronthosting.co.za>
Message-ID: <1426498026.56.0.861879757558.issue23656@psf.upfronthosting.co.za>


Hiroaki Miyajima added the comment:

I've realized that this is a bug of specification of fcntl system call.
I am sorry to bother this site.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23656>
_______________________________________

From report at bugs.python.org  Mon Mar 16 10:31:53 2015
From: report at bugs.python.org (bjshan)
Date: Mon, 16 Mar 2015 09:31:53 +0000
Subject: [issue23678] imaplib status command cannot handle folder name
 containing whitespaces
Message-ID: <1426498313.59.0.493788060886.issue23678@psf.upfronthosting.co.za>


New submission from bjshan:

imaplib status failed if the folder name contains whitespace.
For example, 
c = IMAP4_SSL('hostname')
c = login(username, password)
c.status('Drafts', '(MESSAGES)')    # would succeed
c.status('Apple Mail To Do', '(MESSAGES)') # would fail, error message is:
imaplib.error: STATUS command error: BAD [b"parse error: wrong character; expected '(' but got 'M'"]

It seems the status method could not properly parse the folder name "Apple Mail To Do", it recognizes only the first word "Apple", then failed when meeting the following word "Mail". 

I checked imaplib.py, _command 's definition looks like the cause, but I am not sure:

    def _command(self, name, *args):
         
        ...    
        
        name = bytes(name, 'ASCII')
        data = tag + b' ' + name
        for arg in args:
            if arg is None: continue
            if isinstance(arg, str):
                arg = bytes(arg, "ASCII")
            data = data + b' ' + arg

Work around for this:
Manually add double quote around the folder name, like:   
   '"' + mailbox_name + '"'

BUT, 
while c.status('"Apple Mail To Do"', '(MESSAGES)') worked, 
c.status("'Apple Mail To Do'", '(MESSAGES)') failed. Suggesting single and double quote weighs not the same?

----------
components: Library (Lib)
messages: 238188
nosy: bjshan
priority: normal
severity: normal
status: open
title: imaplib status command cannot handle folder name containing whitespaces
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23678>
_______________________________________

From report at bugs.python.org  Mon Mar 16 11:30:16 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Mar 2015 10:30:16 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>
Message-ID: <1426501816.18.0.447802355619.issue23566@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I reviewed  issue23566_fd_tests.patch .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23566>
_______________________________________

From report at bugs.python.org  Mon Mar 16 11:31:21 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Mar 2015 10:31:21 +0000
Subject: [issue23670] Modifications to support iOS as a cross-compilation
 target
In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za>
Message-ID: <1426501881.16.0.445766967676.issue23670@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Rather than trying to do something ourselves on the mobile testing front, we may want to instead explore the free-for-open-source-project offering from Sauce Labs: https://saucelabs.com/opensauce/

Adapting that to run the CPython self-tests as an "app" might be interesting, but they're PyCon sponsors, so they may be amenable to helping to get that work properly if we need to ask for their help.

Getting that set up would also potentially be a useful tool for ensuring PSF web services are working correctly across multiple browsers and client devices. (I'd actually like to get us to the point of being able to do continuous deployment of those services some day)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23670>
_______________________________________

From report at bugs.python.org  Mon Mar 16 11:32:26 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Mar 2015 10:32:26 +0000
Subject: [issue23670] Modifications to support iOS as a cross-compilation
 target
In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za>
Message-ID: <1426501946.96.0.279135924587.issue23670@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

(Some work on the Buildbot site would still be required, but it would be triggering a Sauce Labs run rather than managing the mobile hardware directly)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23670>
_______________________________________

From report at bugs.python.org  Mon Mar 16 11:52:49 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Mar 2015 10:52:49 +0000
Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate
 escaped strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1426503169.82.0.391058778806.issue18814@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file38506/codecs_convert_escapes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Mon Mar 16 11:55:21 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Mar 2015 10:55:21 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <20150316105518.27379.11862@psf.io>


Roundup Robot added the comment:

New changeset 91fbe0fff882 by Victor Stinner in branch 'default':
Issue #23571: Restore removed assert(!PyErr_Occurred()); in
https://hg.python.org/cpython/rev/91fbe0fff882

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Mon Mar 16 12:00:12 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Mar 2015 11:00:12 +0000
Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate
 escaped strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1426503612.6.0.0271090635277.issue18814@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

(Serhiy, did you miss uploading the new patch?)

Regarding the names, we may need to think about the use cases a bit more explicitly to clarify that in terms of the Python codecs API rather than expecting folks to understand the underlying representation. In the case of handling lone surrogates and escaped surrogates, what about:

    rehandle_surrogatepass(data, errors="strict")
    rehandle_surrogateescape(data, errors="strict")

That is, we know we have data that was decoded with either surrogatepass or surrogateespace (respectively) as the error handler, and we want to process the results of that with a different error handler.

I believe those two would be enough to address the specific cases this issue was raised to cover, so it may make sense to file a separate issue to discuss the use cases for the custom astral handling.

Since astrals aren't actually errors in the first place, that could become:

    handle_astrals(data, errors="strict")

As in "pass every astral code point in this string through the named error handler".

The astral -> surrogate pair and surrogate pair -> astral converters do sound potentially interesting, but as noted above, I think they may call for a separate issue that better explains the specific use cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Mon Mar 16 12:05:30 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 16 Mar 2015 11:05:30 +0000
Subject: [issue23677] Mention dict and set comps in library reference
In-Reply-To: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za>
Message-ID: <1426503930.84.0.0889551742417.issue23677@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
keywords: +patch
versions: +Python 3.5
Added file: http://bugs.python.org/file38507/issue23677.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23677>
_______________________________________

From report at bugs.python.org  Mon Mar 16 12:31:05 2015
From: report at bugs.python.org (mogli)
Date: Mon, 16 Mar 2015 11:31:05 +0000
Subject: [issue23679] SSL Ciphers RC4
Message-ID: <1426505465.73.0.583137037383.issue23679@psf.upfronthosting.co.za>


New submission from mogli:

The documentation (https://docs.python.org/2/library/ssl.html) says:
The settings in Python 2.7.9 are: PROTOCOL_SSLv23, OP_NO_SSLv2, and OP_NO_SSLv3 with high encryption cipher suites without RC4

But it still seems to use RC4: https://www.howsmyssl.com/a/check

Also the test at https://www.ssllabs.com/ssltest/viewMyClient.html says it still supports SSLv3 (not so sure about this one).

----------
messages: 238194
nosy: mogli
priority: normal
severity: normal
status: open
title: SSL Ciphers RC4
type: security
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23679>
_______________________________________

From report at bugs.python.org  Mon Mar 16 12:41:08 2015
From: report at bugs.python.org (Mayank Tripathi)
Date: Mon, 16 Mar 2015 11:41:08 +0000
Subject: [issue21862] cProfile command-line should accept "-m module_name" as
 an alternative to script path
In-Reply-To: <1403640414.18.0.449527177368.issue21862@psf.upfronthosting.co.za>
Message-ID: <1426506068.68.0.652461211897.issue21862@psf.upfronthosting.co.za>


Mayank Tripathi added the comment:

Could someone please review the patch. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21862>
_______________________________________

From report at bugs.python.org  Mon Mar 16 13:06:01 2015
From: report at bugs.python.org (Tapani Kiiskinen)
Date: Mon, 16 Mar 2015 12:06:01 +0000
Subject: [issue23674] super() documentation isn't very clear
In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za>
Message-ID: <1426507561.5.0.662304854479.issue23674@psf.upfronthosting.co.za>


Tapani Kiiskinen added the comment:

A link to the to the glossary would also be good yes. I was figuring out how super() works and as you said the doc gave the impression getattr would explain more but it doesn't. Had to use google to find the glossary entry for MRO which had the link explaining how that is calculated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23674>
_______________________________________

From report at bugs.python.org  Mon Mar 16 14:20:05 2015
From: report at bugs.python.org (Russell Keith-Magee)
Date: Mon, 16 Mar 2015 13:20:05 +0000
Subject: [issue23670] Modifications to support iOS as a cross-compilation
 target
In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za>
Message-ID: <1426512005.15.0.0716975854376.issue23670@psf.upfronthosting.co.za>


Russell Keith-Magee added the comment:

Nick: Finding a way to get on-device test results is next on my TODO list, once I've got the patch up to date for trunk. 

FYI - Updating to trunk is currently blocking on issue22625 (which was introduced by the fix for issue22359).

I had thought about using a mobile testing farm "as a service", but I didn't know Sauce Labs had one. I'll keep that in mind when I get around to working on the test suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23670>
_______________________________________

From report at bugs.python.org  Mon Mar 16 14:32:49 2015
From: report at bugs.python.org (Russell Keith-Magee)
Date: Mon, 16 Mar 2015 13:32:49 +0000
Subject: =?utf-8?q?=5Bissue22625=5D_When_cross-compiling=2C_don=E2=80=99t_try_to_e?=
 =?utf-8?q?xecute_binaries?=
In-Reply-To: <1413226219.68.0.732560661241.issue22625@psf.upfronthosting.co.za>
Message-ID: <1426512769.83.0.322141303708.issue22625@psf.upfronthosting.co.za>


Russell Keith-Magee added the comment:

I'm looking into this issue because of issue23670 (iOS support). 

Am I correct in assuming that the right fix here is to identify a $(CC_FOR_BUILD) analog for $(PYTHON_FOR_BUILD) that will identify the build host's CC, enabling a build-host native $(PGEN) and _freeze_importlib to be compiled?

----------
nosy: +freakboy3742

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22625>
_______________________________________

From report at bugs.python.org  Mon Mar 16 14:39:13 2015
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 16 Mar 2015 13:39:13 +0000
Subject: [issue22359] Remove incorrect uses of recursive make
In-Reply-To: <1410165869.76.0.203082844365.issue22359@psf.upfronthosting.co.za>
Message-ID: <1426513153.71.0.962742306075.issue22359@psf.upfronthosting.co.za>


Matthias Klose added the comment:

reopening, breaks cross builds. I'll have a look

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22359>
_______________________________________

From report at bugs.python.org  Mon Mar 16 14:41:45 2015
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 16 Mar 2015 13:41:45 +0000
Subject: =?utf-8?q?=5Bissue22625=5D_When_cross-compiling=2C_don=E2=80=99t_try_to_e?=
 =?utf-8?q?xecute_binaries?=
In-Reply-To: <1413226219.68.0.732560661241.issue22625@psf.upfronthosting.co.za>
Message-ID: <1426513305.57.0.455419776894.issue22625@psf.upfronthosting.co.za>


Matthias Klose added the comment:

there are two approaches here, one to check in generated files and try to avoid the rebuild, or completely fix the cross build. I think the patch for the parallel build just was a bit over-eager

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22625>
_______________________________________

From report at bugs.python.org  Mon Mar 16 14:55:35 2015
From: report at bugs.python.org (Leonardo Bianconi)
Date: Mon, 16 Mar 2015 13:55:35 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_g++_module_compile_fails_with_=E2=80=98=5FAtom?=
 =?utf-8?q?ic=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426514135.01.0.908994680994.issue23644@psf.upfronthosting.co.za>


Leonardo Bianconi added the comment:

@haypo

For adding compatibility for atomics based on @Joshua.J.Cogliati change, I propose:

#ifndef Py_LIMITED_API
#ifndef Py_ATOMIC_H
#define Py_ATOMIC_H

#include "dynamic_annotations.h"

#include "pyconfig.h"

#if defined(HAVE_STD_ATOMIC)
#ifdef __cplusplus
#include <atomic>
#define _Atomic(T) atomic<T>
using namespace std;
#else
#include <stdatomic.h>
#endif
#endif

#ifdef __cplusplus
extern "C" {
#endif


/* This is modeled after the atomics interface from C1x, according to
 * the draft at
 * http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1425.pdf.
 * Operations and types are named the same except with a _Py_ prefix
 * and have the same semantics.
 *
 * Beware, the implementations here are deep magic.
 */

#if defined(HAVE_STD_ATOMIC)

typedef enum _Py_memory_order {
    _Py_memory_order_relaxed = memory_order_relaxed,
    _Py_memory_order_acquire = memory_order_acquire,
    _Py_memory_order_release = memory_order_release,
    _Py_memory_order_acq_rel = memory_order_acq_rel,
    _Py_memory_order_seq_cst = memory_order_seq_cst
} _Py_memory_order;

typedef struct _Py_atomic_address {
    _Atomic (void) *_value;
} _Py_atomic_address;

typedef struct _Py_atomic_int {
    atomic_int _value;
} _Py_atomic_int;


... (rest same)

----------
keywords: +patch
Added file: http://bugs.python.org/file38508/atomicfix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Mon Mar 16 14:59:36 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Mar 2015 13:59:36 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_g++_module_compile_fails_with_=E2=80=98=5FAtom?=
 =?utf-8?q?ic=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426514376.0.0.317478435636.issue23644@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> using namespace std;

Doing this in a header is ugly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Mon Mar 16 15:00:58 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Mar 2015 14:00:58 +0000
Subject: [issue23677] Mention dict and set comps in library reference
In-Reply-To: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za>
Message-ID: <1426514458.91.0.302149933895.issue23677@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sounds reasonable.  Dict and set comprehensions were added later than list comprehensions, and we probably just didn't notice this needed updating.

Mark's patch, however, is incorrect.  Mark: the dict/set literal notation is a different thing from a comprehension.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23677>
_______________________________________

From report at bugs.python.org  Mon Mar 16 15:03:46 2015
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Mon, 16 Mar 2015 14:03:46 +0000
Subject: [issue23624] str.center inconsistent with format "^"
In-Reply-To: <1425966835.2.0.36838695627.issue23624@psf.upfronthosting.co.za>
Message-ID: <1426514626.22.0.324127387956.issue23624@psf.upfronthosting.co.za>


Vedran ?a?i? added the comment:

Ok, let's say I see your point about breaking existing code (though, I reiterate, it's _undocumented_ and even examples in the docs all cover only the obvious case).

Is it _at least_ possible to give .center an (keyword-only if needed) argument that specifies the rounding method? Default will of course be "ROUND_HALF_EVEN", but it should be possible at least to specify "ROUND_FLOOR" to be consistent with format (maybe other rounding method should be supported, but it's not important).

This will not break anything, and it will be a tremendous help to those who want to switch from one method to the other (for example, once the field width becomes variable)? I suggest changing .center instead of format because a) it's easier and more Pythonic (keyword-only arguments are accepted method of dealing exactly with that kind of problem), b) it's more likely wanted to be changed, since format method is more "obvious" to many people, c) I guess more people switch in that direction, and d) format doesn't really have a nice hook in the format string to customize the rounding.

I sincerely hope you'll agree at least to this. Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23624>
_______________________________________

From report at bugs.python.org  Mon Mar 16 15:05:43 2015
From: report at bugs.python.org (Mark Hughes)
Date: Mon, 16 Mar 2015 14:05:43 +0000
Subject: [issue22931] cookies with square brackets in value
In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za>
Message-ID: <1426514743.93.0.468106234256.issue22931@psf.upfronthosting.co.za>


Mark Hughes added the comment:

This is also an issue with Python 2.7.9 but not 2.7.8. There were various cookie related fixes in 2.7.9 which could have revealed this issue. Maybe this one?

https://hg.python.org/cpython/rev/9e765e65e5cb

----------
nosy: +Mark Hughes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22931>
_______________________________________

From report at bugs.python.org  Mon Mar 16 15:09:03 2015
From: report at bugs.python.org (Dan Nawrocki)
Date: Mon, 16 Mar 2015 14:09:03 +0000
Subject: [issue23658] multiprocessing: string arg to SystemExit
In-Reply-To: <1426260142.17.0.720553845147.issue23658@psf.upfronthosting.co.za>
Message-ID: <1426514943.79.0.686817399408.issue23658@psf.upfronthosting.co.za>


Dan Nawrocki added the comment:

I am using 2.7.5 (RHEL7 and FC20). Indeed, this issue appears fixed in 2.7.7, by https://hg.python.org/cpython/diff/44b5ec2f0f5d/Lib/multiprocessing/process.py.

I'm closing as not a bug.

Thanks for the help!

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23658>
_______________________________________

From report at bugs.python.org  Mon Mar 16 15:11:25 2015
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Mon, 16 Mar 2015 14:11:25 +0000
Subject: [issue23665] Provide IDLE menu option to set command-line arguments
In-Reply-To: <1426376024.32.0.301061562538.issue23665@psf.upfronthosting.co.za>
Message-ID: <1426515085.03.0.62362794185.issue23665@psf.upfronthosting.co.za>


Saimadhav Heblikar added the comment:

http://bugs.python.org/issue5680

Also had submitted a patch for it. Could you post your review there? (I was learning the CPython style then, so excuse obvious mistakes :) )

----------
nosy: +sahutd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23665>
_______________________________________

From report at bugs.python.org  Mon Mar 16 15:11:28 2015
From: report at bugs.python.org (Joshua J Cogliati)
Date: Mon, 16 Mar 2015 14:11:28 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_g++_module_compile_fails_with_=E2=80=98=5FAtom?=
 =?utf-8?q?ic=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426515088.4.0.306572134759.issue23644@psf.upfronthosting.co.za>


Joshua J Cogliati added the comment:

>> using namespace std;

>Doing this in a header is ugly.

If you put it in the:
#ifdef __cplusplus
extern "C" {
#endif

then it would only apply till the end of the pyatomic header, and not to anything that includes it.  Something like:

#ifdef __cplusplus
extern "C" {
#if defined(HAVE_STD_ATOMIC)
using namespace std;
#endif
#endif

But if you are already defining:
#define _Atomic(T) atomic<T>
maybe it should be:
#define _Atomic(T) std::atomic<T>

(I haven't checked any of this code, but they would get around the namespace std being changed in code that includes pyatomic.h problem. )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Mon Mar 16 15:23:36 2015
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 16 Mar 2015 14:23:36 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426515816.15.0.400676030365.issue2211@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


Added file: http://bugs.python.org/file38509/issue2211_5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Mon Mar 16 15:24:23 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Mar 2015 14:24:23 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_g++_module_compile_fails_with_=E2=80=98=5FAtom?=
 =?utf-8?q?ic=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426515088.4.0.306572134759.issue23644@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb5Dgek-1yDjX1TC8UV8WHjzUNxC=i7Lic3jTQ9t_GjcQ@mail.gmail.com>


STINNER Victor added the comment:

> #define _Atomic(T) std::atomic<T>

This looks better to me :-) Can you please write a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Mon Mar 16 16:09:32 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Mar 2015 15:09:32 +0000
Subject: [issue23656] shutil.copyfile (or built-in open) releases sqlite3's
 transaction lock
In-Reply-To: <1426234382.55.0.94867097951.issue23656@psf.upfronthosting.co.za>
Message-ID: <1426518572.42.0.808219363162.issue23656@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> not a bug
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23656>
_______________________________________

From report at bugs.python.org  Mon Mar 16 16:16:36 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Mar 2015 15:16:36 +0000
Subject: [issue23678] imaplib status command cannot handle folder name
 containing whitespaces
In-Reply-To: <1426498313.59.0.493788060886.issue23678@psf.upfronthosting.co.za>
Message-ID: <1426518996.54.0.905086620005.issue23678@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is a duplicate of a subset of issue 917120.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> imaplib: incorrect quoting in commands

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23678>
_______________________________________

From report at bugs.python.org  Mon Mar 16 16:16:53 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Mar 2015 15:16:53 +0000
Subject: [issue917120] imaplib: incorrect quoting in commands
Message-ID: <1426519013.42.0.477973571124.issue917120@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +bjshan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue917120>
_______________________________________

From report at bugs.python.org  Mon Mar 16 16:24:24 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Mar 2015 15:24:24 +0000
Subject: [issue23670] Modifications to support iOS as a cross-compilation
 target
In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za>
Message-ID: <1426519464.26.0.731668774041.issue23670@psf.upfronthosting.co.za>


R. David Murray added the comment:

The Sauce labs option may render this obsolete, but to answer your question, Russell: our buildbot fleet is distributed in many people's offices, basements, and occasionally colo racks.  The buildbot needs to be on-line 24/7, but it "calls out" and does not need any inbound ports open.  See https://wiki.python.org/moin/BuildBot for the currently available documentation about setting up a buildbot for our fleet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23670>
_______________________________________

From report at bugs.python.org  Mon Mar 16 16:26:46 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Mar 2015 15:26:46 +0000
Subject: [issue23679] SSL Ciphers RC4
In-Reply-To: <1426505465.73.0.583137037383.issue23679@psf.upfronthosting.co.za>
Message-ID: <1426519606.27.0.0115956099239.issue23679@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +alex, dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23679>
_______________________________________

From report at bugs.python.org  Mon Mar 16 16:31:18 2015
From: report at bugs.python.org (Alex Gaynor)
Date: Mon, 16 Mar 2015 15:31:18 +0000
Subject: [issue23679] SSL Ciphers RC4
In-Reply-To: <1426505465.73.0.583137037383.issue23679@psf.upfronthosting.co.za>
Message-ID: <1426519878.1.0.492591509202.issue23679@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

I believe RC4 will still be used under 2.7.9 on clients, this is changed for 2.7.10

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23679>
_______________________________________

From report at bugs.python.org  Mon Mar 16 16:41:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Mar 2015 15:41:15 +0000
Subject: [issue23624] str.center inconsistent with format "^"
In-Reply-To: <1425966835.2.0.36838695627.issue23624@psf.upfronthosting.co.za>
Message-ID: <1426520475.09.0.61442040565.issue23624@psf.upfronthosting.co.za>


R. David Murray added the comment:

Backward compatibility does not mean "matches the docs", it means "if we change this, someone's existing code is likely to break".  That does not prevent us from making at-the-margin changes in a feature release, but it is still a bar to be overcome in making such a change, and the consensus here is that it doesn't meet that bar.

Your primary argument seems to be the desire to make it easy to switch to center if the width of the field becomes a variable.  But you note yourself that you do not need to do this; format is quite capable of handing a variable width field.

So, there also does not seem to be sufficient motivation to add this feature.  If you wish to pursue this further, posting your proposal for a keyword for center and the motivation to python-ideas would be the way to proceed.  If you gather a consensus of support there, you can propose a new enhancement request issue with a link to the python-ideas discussion.  (Or, in the unlikely case that the consensus is that center's algorithm should change, we can reopen this issue.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23624>
_______________________________________

From report at bugs.python.org  Mon Mar 16 16:49:24 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 16 Mar 2015 15:49:24 +0000
Subject: [issue23668] Support os.[f]truncate on Windows
In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za>
Message-ID: <1426520964.86.0.42523558047.issue23668@psf.upfronthosting.co.za>


Steve Dower added the comment:

It looks like mmap uses pure Win32 APIs for the Windows implementation, and so _chsize_s isn't necessary. There is a comment "todo: need ... a 'chsize' analog" in the file, but I'm not actually sure what that means.

I've made some minor changes from the review, but I had a question about possibly defining HAVE_[F]TRUNCATE in *.c rather than *.h. See the review, and I'll update the patch once we've figured that out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23668>
_______________________________________

From report at bugs.python.org  Mon Mar 16 16:53:27 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Mar 2015 15:53:27 +0000
Subject: [issue23680] Sporadic freeze in test_interrupted_write_retry_text
Message-ID: <1426521207.32.0.580722848653.issue23680@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Sometimes the test suite freezes in test_interrupted_write_retry_text (test.test_io.CSignalsTest). Corresponding strace is:


write(1, "test_interrupted_write_retry_tex"..., 66) = 66
rt_sigaction(SIGALRM, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, {SIG_DFL, [], SA_RESTORER, 0x7fd1ada2d0a0}, 8) = 0
pipe2([4, 5], O_CLOEXEC)                = 0
rt_sigaction(SIGALRM, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, 8) = 0
fstat(5, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fstat(5, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd0944d40) = -1 EINVAL (Invalid argument)
lseek(5, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
lseek(5, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
alarm(1)                                = 0
brk(0x3360000)                          = 0x3360000
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0x2640030)                 = 53870592
write(5, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"..., 4194305


A successful run looks like this:

write(1, "test_interrupted_write_retry_tex"..., 66) = 66
rt_sigaction(SIGALRM, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, {SIG_DFL, [], SA_RESTORER, 0x7fd1ada2d0a0}, 8) = 0
pipe2([4, 5], O_CLOEXEC)                = 0
rt_sigaction(SIGALRM, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, 8) = 0
fstat(5, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
fstat(5, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fffd0944d40) = -1 EINVAL (Invalid argument)
lseek(5, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
lseek(5, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
alarm(1)                                = 0
brk(0x2f60000)                          = 0x2f60000
brk(0x3360000)                          = 0x3360000
write(5, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"..., 4194305) = 65536
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0x2640030)                 = 65536
rt_sigaction(SIGALRM, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, 8) = 0
alarm(1)                                = 0
write(5, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"..., 4128769) = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0x2640030)                 = -1 EINTR (Interrupted system call)
clone(child_stack=0x7fd1a8852ff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SE
TTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x7fd1a88539d0, tls=0x7fd1a8853700, child_tidptr=0x7fd1a88539d0) = 3611
futex(0x24b5140, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
futex(0x9a1904, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1563, {1426520501, 20155000}, ffffffff) = 0
futex(0x9a1940, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0x9a1940, FUTEX_WAKE_PRIVATE, 1)  = 0
write(5, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"..., 4128769) = 4128769
futex(0x9a1904, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x9a1900, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x9a1940, FUTEX_WAKE_PRIVATE, 1)  = 1
futex(0x2631c50, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
close(5)                                = 0
close(4)                                = 0
rt_sigaction(SIGALRM, {SIG_DFL, [], SA_RESTORER, 0x7fd1ada2d0a0}, {0x444400, [], SA_RESTORER, 0x7fd1ada2d0a0}, 8) = 0
write(1, "ok\n", 3)                     = 3

----------
messages: 238215
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: Sporadic freeze in test_interrupted_write_retry_text
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23680>
_______________________________________

From report at bugs.python.org  Mon Mar 16 16:53:35 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Mar 2015 15:53:35 +0000
Subject: [issue23680] Sporadic freeze in test_interrupted_write_retry_text
In-Reply-To: <1426521207.32.0.580722848653.issue23680@psf.upfronthosting.co.za>
Message-ID: <1426521215.79.0.742500885334.issue23680@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Tests
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23680>
_______________________________________

From report at bugs.python.org  Mon Mar 16 17:01:04 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Mar 2015 16:01:04 +0000
Subject: [issue23680] Sporadic freeze in test_interrupted_write_retry_text
In-Reply-To: <1426521207.32.0.580722848653.issue23680@psf.upfronthosting.co.za>
Message-ID: <1426521664.1.0.277503353599.issue23680@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The bug only occurs in Python 3.5, right?

> Sometimes the test suite freezes in test_interrupted_write_retry_text (test.test_io.CSignalsTest).

How do you run the test suite? Is your system heavily loaded? Is it "fast"?

This is an obvious race condition in the test if SIGARLM is send before write() is called:

            signal.alarm(1)
            # Expected behaviour:
            # - first raw write() is partial (because of the limited pipe buffer
            #   and the first alarm)
            # - second raw write() returns EINTR (because of the second alarm)
            # - subsequent write()s are successful (either partial or complete)
            self.assertEqual(N, wio.write(item * N))

1 second should be enough :-)

--

Or it is maybe a regression caused by the changeset 5b63010be19e of issue #23285 (PEP 475).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23680>
_______________________________________

From report at bugs.python.org  Mon Mar 16 17:18:05 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Mar 2015 16:18:05 +0000
Subject: [issue23680] Sporadic freeze in test_interrupted_write_retry_text
In-Reply-To: <1426521207.32.0.580722848653.issue23680@psf.upfronthosting.co.za>
Message-ID: <1426522685.56.0.828790254724.issue23680@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The system is rather slow (a shared VPS instance). In the trace you can SIGALRM is triggered before the first write() call (or so it seems).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23680>
_______________________________________

From report at bugs.python.org  Mon Mar 16 17:28:12 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Mar 2015 16:28:12 +0000
Subject: [issue23680] Sporadic freeze in test_interrupted_write_retry_text
In-Reply-To: <1426521207.32.0.580722848653.issue23680@psf.upfronthosting.co.za>
Message-ID: <1426523292.71.0.0801545644433.issue23680@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The system is rather slow (a shared VPS instance). In the trace you can SIGALRM is triggered before the first write() call (or so it seems).

Yep. It remembers me my old idea to make "sleep configurable" in tests: issue #20910.

Most of the time, 1 second is enough. But on such very slow setup, it's annoying to get random failures because of race conditions. It would be better to use longer timeout (ex: 5 seconds), without making tests longer on other buildbots.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23680>
_______________________________________

From report at bugs.python.org  Mon Mar 16 17:38:21 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 16 Mar 2015 16:38:21 +0000
Subject: [issue23679] SSL Ciphers RC4
In-Reply-To: <1426505465.73.0.583137037383.issue23679@psf.upfronthosting.co.za>
Message-ID: <1426523901.48.0.422310345978.issue23679@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

RC4 is dropped in the next releases.

----------
dependencies: +SSL module should not offer RC4 based cipher suites for clients by default
nosy: +benjamin.peterson
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23679>
_______________________________________

From report at bugs.python.org  Mon Mar 16 17:40:00 2015
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 16 Mar 2015 16:40:00 +0000
Subject: [issue22852] urllib.parse wrongly strips empty #fragment
In-Reply-To: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za>
Message-ID: <1426524000.73.0.866321966499.issue22852@psf.upfronthosting.co.za>


Demian Brecht added the comment:

I've done an initial pass in Rietveld and left some comments, mostly around docs. Here are some additional questions though:

Given has_* flags can be inferred during instantiation of *Result classes, is there a reason to have them writable, meaning is there a reason to add them to the __init__ methods?

I'd also like to see this logic moved out of _NetlocResultMixinBase. I'm assuming it was put there for backwards compatibility which is understandable, but I don't think it makes sense to add such logic to a mixin who's purpose is additional functionality around the netloc attribute. This one's a little more subjective though, but here's a rough idea of what I'm thinking:

SplitResult = namedtuple('SplitResult', 'scheme netloc path query fragment')
class _SplitResultBase(SplitResult):
    def __new__(cls, scheme, netloc, path, query, fragment):
        inst = super().__new__(cls, scheme, netloc, path, query, fragment)
        inst.has_netloc = bool(netloc)
        return inst

>>> s = urlsplit('http://example.com/foo/bar/')
>>> s.has_netloc
True

This keeps backwards compatibility, but also adds the additional logic to the bases rather than in the mixins. I might also split out the logic into helper functions in order to avoid duplication between _SplitResultBase and _ParseResultBase.

This method also avoids the dependency on ordering of base classes as well as the addition of a variadic signature to (Split|Parse)Result.__init__.

Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22852>
_______________________________________

From report at bugs.python.org  Mon Mar 16 17:41:08 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Mar 2015 16:41:08 +0000
Subject: [issue23680] Sporadic freeze in test_interrupted_write_retry_text
In-Reply-To: <1426521207.32.0.580722848653.issue23680@psf.upfronthosting.co.za>
Message-ID: <1426524068.73.0.264564987897.issue23680@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Note that PIPE_MAX_SIZE can be large. Perhaps move the memory allocation (i.e. `item * (support.PIPE_MAX_SIZE // len(item) + 1)`) before the alarm(1) call?

Or what if alarm_interrupt is simply set up to retrigger the signal? e.g. instead of:

    def alarm_interrupt(self, sig, frame):
        1/0

write:

    def alarm_interrupt(self, sig, frame):
        signal.alarm(1)
        1/0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23680>
_______________________________________

From report at bugs.python.org  Mon Mar 16 17:42:36 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Mar 2015 16:42:36 +0000
Subject: [issue23679] SSL Ciphers RC4
In-Reply-To: <1426505465.73.0.583137037383.issue23679@psf.upfronthosting.co.za>
Message-ID: <1426524156.95.0.733346825407.issue23679@psf.upfronthosting.co.za>


STINNER Victor added the comment:

You can explicitly disable RC4 if you create a SSLContext and then call set_ciphers() with the right list of ciphers. See for examples cipher lists of Python 2.7 (development branch):
https://hg.python.org/cpython/file/0b44c749ae51/Lib/ssl.py#l150

Add ":!RC4" at the end of the cipher list to disable RC4.

OpenSSL cipher list format:
https://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23679>
_______________________________________

From report at bugs.python.org  Mon Mar 16 17:49:45 2015
From: report at bugs.python.org (Leonardo Bianconi)
Date: Mon, 16 Mar 2015 16:49:45 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_g++_module_compile_fails_with_=E2=80=98=5FAtom?=
 =?utf-8?q?ic=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426524585.86.0.713637662928.issue23644@psf.upfronthosting.co.za>


Leonardo Bianconi added the comment:

> #define _Atomic(T) std::atomic<T>
Does not work, since there are definitions like "memory_order_relaxed" that are in std.

I tested the other one, and it works fine:
>#ifdef __cplusplus
>extern "C" {
>#if defined(HAVE_STD_ATOMIC)
>using namespace std;
>#endif
>#endif

@haypo, what do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Mon Mar 16 17:58:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Mar 2015 16:58:38 +0000
Subject: [issue23680] Sporadic freeze in test_interrupted_write_retry_text
In-Reply-To: <1426521207.32.0.580722848653.issue23680@psf.upfronthosting.co.za>
Message-ID: <20150316165835.27355.92593@psf.io>


Roundup Robot added the comment:

New changeset a18f7508649b by Victor Stinner in branch 'default':
Issue #23680: Reduce risk of race condition in check_interrupted_write_retry()
https://hg.python.org/cpython/rev/a18f7508649b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23680>
_______________________________________

From report at bugs.python.org  Mon Mar 16 18:00:17 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 16 Mar 2015 17:00:17 +0000
Subject: [issue23680] Sporadic freeze in test_interrupted_write_retry_text
In-Reply-To: <1426521207.32.0.580722848653.issue23680@psf.upfronthosting.co.za>
Message-ID: <1426525217.3.0.622078088856.issue23680@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Also, I think there another issue in that test. It uses `N = support.PIPE_MAX_SIZE` but I think you want `N = support.PIPE_MAX_SIZE + 1` if you want the raw write() to block.

There is another test that can have a race condition: check_interrupted_write().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23680>
_______________________________________

From report at bugs.python.org  Mon Mar 16 18:00:59 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Mar 2015 17:00:59 +0000
Subject: [issue23680] Sporadic freeze in test_interrupted_write_retry_text
In-Reply-To: <1426524068.73.0.264564987897.issue23680@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb1N7e1jk8_adAO+GLdb-GkBNd_xn77H_pkh3qX0uqjLQ@mail.gmail.com>


STINNER Victor added the comment:

2015-03-16 17:41 GMT+01:00 Antoine Pitrou <report at bugs.python.org>:
> Note that PIPE_MAX_SIZE can be large. Perhaps move the memory allocation (i.e. `item * (support.PIPE_MAX_SIZE // len(item) + 1)`) before the alarm(1) call?

Good idea, the first strace shows that SIGALRM was received while
Python was creating the large data.

I made this simple change. Can you tell me if my change fixes the issue?

> Or what if alarm_interrupt is simply set up to retrigger the signal?

It may make the test more reliable and I don't see how it can fix the
issue showed in the strace. Feel free to make the test more reliable
with such change if you want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23680>
_______________________________________

From report at bugs.python.org  Mon Mar 16 18:05:02 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 Mar 2015 17:05:02 +0000
Subject: [issue23680] Sporadic freeze in test_interrupted_write_retry_text
In-Reply-To: <CAMpsgwb1N7e1jk8_adAO+GLdb-GkBNd_xn77H_pkh3qX0uqjLQ@mail.gmail.com>
Message-ID: <CAMpsgwYywz_b6xcwREj-or0C71fe=D7w=ow4UkJcD2f_dHRd4Q@mail.gmail.com>


STINNER Victor added the comment:

> Also, I think there another issue in that test. It uses `N = support.PIPE_MAX_SIZE` but I think you want `N = support.PIPE_MAX_SIZE + 1` if you want the raw write() to block.

PIPE_MAX_SIZE is much larger than the effictive size of a pipe on
Linux. It's defined as:

# A constant likely larger than the underlying OS pipe buffer size, to
# make writes blocking.
# Windows limit seems to be around 512 B, and many Unix kernels have a
# 64 KiB pipe buffer size or 16 * PAGE_SIZE: take a few megs to be sure.
# (see issue #17835 for a discussion of this number).
PIPE_MAX_SIZE = 4 * 1024 * 1024 + 1

I don't think that PIPE_MAX_SIZE+1 makes a difference here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23680>
_______________________________________

From report at bugs.python.org  Mon Mar 16 18:05:30 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 16 Mar 2015 17:05:30 +0000
Subject: [issue23681] Have -b warn when directly comparing ints and bytes
Message-ID: <1426525530.11.0.0814957947674.issue23681@psf.upfronthosting.co.za>


New submission from Brett Cannon:

To help writing Python 2/3 code the -b flag should switch on a warning when comparing an int to a bytes object in Python 2. This will help when someone writes something like `b'abcd'[2] == b'c'` and it always returns False thanks to the indexing returning 99 in Python 3.

----------
assignee: brett.cannon
components: Interpreter Core
messages: 238228
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: Have -b warn when directly comparing ints and bytes
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23681>
_______________________________________

From report at bugs.python.org  Mon Mar 16 18:05:54 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 16 Mar 2015 17:05:54 +0000
Subject: [issue23681] Have -b warn when directly comparing ints and bytes
In-Reply-To: <1426525530.11.0.0814957947674.issue23681@psf.upfronthosting.co.za>
Message-ID: <1426525554.51.0.458865050572.issue23681@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
versions: +Python 3.5 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23681>
_______________________________________

From report at bugs.python.org  Mon Mar 16 18:06:00 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 16 Mar 2015 17:06:00 +0000
Subject: [issue23681] Have -b warn when directly comparing ints and bytes
In-Reply-To: <1426525530.11.0.0814957947674.issue23681@psf.upfronthosting.co.za>
Message-ID: <1426525560.69.0.494192004878.issue23681@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: normal -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23681>
_______________________________________

From report at bugs.python.org  Mon Mar 16 18:06:10 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 16 Mar 2015 17:06:10 +0000
Subject: [issue23681] Have -b warn when directly comparing ints and bytes
In-Reply-To: <1426525530.11.0.0814957947674.issue23681@psf.upfronthosting.co.za>
Message-ID: <1426525570.08.0.935269123904.issue23681@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23681>
_______________________________________

From report at bugs.python.org  Mon Mar 16 18:07:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Mar 2015 17:07:42 +0000
Subject: [issue23680] Sporadic freeze in test_interrupted_write_retry_text
In-Reply-To: <1426521207.32.0.580722848653.issue23680@psf.upfronthosting.co.za>
Message-ID: <20150316170347.23888.43911@psf.io>


Roundup Robot added the comment:

New changeset 10acab2d4a88 by Victor Stinner in branch 'default':
Issue #23680: Reduce risk of race condition in check_interrupted_write() of
https://hg.python.org/cpython/rev/10acab2d4a88

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23680>
_______________________________________

From report at bugs.python.org  Mon Mar 16 18:28:07 2015
From: report at bugs.python.org (mogli)
Date: Mon, 16 Mar 2015 17:28:07 +0000
Subject: [issue23679] SSL Ciphers RC4
In-Reply-To: <1426505465.73.0.583137037383.issue23679@psf.upfronthosting.co.za>
Message-ID: <1426526887.44.0.886407986198.issue23679@psf.upfronthosting.co.za>


mogli added the comment:

So it seems the docs are wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23679>
_______________________________________

From report at bugs.python.org  Mon Mar 16 18:33:06 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 16 Mar 2015 17:33:06 +0000
Subject: [issue23679] SSL Ciphers RC4
In-Reply-To: <1426505465.73.0.583137037383.issue23679@psf.upfronthosting.co.za>
Message-ID: <1426527186.89.0.990237844421.issue23679@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

They're correct for the next release. :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23679>
_______________________________________

From report at bugs.python.org  Mon Mar 16 18:40:40 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Mar 2015 17:40:40 +0000
Subject: [issue23679] SSL Ciphers RC4
In-Reply-To: <1426505465.73.0.583137037383.issue23679@psf.upfronthosting.co.za>
Message-ID: <1426527640.99.0.326016832985.issue23679@psf.upfronthosting.co.za>


R. David Murray added the comment:

But the doc explicitly says 2.7.9, so no, they are not correct.  There also should be versionchanged directive, I think.

----------
assignee:  -> docs at python
components: +Documentation
dependencies:  -SSL module should not offer RC4 based cipher suites for clients by default
nosy: +docs at python, r.david.murray
stage:  -> needs patch
status: closed -> open
type: security -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23679>
_______________________________________

From report at bugs.python.org  Mon Mar 16 18:40:51 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Mar 2015 17:40:51 +0000
Subject: [issue23679] SSL Ciphers RC4
In-Reply-To: <1426505465.73.0.583137037383.issue23679@psf.upfronthosting.co.za>
Message-ID: <1426527651.17.0.965160023258.issue23679@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution: duplicate -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23679>
_______________________________________

From report at bugs.python.org  Mon Mar 16 18:42:38 2015
From: report at bugs.python.org (Mark Hughes)
Date: Mon, 16 Mar 2015 17:42:38 +0000
Subject: [issue22931] cookies with square brackets in value
In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za>
Message-ID: <1426527758.5.0.625332811258.issue22931@psf.upfronthosting.co.za>


Mark Hughes added the comment:

We experimented with a version of the patch for 2.7.9. 

One issue we immediately noticed is that even though disallowed by the spec the use of commas in cookie values is widespread so we needed to add \, to the _LEGAL_VALUES_PATT.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22931>
_______________________________________

From report at bugs.python.org  Mon Mar 16 18:45:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Mar 2015 17:45:38 +0000
Subject: [issue23679] SSL Ciphers RC4
In-Reply-To: <1426505465.73.0.583137037383.issue23679@psf.upfronthosting.co.za>
Message-ID: <20150316174535.30194.49061@psf.io>


Roundup Robot added the comment:

New changeset e1dfa5f0709f by Benjamin Peterson in branch '2.7':
versionchanged for rc4 removal (closes #23679)
https://hg.python.org/cpython/rev/e1dfa5f0709f

New changeset 2a6a63828a40 by Benjamin Peterson in branch '3.4':
versionchanged for rc4 removal (closes #23679)
https://hg.python.org/cpython/rev/2a6a63828a40

New changeset 87c102d0df39 by Benjamin Peterson in branch 'default':
merge 3.4 (#23679)
https://hg.python.org/cpython/rev/87c102d0df39

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23679>
_______________________________________

From report at bugs.python.org  Mon Mar 16 18:59:28 2015
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Mar 2015 17:59:28 +0000
Subject: [issue23673] IntEnum is unpicklable by previous Python versions
In-Reply-To: <1426432245.83.0.265780672947.issue23673@psf.upfronthosting.co.za>
Message-ID: <1426528768.02.0.935733833961.issue23673@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Patch adds Enum._convert which is a class method that handles:

  - creating the new Enum
  - adding the appropriate members
  - adding the new Enum to the module's namespace (which is a passed parameter)
  - replacing the __reduce_ex__ method to return just the member's name

The change to Enum is:

    @classmethod
    def _convert(cls, name, module, filter, source=None):
        """
        Create a new Enum subclass that replaces a collection of global constants
        """
        # convert all constants from source (or module) that pass filter() to
        # a new Enum called name, and export the enum and its members back to
        # module;
        # also, replace the __reduce_ex__ method so unpickling works in
        # previous Python versions
        module_globals = vars(sys.modules[module])
        if source:
            source = vars(source)
        else:
            source = module_globals
        members = {name: value for name, value in source.items()
                if filter(name)}
        cls = cls(name, members, module=module)
        cls.__reduce_ex__ = _reduce_ex_by_name
        module_globals.update(cls.__members__)
        module_globals[name] = cls
        return cls

In use it looks like:

   IntEnum._convert(
        'AddressFamily',
        __name__,
        lambda C: C.isupper() and C.startswith('AF_'))

or

  _IntEnum._convert(
        '_SSLMethod', __name__,
        lambda name: name.startswith('PROTOCOL_'),
        source=_ssl)


ssl.py, socket.py, signal.py, and http/__init__.py have been updated to use this method.

----------
keywords: +patch
stage: test needed -> patch review
Added file: http://bugs.python.org/file38510/issue23673.stoneleaf.01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23673>
_______________________________________

From report at bugs.python.org  Mon Mar 16 19:04:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Mar 2015 18:04:00 +0000
Subject: [issue23681] Have -b warn when directly comparing ints and bytes
In-Reply-To: <1426525530.11.0.0814957947674.issue23681@psf.upfronthosting.co.za>
Message-ID: <1426529040.83.0.104626314533.issue23681@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

6 tests failed:
    test_buffer test_poplib test_quopri test_smtpd test_sunau
    test_tokenize

And all of them look as bugs.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23681>
_______________________________________

From report at bugs.python.org  Mon Mar 16 19:39:01 2015
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 16 Mar 2015 18:39:01 +0000
Subject: =?utf-8?q?=5Bissue22625=5D_When_cross-compiling=2C_don=E2=80=99t_try_to_e?=
 =?utf-8?q?xecute_binaries?=
In-Reply-To: <1413226219.68.0.732560661241.issue22625@psf.upfronthosting.co.za>
Message-ID: <1426531141.24.0.0675949112922.issue22625@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22625>
_______________________________________

From report at bugs.python.org  Mon Mar 16 20:03:34 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 Mar 2015 19:03:34 +0000
Subject: [issue23681] Have -b warn when directly comparing ints and bytes
In-Reply-To: <1426525530.11.0.0814957947674.issue23681@psf.upfronthosting.co.za>
Message-ID: <1426532614.91.0.492434961602.issue23681@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that adds required feature and fixes existing bugs in the stdlib and tests.

No one of failed tests was false positive.

----------
keywords: +patch
stage: test needed -> patch review
Added file: http://bugs.python.org/file38511/bytes_to_int_compare.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23681>
_______________________________________

From report at bugs.python.org  Mon Mar 16 20:29:17 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Mon, 16 Mar 2015 19:29:17 +0000
Subject: [issue23681] Have -b warn when directly comparing ints and bytes
In-Reply-To: <1426525530.11.0.0814957947674.issue23681@psf.upfronthosting.co.za>
Message-ID: <1426534157.5.0.52923380398.issue23681@psf.upfronthosting.co.za>


Changes by Claudiu Popa <pcmanticore at gmail.com>:


----------
nosy: +Claudiu.Popa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23681>
_______________________________________

From report at bugs.python.org  Mon Mar 16 20:56:52 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 16 Mar 2015 19:56:52 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1426535812.75.0.757285891666.issue23571@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: commit review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Mon Mar 16 21:32:55 2015
From: report at bugs.python.org (Martin Sekera)
Date: Mon, 16 Mar 2015 20:32:55 +0000
Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces
In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za>
Message-ID: <1426537975.34.0.778929010503.issue23441@psf.upfronthosting.co.za>


Martin Sekera added the comment:

Copy that. Would the patch be acceptable if the '\t' was simply changed to 4 spaces?

To discuss further, it is my opinion that the interpreter should output a \t character when the TAB key is pressed, as this is the behavior of nearly every shell and interpreter (that doesn't autocomplete all the time) there is, including all versions of python. Introducing new behavior for the sake of compliance with PEP 8 (which, as it itself states, applies only to "the Python code comprising the standard library in the main Python distribution"), is in my opinion unnecessary and confusing (since to clear n indent levels the user has to backspace 4n times).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23441>
_______________________________________

From report at bugs.python.org  Mon Mar 16 21:39:08 2015
From: report at bugs.python.org (Dan Stromberg)
Date: Mon, 16 Mar 2015 20:39:08 +0000
Subject: [issue23397] PEP 431 implementation
In-Reply-To: <1423124685.79.0.871732052041.issue23397@psf.upfronthosting.co.za>
Message-ID: <1426538348.25.0.815314151546.issue23397@psf.upfronthosting.co.za>


Changes by Dan Stromberg <strombrg at gmail.com>:


----------
nosy: +strombrg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23397>
_______________________________________

From report at bugs.python.org  Mon Mar 16 22:00:03 2015
From: report at bugs.python.org (Lennart Regebro)
Date: Mon, 16 Mar 2015 21:00:03 +0000
Subject: [issue23397] PEP 431 implementation
In-Reply-To: <1423124685.79.0.871732052041.issue23397@psf.upfronthosting.co.za>
Message-ID: <1426539603.89.0.539278476521.issue23397@psf.upfronthosting.co.za>


Lennart Regebro added the comment:

FYI me and Berker started over here: https://bitbucket.org/regebro/cpython

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23397>
_______________________________________

From report at bugs.python.org  Mon Mar 16 22:22:56 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Mar 2015 21:22:56 +0000
Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces
In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za>
Message-ID: <1426540976.54.0.925662977486.issue23441@psf.upfronthosting.co.za>


R. David Murray added the comment:

No program that I work with (and I use cli all the time) outputs a tab when I press the tab key.  Now, true, I think I had to configure vi so that that was the case, but nothing else that I remember.  Of course, most of those programs use readline and come with some sort of configuration such as what we are (belatedly) supply in python's command line.  So, to me, outputting an actual tab character would be *less* consistent with my general (modern) computing experience.  Especially since we are, in fact, talking about python now doing "autocomplete all the time" :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23441>
_______________________________________

From report at bugs.python.org  Mon Mar 16 22:32:46 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 16 Mar 2015 21:32:46 +0000
Subject: [issue23682] distutils docs still talk about compatibility with
 Python 2.2
Message-ID: <1426541566.7.0.328522056183.issue23682@psf.upfronthosting.co.za>


New submission from Thomas Kluyver:

I'm pretty sure the distutils docs for Python 3.4 don't need to describe how to make packages compatible with Python < 2.2.3.

I know that these docs are deprecated in favour of the Python packaging guide, but I still look at them at times, and this is embarrassing.

----------
assignee: docs at python
components: Documentation
files: dont-mention-py22.patch
keywords: patch
messages: 238241
nosy: docs at python, takluyver
priority: normal
severity: normal
status: open
title: distutils docs still talk about compatibility with Python 2.2
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38512/dont-mention-py22.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23682>
_______________________________________

From report at bugs.python.org  Mon Mar 16 22:39:39 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 16 Mar 2015 21:39:39 +0000
Subject: [issue11726] clarify that linecache only works on files that can be
 decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <1426541979.67.0.883494378889.issue11726@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Anything else I should be doing here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11726>
_______________________________________

From report at bugs.python.org  Mon Mar 16 22:46:59 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 16 Mar 2015 21:46:59 +0000
Subject: [issue23657] Don't do isinstance checks in zipapp
In-Reply-To: <1426258210.85.0.503105299924.issue23657@psf.upfronthosting.co.za>
Message-ID: <1426542419.37.0.899930309553.issue23657@psf.upfronthosting.co.za>


Paul Moore added the comment:

Updated version of the patch with tests, plus doc update noting that path objects are explicitly supported.

----------
Added file: http://bugs.python.org/file38513/duck_typed_zipapp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23657>
_______________________________________

From report at bugs.python.org  Mon Mar 16 22:49:50 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 16 Mar 2015 21:49:50 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_g++_module_compile_fails_with_=E2=80=98=5FAtom?=
 =?utf-8?q?ic=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426542590.2.0.377909880949.issue23644@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

So use std::memory_order_relaxed, std::memory_order_acquire etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Mon Mar 16 22:53:50 2015
From: report at bugs.python.org (Martin Sekera)
Date: Mon, 16 Mar 2015 21:53:50 +0000
Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces
In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za>
Message-ID: <1426542830.6.0.564388792962.issue23441@psf.upfronthosting.co.za>


Martin Sekera added the comment:

In the end it doesn't matter what characters end up on the terminal. What matters is the UX of not having to press backspace several times to unindent. That's sloppy design.

The issue of forcing a custom indent width on a user who might have their tab stops setup differently is another, albeit smaller, issue. I think the interpreter has absolutely no reason to do what's basically UI work (aligning tabbed text with tab-stop columns as in the first patch). That's the terminal's job.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23441>
_______________________________________

From report at bugs.python.org  Mon Mar 16 23:07:30 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 16 Mar 2015 22:07:30 +0000
Subject: [issue22852] urllib.parse wrongly strips empty #fragment
In-Reply-To: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za>
Message-ID: <1426543650.75.0.796896034366.issue22852@psf.upfronthosting.co.za>


Martin Panter added the comment:

## Inferring flags ##

The whole reason for the has_netloc etc flags is that I don?t think we can always infer their values, so we have to explicitly remember them. Consider the following two URLs, which I think should both have empty ?netloc? strings for backwards compatibility, but should be handled differently by urlunsplit():

>>> urlsplit("////evil.com").netloc
''
>>> urlsplit("////evil.com").has_netloc
True
>>> urlunsplit(urlsplit("////evil.com"))  # Adds ?//? back
'////evil.com'
>>> urlsplit("/normal/path").netloc
''
>>> urlsplit("/normal/path").has_netloc
False
>>> urlunsplit(urlsplit("/normal/path"))  # Does not add ?//?
'/normal/path'

## _NetlocResultMixinBase abuse ##

The _NetlocResultMixinBase class is a common class used by the four result classes I?m interested in. I probably should rename it to something like _SplitParseMixinBase, since it is the common base to both urlsplit() and urlparse() results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22852>
_______________________________________

From report at bugs.python.org  Mon Mar 16 23:09:09 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 16 Mar 2015 22:09:09 +0000
Subject: [issue23682] distutils docs still talk about compatibility with
 Python 2.2
In-Reply-To: <1426541566.7.0.328522056183.issue23682@psf.upfronthosting.co.za>
Message-ID: <1426543749.82.0.717191020054.issue23682@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I also removed it in my patch for issue 19610.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23682>
_______________________________________

From report at bugs.python.org  Mon Mar 16 23:14:23 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 16 Mar 2015 22:14:23 +0000
Subject: [issue23682] distutils docs still talk about compatibility with
 Python 2.2
In-Reply-To: <1426541566.7.0.328522056183.issue23682@psf.upfronthosting.co.za>
Message-ID: <1426544063.08.0.593490040016.issue23682@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
assignee: docs at python -> berker.peksag
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23682>
_______________________________________

From report at bugs.python.org  Mon Mar 16 23:17:38 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 16 Mar 2015 22:17:38 +0000
Subject: [issue17911] traceback: add a new thin class storing a traceback
 without storing local variables
In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za>
Message-ID: <1426544258.53.0.722964596694.issue17911@psf.upfronthosting.co.za>


Robert Collins added the comment:

Regression fixed AFAICT, please re-open if not.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17911>
_______________________________________

From report at bugs.python.org  Mon Mar 16 23:48:25 2015
From: report at bugs.python.org (Shakeel Mohamed)
Date: Mon, 16 Mar 2015 22:48:25 +0000
Subject: [issue23542] Update PEP 476 for using urllib2.build_opener()
In-Reply-To: <1425069828.0.0.476725699175.issue23542@psf.upfronthosting.co.za>
Message-ID: <1426546105.68.0.817465200459.issue23542@psf.upfronthosting.co.za>


Shakeel Mohamed added the comment:

Hi, any plans to do this? If not, we can close it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23542>
_______________________________________

From report at bugs.python.org  Tue Mar 17 00:59:37 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 16 Mar 2015 23:59:37 +0000
Subject: [issue23529] Limit decompressed data when reading from LZMAFile and
 BZ2File
In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za>
Message-ID: <1426550377.32.0.0173453916865.issue23529@psf.upfronthosting.co.za>


Martin Panter added the comment:

Posting LZMAFile-etc.v5.patch with the following changes:

* Merged with current code
* Changed BZ2File(buffer_size=...) to a keyword-only parameter and restored previous unused ?buffering? parameter. Also changed the LZMAFile parameter to keyword-only for consistency.
* Dropped documenting how buffer_size affects the compressed data chunk size or the fast-forward chunk size for seeking
* Dropped backslash from \* in function signatures
* Documented and tested that buffer_size=0 is not valid for the LZMAFile etc classes
* Clarified a few code comments

There is still Nikolaus?s concern about setting the buffer size to zero and doing short reads, discussed on Rietveld. Apart from that, I think this patch addresses the rest of the comments. Let me know if I missed something!

----------
Added file: http://bugs.python.org/file38514/LZMAFile-etc.v5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23529>
_______________________________________

From report at bugs.python.org  Tue Mar 17 01:46:41 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 17 Mar 2015 00:46:41 +0000
Subject: [issue22852] urllib.parse wrongly strips empty #fragment
In-Reply-To: <1426543650.75.0.796896034366.issue22852@psf.upfronthosting.co.za>
Message-ID: <C6114173-8BBA-42C4-897F-30839C22C7EF@gmail.com>


Demian Brecht added the comment:

>>>> urlsplit("////evil.com").netloc
> ''
>>>> urlsplit("////evil.com").has_netloc
> True
>>>> urlunsplit(urlsplit("////evil.com"))  # Adds ?//? back
> '////evil.com'

RFC 3986, section 3.3:

   If a URI contains an authority component, then the path component
   must either be empty or begin with a slash ("/") character.  If a URI
   does not contain an authority component, then the path cannot begin
   with two slash characters ("//").

Because this is a backwards incompatible behavioural change and is just as invalid as far as the RFC goes, I think that the current behaviour should be preserved. Even though it's still incorrect, it won't break existing code if left unchanged.

> ## _NetlocResultMixinBase abuse ##
> 
> The _NetlocResultMixinBase class is a common class used by the four result classes I?m interested in. I probably should rename it to something like _SplitParseMixinBase, since it is the common base to both urlsplit() and urlparse() results.

I think I'm coming around to this and realizing that it's actually quite close to my proposal, the major difference being the additional level of hierarchy in mine. My issue was mostly due to the addition of the variadic signature in the docs (i.e. line 407 here: http://bugs.python.org/review/22852/diff/14176/Doc/library/urllib.parse.rst) which led me to believe a nonsensical signature would be valid. After looking at it again, __new__ is still bound to the tuple's signature, so you still get the following:

>>> SplitResult('scheme','authority','path','query','fragment','foo','bar','baz')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Volumes/src/p/cpython/Lib/urllib/parse.py", line 137, in __new__
    self = super().__new__(type, *pos, **kw)
TypeError: __new__() takes 6 positional arguments but 9 were given

So I'm less opposed to this as-is. I would like to see the "*" removed from the docs though as it's misleading in the context of each of (Split|Parse)Result. I do agree that renaming _NetlocResultMixinBase would be helpful, but it might also be nice (from a pedant's point of view) to remove "mixin" altogether if the __new__ implementation stays as-is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22852>
_______________________________________

From report at bugs.python.org  Tue Mar 17 01:47:44 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 00:47:44 +0000
Subject: [issue23683] allow timeit to run expensive reset code per repeats
Message-ID: <1426553264.53.0.0690817239564.issue23683@psf.upfronthosting.co.za>


New submission from Robert Collins:

I was timing some cold-cache operations today and had to not use timeit because I wanted to run some code between statement (flushing caches) that shouldn't be timed as part of statement. It would be nice, similarly to -s, to be able to say -i 'something run between statement repetitions'. That is - we run statement in a tight loop some N times, and then repeat that loop some R times, I'd like to run the -i code between the R repetitions, not inside the inner timing loop (since we run that to get timer resolution).

----------
messages: 238252
nosy: rbcollins
priority: normal
severity: normal
status: open
title: allow timeit to run expensive reset code per repeats
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23683>
_______________________________________

From report at bugs.python.org  Tue Mar 17 02:39:42 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 Mar 2015 01:39:42 +0000
Subject: [issue23684] urlparse() documentation does not account for default
 scheme
Message-ID: <1426556382.03.0.776976224321.issue23684@psf.upfronthosting.co.za>


New submission from Martin Panter:

The documentation for urlsplit() says:

'''
urlparse(urlstring, scheme='', allow_fragments=True)

. . .

If the scheme argument is specified, it gives the default addressing scheme, to be used only if the URL does not specify one. The default value for this argument is the empty string.
'''

However this contradicts the table of attributes, which gives:

Attribute: scheme, . . . Value if not present: empty string

Similarly for urlsplit(). Of course, the description of the ?scheme? parameter is correct, and the table is only correct when no ?scheme? parameter is given:

>>> urlparse("//example.net").scheme
''
>>> urlparse(b"//example.net").scheme
b''
>>> urlparse("//example.net", "http").scheme
'http'

This issue is split off another where I tried to sneak in a quick fix, but the wording probably needs more thought. Original change: <https://bugs.python.org/review/22852/patch/14176/52720#old-line-92>.

Maybe change it to this?

Value if not present: empty string or default scheme

----------
assignee: docs at python
components: Documentation
messages: 238253
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: urlparse() documentation does not account for default scheme

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23684>
_______________________________________

From report at bugs.python.org  Tue Mar 17 03:01:15 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 Mar 2015 02:01:15 +0000
Subject: [issue22891] code removal from urllib.parse.urlsplit()
In-Reply-To: <1416220944.83.0.361625539874.issue22891@psf.upfronthosting.co.za>
Message-ID: <1426557675.42.0.970738101658.issue22891@psf.upfronthosting.co.za>


Martin Panter added the comment:

The patch seems sensible. The only behaviour change I can forsee would be the odd case of http:1234 no longer being parsed like this:

>>> urlsplit("http:1234")
SplitResult(scheme='http', netloc='', path='1234', query='', fragment='')

Instead it would be parsed the same as HTTP:1234 (or tel:1234!):

>>> urlsplit("HTTP:1234")
SplitResult(scheme='', netloc='', path='HTTP:1234', query='', fragment='')

If optimizing for ?http:? really is important, it might still be done without the code duplication. Other options might be factoring a subroutine, using str.strip(), set.issubset(), or regular expressions.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22891>
_______________________________________

From report at bugs.python.org  Tue Mar 17 03:09:14 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 Mar 2015 02:09:14 +0000
Subject: [issue22852] urllib.parse wrongly strips empty #fragment
In-Reply-To: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za>
Message-ID: <1426558154.54.0.85868842335.issue22852@psf.upfronthosting.co.za>


Martin Panter added the comment:

Regarding unparsing of "////evil.com", see Issue 23505, where the invalid behaviour is pointed out as a security issue. This was one of the bugs that motivated me to make this patch. I cannot imagine some existing code (other than an exploit) that would be broken by restoring the empty ?//? component; do you have an example?

Why do you think the asterisks (*) in the Split/ParseResult signatures are misleading? I am trying to document that the has_ flags are keyword-only parameters. I avoided making them positional parameters, as they are not part of the underlying tuple object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22852>
_______________________________________

From report at bugs.python.org  Tue Mar 17 03:42:19 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 Mar 2015 02:42:19 +0000
Subject: [issue22351] NNTP constructor exception leaves socket for garbage
 collector
In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za>
Message-ID: <1426560139.75.0.360694216439.issue22351@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for reviewing, Serhiy. I am posting a new patch addressing the comments:

* Removed underscore from method name
* Made separate MockSslTests subclass, using a hacked ssl_context parameter to bypass the SSL module
* Separated asserts for closed socket and file objects

I have left the tests patching the ?nntplib? module and inserting a mock ?socket? module. Serhiy suggested patching the ?socket? module directly, but that seems to be asking for trouble. Alternatives I can think of are:

* Go back to Rishi?s original code that uses a real socket in a background thread.
* Do the patching in a subprocess. But this is awkward if you want to reuse the existing NNTPv1Handler class in the subprocess. Suggestions or patches welcome :)
* Refactor the ?nntplib? code specially to make it easier to test without a real socket and without patching

----------
Added file: http://bugs.python.org/file38515/issue22351_nntp_fail_5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22351>
_______________________________________

From report at bugs.python.org  Tue Mar 17 04:07:06 2015
From: report at bugs.python.org (Samuel Bronson)
Date: Tue, 17 Mar 2015 03:07:06 +0000
Subject: [issue11410] Use GCC visibility attrs in PyAPI_*
In-Reply-To: <1299391945.72.0.037942723875.issue11410@psf.upfronthosting.co.za>
Message-ID: <1426561626.46.0.457711253653.issue11410@psf.upfronthosting.co.za>


Samuel Bronson added the comment:

Um ... any progress on reviewing this?

----------
nosy: +SamB

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11410>
_______________________________________

From report at bugs.python.org  Tue Mar 17 05:13:54 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 17 Mar 2015 04:13:54 +0000
Subject: [issue22852] urllib.parse wrongly strips empty #fragment
In-Reply-To: <1426558154.54.0.85868842335.issue22852@psf.upfronthosting.co.za>
Message-ID: <5DDBD499-8698-42D8-9AE4-966AC67FF62D@gmail.com>


Demian Brecht added the comment:

> I avoided making them positional parameters, as they are not part of the underlying tuple object.

Ignore me, I was off my face and you're absolutely correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22852>
_______________________________________

From report at bugs.python.org  Tue Mar 17 05:56:06 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Mar 2015 04:56:06 +0000
Subject: [issue23682] distutils docs still talk about compatibility with
 Python 2.2
In-Reply-To: <1426541566.7.0.328522056183.issue23682@psf.upfronthosting.co.za>
Message-ID: <20150317045603.7239.96127@psf.io>


Roundup Robot added the comment:

New changeset 910a7a540a31 by Berker Peksag in branch '3.4':
Issue #23682: Delete Python 2.2 mention from distutils documentation.
https://hg.python.org/cpython/rev/910a7a540a31

New changeset 7757e98a9f3b by Berker Peksag in branch 'default':
Issue #23682: Delete Python 2.2 mention from distutils documentation.
https://hg.python.org/cpython/rev/7757e98a9f3b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23682>
_______________________________________

From report at bugs.python.org  Tue Mar 17 05:56:55 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 17 Mar 2015 04:56:55 +0000
Subject: [issue23682] distutils docs still talk about compatibility with
 Python 2.2
In-Reply-To: <1426541566.7.0.328522056183.issue23682@psf.upfronthosting.co.za>
Message-ID: <1426568215.31.0.511612597328.issue23682@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks Thomas!

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23682>
_______________________________________

From report at bugs.python.org  Tue Mar 17 06:01:19 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 17 Mar 2015 05:01:19 +0000
Subject: [issue23681] Have -b warn when directly comparing ints and bytes
In-Reply-To: <1426525530.11.0.0814957947674.issue23681@psf.upfronthosting.co.za>
Message-ID: <1426568479.68.0.202000405322.issue23681@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> [...] fixes existing bugs in the stdlib and tests.

These changes should probably be backported to 3.4.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23681>
_______________________________________

From report at bugs.python.org  Tue Mar 17 07:31:13 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 Mar 2015 06:31:13 +0000
Subject: [issue22233] http.client splits headers on none-\r\n characters
In-Reply-To: <1408528953.84.0.772180232607.issue22233@psf.upfronthosting.co.za>
Message-ID: <1426573873.28.0.125344763878.issue22233@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22233>
_______________________________________

From report at bugs.python.org  Tue Mar 17 07:40:32 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 Mar 2015 06:40:32 +0000
Subject: [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1426574432.11.0.40236603628.issue12855@psf.upfronthosting.co.za>


Martin Panter added the comment:

Note to self, or anyone else handling this patch: See <https://bugs.python.org/issue22232#msg225769> for further improvement ideas:

* Might be good to bring back the reference to universal newlines, but say it accepts additional line boundaries
* Terry also suggested a doc string improvement

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Tue Mar 17 07:42:25 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 Mar 2015 06:42:25 +0000
Subject: [issue22232] str.splitlines splitting on non-\r\n characters
In-Reply-To: <1408528911.37.0.452679392827.issue22232@psf.upfronthosting.co.za>
Message-ID: <1426574545.21.0.143809045411.issue22232@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22232>
_______________________________________

From report at bugs.python.org  Tue Mar 17 07:42:32 2015
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Tue, 17 Mar 2015 06:42:32 +0000
Subject: [issue23624] str.center inconsistent with format "^"
In-Reply-To: <1425966835.2.0.36838695627.issue23624@psf.upfronthosting.co.za>
Message-ID: <1426574552.64.0.482602225353.issue23624@psf.upfronthosting.co.za>


Vedran ?a?i? added the comment:

Only one detail to resolve: you say "format is quite capable of handing a variable width field".

It does, but not in a really nice way. Honestly, would you really rather see

    "{:^{}}".format(title, width)

than

    title.center(width)

? Nested formats are ugly, I think that's a consensus. :-) Not to mention that .center is more explicit about what's going on - that "^" is almost lost in that brace-forest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23624>
_______________________________________

From report at bugs.python.org  Tue Mar 17 07:54:34 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 17 Mar 2015 06:54:34 +0000
Subject: [issue22852] urllib.parse wrongly strips empty #fragment
In-Reply-To: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za>
Message-ID: <1426575274.18.0.0926851371468.issue22852@psf.upfronthosting.co.za>


Demian Brecht added the comment:

> I cannot imagine some existing code (other than an exploit) that would be broken by restoring the empty ?//? component; do you have an example?

You're likely right about the usage (I can't think of a plausible use case at any rate).

At first read of #23505, I think I agree with the changes you've made to allow for successful round-tripping, but I'd think it'll have to be vetted by at least more than one core dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22852>
_______________________________________

From report at bugs.python.org  Tue Mar 17 09:41:39 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 17 Mar 2015 08:41:39 +0000
Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable
 (on POSIX)
In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za>
Message-ID: <1426581699.97.0.744347019432.issue23458@psf.upfronthosting.co.za>


Ned Deily added the comment:

FD_CLOEXEC is first support on OS X 10.5.  Here's a patch to skip the test on earlier systems: tested on 10.4, 10.5, and 10.10.

----------
nosy: +ned.deily
stage:  -> commit review
Added file: http://bugs.python.org/file38516/issue23458_tiger.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23458>
_______________________________________

From report at bugs.python.org  Tue Mar 17 10:21:12 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 09:21:12 +0000
Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable
 (on POSIX)
In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za>
Message-ID: <1426584072.25.0.473637681159.issue23458@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ned Deily added the comment:
> FD_CLOEXEC is first support on OS X 10.5.  Here's a patch to skip the test on earlier systems: tested on 10.4, 10.5, and 10.10.

What do you mean by "first support"? Does it mean that fcntl(fd, F_SETFD, FD_CLOEXEC) is simply a no-op?

Does Python 3.4 with the PEP 446 works on OS X 10.4? Can you test the following example?

Python 3.4.1 (default, Nov  3 2014, 14:38:10)
[GCC 4.9.1 20140930 (Red Hat 4.9.1-11)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> fd=os.open('.', os.O_RDONLY)
>>> os.get_inheritable(fd)
False
>>> os.set_inheritable(fd, True)
>>> os.get_inheritable(fd)
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23458>
_______________________________________

From report at bugs.python.org  Tue Mar 17 10:31:09 2015
From: report at bugs.python.org (Thomas Guettler)
Date: Tue, 17 Mar 2015 09:31:09 +0000
Subject: [issue23625] load_module() docs: zipped eggs are not loaded.
In-Reply-To: <1425986086.94.0.227506635369.issue23625@psf.upfronthosting.co.za>
Message-ID: <1426584669.72.0.839928433388.issue23625@psf.upfronthosting.co.za>


Thomas Guettler added the comment:

In this case I am wearing newbee user glasses.

And with this glasses on my nose, I don't care for implementation.

I am confused that imp module does not work like "import foo".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23625>
_______________________________________

From report at bugs.python.org  Tue Mar 17 10:37:14 2015
From: report at bugs.python.org (mogli)
Date: Tue, 17 Mar 2015 09:37:14 +0000
Subject: [issue23679] SSL Ciphers RC4
In-Reply-To: <1426505465.73.0.583137037383.issue23679@psf.upfronthosting.co.za>
Message-ID: <1426585034.01.0.24106937629.issue23679@psf.upfronthosting.co.za>


mogli added the comment:

That was fast, great job!

For the record: The SSLv3 issue I also wrote about was a false positive because the test only works with Javascript. Python 2.7.9 has SSLv3 disabled by default as it should.

urllib2.urlopen("https://sslv3.dshield.org")  # fails as it should

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23679>
_______________________________________

From report at bugs.python.org  Tue Mar 17 10:50:12 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Mar 2015 09:50:12 +0000
Subject: [issue23646] PEP 475: handle EINTR in the time module, retry sleep()
In-Reply-To: <1426174662.68.0.293958221956.issue23646@psf.upfronthosting.co.za>
Message-ID: <20150317095009.24260.490@psf.io>


Roundup Robot added the comment:

New changeset 4accc35cbfcf by Victor Stinner in branch 'default':
Revert changeset d927047b1d8eb87738676980a24930d053ba2150
https://hg.python.org/cpython/rev/4accc35cbfcf

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23646>
_______________________________________

From report at bugs.python.org  Tue Mar 17 10:52:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 09:52:08 +0000
Subject: [issue23646] PEP 475: handle EINTR in the time module, retry sleep()
In-Reply-To: <1426174662.68.0.293958221956.issue23646@psf.upfronthosting.co.za>
Message-ID: <1426585928.3.0.0768447707675.issue23646@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I commited sleep_eintr.patch by mistake. After this change, test_socket started to fail on Windows. I don't understand why.

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/5836/steps/test/logs/stdio

======================================================================
ERROR: testClose (test.test_socket.TCPCloserTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_socket.py", line 3723, in testClose
    read, write, err = select.select([sd], [], [], 1.0)
TypeError: argument must be an int, or have a fileno() method.

======================================================================
FAIL: testRecv (test.test_socket.NonBlockingTCPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_socket.py", line 3883, in testRecv
    self.fail("Error trying to do non-blocking recv.")
AssertionError: Error trying to do non-blocking recv.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23646>
_______________________________________

From report at bugs.python.org  Tue Mar 17 11:05:02 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 17 Mar 2015 10:05:02 +0000
Subject: [issue23625] load_module() docs: zipped eggs are not loaded.
In-Reply-To: <1425986086.94.0.227506635369.issue23625@psf.upfronthosting.co.za>
Message-ID: <1426586702.33.0.77423709959.issue23625@psf.upfronthosting.co.za>


Paul Moore added the comment:

Egg files are a format defined by setuptools. If you look in the setuptools documentation it notes that egg files are simply zipfiles with a particular structure and naming convention. So from a core Python perspective, you can use eggs just like any other zipfile. See the zipimport documentation for further details if you need them.

To further confuse the issue, setuptools includes some pretty complex mechanisms for adding eggs to syst.path so that their contents can be imported (there are .pth files and multi-version support, for example). Those mechanisms are part of setuptools, not of core Python. From a core Python perspective, the path handling is something you do manually.

So while I understand your confusion, I think you should understand that it is a confusion over the setuptools implementation, and how it interacts with the mechanisms defined by core Python (which are defined in terms of zipfiles). So if you feel there are any documentation issues, they should probably be addressed by setuptools rather than in the core docs.

On a peripherally related point, your comment "zipped egg files in sys.path are not found" doesn't really explain your problem very well. When reporting to setuptools, I'd suggest that you need to clarify your problem a bit better - what steps did you take, did they match the steps that the setuptools docs tell you to use, and how did the failure show itself? But as I say, that's for a setuptools bug report.

----------
nosy: +paul.moore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23625>
_______________________________________

From report at bugs.python.org  Tue Mar 17 11:13:53 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 10:13:53 +0000
Subject: [issue23685] Fix usage of PyMODINIT_FUNC
Message-ID: <1426587233.23.0.965954561717.issue23685@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch fixes the usage of the PyMODINIT_FUNC macro.

My patch is based on Thomas Wouters's patch of the issue #11410.

I don't understand why Modules/pyexpat.c redefined PyMODINIT_FUNC if not defined. In which case PyMODINIT_FUNC was not defined?

I'm not sure that PC/config.c should use PyMODINIT_FUNC instead of use "PyObject*".

@Steve.Dower: Does my change to PC/config.c look correct or not?

----------
components: Build, Windows
files: PyMODINIT_FUNC.patch
keywords: patch
messages: 238272
nosy: haypo, loewis, pitrou, steve.dower, tim.golden, twouters, zach.ware
priority: normal
severity: normal
status: open
title: Fix usage of PyMODINIT_FUNC
versions: Python 3.5
Added file: http://bugs.python.org/file38517/PyMODINIT_FUNC.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23685>
_______________________________________

From report at bugs.python.org  Tue Mar 17 11:14:29 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 10:14:29 +0000
Subject: [issue11410] Use GCC visibility attrs in PyAPI_*
In-Reply-To: <1299391945.72.0.037942723875.issue11410@psf.upfronthosting.co.za>
Message-ID: <1426587269.97.0.650833340064.issue11410@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I extracted the changes on the PyMODINIT_FUNC macro and I opened the issue #23685.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11410>
_______________________________________

From report at bugs.python.org  Tue Mar 17 11:22:37 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 10:22:37 +0000
Subject: [issue11410] Use GCC visibility attrs in PyAPI_*
In-Reply-To: <1299391945.72.0.037942723875.issue11410@psf.upfronthosting.co.za>
Message-ID: <1426587757.77.0.196167810218.issue11410@psf.upfronthosting.co.za>


STINNER Victor added the comment:

+#if defined(__GNUC__) && __GNUC__ >= 4
+#       define HAVE_ATTRIBUTE_VISIBILITY
+#endif

Clang now also supports __attribute__((visibility("..."))). I don't know since which version.

I'm not sure because I don't see it:
http://clang.llvm.org/docs/AttributeReference.html

I see it there:
http://llvm.org/docs/LangRef.html#visibility-styles

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11410>
_______________________________________

From report at bugs.python.org  Tue Mar 17 11:25:04 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 10:25:04 +0000
Subject: [issue11410] Use GCC visibility attrs in PyAPI_*
In-Reply-To: <1299391945.72.0.037942723875.issue11410@psf.upfronthosting.co.za>
Message-ID: <1426587904.13.0.525433681796.issue11410@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The getargs.c change *is* necessary, although it doesn't have to be that exact change.

Why not moving these declarations to Include/modsupport.h where _PyArg_Parse...() are already used?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11410>
_______________________________________

From report at bugs.python.org  Tue Mar 17 11:37:55 2015
From: report at bugs.python.org (Thomas Guettler)
Date: Tue, 17 Mar 2015 10:37:55 +0000
Subject: [issue23625] load_module() docs: zipped eggs are not loaded.
In-Reply-To: <1425986086.94.0.227506635369.issue23625@psf.upfronthosting.co.za>
Message-ID: <1426588675.97.0.201855841171.issue23625@psf.upfronthosting.co.za>


Thomas Guettler added the comment:

The docs should be where new users look.

I don't speak about several hundret words ....

Where do you think new users look for documentation if they want a method which does find a module?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23625>
_______________________________________

From report at bugs.python.org  Tue Mar 17 12:13:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Mar 2015 11:13:28 +0000
Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate
 escaped strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1426590808.43.0.598474585118.issue18814@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I uploaded the patch just before your comment Nick.

Here is updated patch. Functions are renamed as Nick suggested, added two more functions: decompose_astrals() and compose_surrogate_pairs(). They are mainly for example here, they can be committed in other issue.

I hesitate about the rehandle_surrogatepass name. This function handles surrogates than can be created not only with the "surrogatepass" handler, but also with different ways, e.g. with the "surrogateescape" handler, with chr(), handle_astral() or decompose_astrals(). Actually it checks that the string is valid Unicode (not containing surrogates) and handle errors if found with specified error handler.

May be there is a time for wider discussion on Python-Dev. I especially want to hear opinions of Ezio and Martin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Tue Mar 17 12:17:01 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 11:17:01 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_g++_module_compile_fails_with_=E2=80=98=5FAtom?=
 =?utf-8?q?ic=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426591021.34.0.467516202745.issue23644@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hum, I'm lost with the problem with C++ :-( What is your use case? Do you want to compile CPython with C++? Or compile a third-party extension with C++ and this extension includes "Python.h" which includes "pyatomic.h".

For third-party code, pyatomic.h is only needed by PyThreadState_GET() in pystate.h. Maybe we should hide completly pyatomic.h. Currently, pyatomic.h is not really used if Py_LIMITED_API is defined.

By the way, can you try to compile the extension with Py_LIMITED_API? It should just work.


C++ 11 atomic:
---
#include <atomic>

int main()
{
    std::atomic_uintptr_t current;
    current.store(0, std::memory_order_relaxed);
    return 0;
}
---


C++ 11 atomic used with C functions:
---
#include <atomic>

int main()
{
    std::atomic<uintptr_t> current(0);
    std::atomic_store_explicit(&current, (uintptr_t)0, std::memory_order_relaxed);
    return 0;
}
---

I didn't find how to use std::atomic_store_explicit with std::atomic_uintptr_t, so I used std::atomic<uintptr_t> instead.

"std::atomic_store_explicit(&current, 0, std::memory_order_relaxed);" doesn't work: 0 must be explicitly cast to uintptr_t :-(

I tried to hack pyatomic.h to use std::atomic template: see attached pyatomic_cpp.patch.

But I don't understand: when PyThreadState_GET() is compiled in C++, should it use exactly the same functions of CPython (compiled with C)? It should be strange to to use a std::atomic C++ template to access an atomic C variable.

----------
Added file: http://bugs.python.org/file38518/pyatomic_cpp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Tue Mar 17 12:24:16 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 11:24:16 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_g++_module_compile_fails_with_=E2=80=98=5FAtom?=
 =?utf-8?q?ic=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426591456.43.0.985957441894.issue23644@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> For third-party code, pyatomic.h is only needed by PyThreadState_GET() in pystate.h. Maybe we should hide completly pyatomic.h. Currently, pyatomic.h is not really used if Py_LIMITED_API is defined.

pystate_cplusplus.patch: disable completly pyatomic.h on C++, and modify pystate.h: PyThreadState_GET() is just an alias to PyThreadState_Get() with compiled with C++.

IMO pystate_cplusplus.patch makes more sense.

I don't understand the purpose of atomicfix.patch or pyatomic_cpp.patch, PyThreadState_GET() will not work with these patches.

----------
Added file: http://bugs.python.org/file38519/pystate_cplusplus.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Tue Mar 17 12:29:42 2015
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 17 Mar 2015 11:29:42 +0000
Subject: [issue23686] Upgrade copy of OpenSSL bundled with Python
Message-ID: <1426591782.15.0.995555672449.issue23686@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

On Thursday OpenSSL will disclose some security issues and issue new releases: https://mta.openssl.org/pipermail/openssl-announce/2015-March/000020.html

When that happens, Python's that bundle an OpenSSL should be upgraded.

----------
keywords: security_issue
messages: 238280
nosy: alex
priority: normal
severity: normal
status: open
title: Upgrade copy of OpenSSL bundled with Python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23686>
_______________________________________

From report at bugs.python.org  Tue Mar 17 12:30:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Mar 2015 11:30:08 +0000
Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate
 escaped strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1426591808.92.0.426433945813.issue18814@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file38520/codecs_convert_escapes_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Tue Mar 17 12:36:37 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Mar 2015 11:36:37 +0000
Subject: [issue23115] Backport #22585 -- getentropy for urandom to Python 2.7
In-Reply-To: <1419610873.69.0.17447907262.issue23115@psf.upfronthosting.co.za>
Message-ID: <20150317113536.7239.89234@psf.io>


Roundup Robot added the comment:

New changeset 961efafe9497 by Ned Deily in branch '2.7':
Issue #22585, #23115: make URandomFDTests test case actually run
https://hg.python.org/cpython/rev/961efafe9497

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23115>
_______________________________________

From report at bugs.python.org  Tue Mar 17 12:36:37 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Mar 2015 11:36:37 +0000
Subject: [issue22585] os.urandom() should use getentropy() of OpenBSD 5.6
In-Reply-To: <1412846768.8.0.764206346975.issue22585@psf.upfronthosting.co.za>
Message-ID: <20150317113536.7239.47243@psf.io>


Roundup Robot added the comment:

New changeset 371deb4a5fd1 by Ned Deily in branch '3.4':
Issue #22585: make URandomFDTests test case actually run
https://hg.python.org/cpython/rev/371deb4a5fd1

New changeset c89f7c34e356 by Ned Deily in branch 'default':
Issue #22585: null merge
https://hg.python.org/cpython/rev/c89f7c34e356

New changeset 961efafe9497 by Ned Deily in branch '2.7':
Issue #22585, #23115: make URandomFDTests test case actually run
https://hg.python.org/cpython/rev/961efafe9497

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22585>
_______________________________________

From report at bugs.python.org  Tue Mar 17 12:42:36 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 17 Mar 2015 11:42:36 +0000
Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable
 (on POSIX)
In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za>
Message-ID: <1426592556.29.0.393055463001.issue23458@psf.upfronthosting.co.za>


Ned Deily added the comment:

$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.4.11
BuildVersion:	8S165
$ ./python
Python 3.4.3+ (3.4:910a7a540a31, Mar 17 2015, 03:33:01)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> fd=os.open('.', os.O_RDONLY)
>>> os.get_inheritable(fd)
False
>>> os.set_inheritable(fd, True)
>>> os.get_inheritable(fd)
True

But if I port test_urandom_fd_non_inheritable from 2.7, it fails on 3.4 as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23458>
_______________________________________

From report at bugs.python.org  Tue Mar 17 12:45:23 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 17 Mar 2015 11:45:23 +0000
Subject: [issue23686] Upgrade copy of OpenSSL bundled with Python
In-Reply-To: <1426591782.15.0.995555672449.issue23686@psf.upfronthosting.co.za>
Message-ID: <1426592723.99.0.019784730907.issue23686@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
components: +Build
nosy: +ned.deily, steve.dower, zach.ware
stage:  -> needs patch
versions: +Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23686>
_______________________________________

From report at bugs.python.org  Tue Mar 17 12:47:37 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 17 Mar 2015 11:47:37 +0000
Subject: [issue23686] Update Windows and OS X installer OpenSSL to 1.0.2a
In-Reply-To: <1426591782.15.0.995555672449.issue23686@psf.upfronthosting.co.za>
Message-ID: <1426592857.79.0.668171529929.issue23686@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
title: Upgrade copy of OpenSSL bundled with Python -> Update Windows and OS X installer OpenSSL to 1.0.2a

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23686>
_______________________________________

From report at bugs.python.org  Tue Mar 17 12:52:58 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 17 Mar 2015 11:52:58 +0000
Subject: [issue23593] Update Windows and OS X installer OpenSSL to 1.0.2
In-Reply-To: <1425589358.2.0.224433593674.issue23593@psf.upfronthosting.co.za>
Message-ID: <1426593178.15.0.558968065031.issue23593@psf.upfronthosting.co.za>


Ned Deily added the comment:

Superseded by Issue23686, OpenSSL 1.0.2a

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed
superseder:  -> Update Windows and OS X installer OpenSSL to 1.0.2a

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23593>
_______________________________________

From report at bugs.python.org  Tue Mar 17 13:18:58 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Mar 2015 12:18:58 +0000
Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate
 escaped strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1426594738.45.0.314347087639.issue18814@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I'd wondered about that with respect to rehandle_surrogatepass.

The current implementation looks like it processes *all* surrogates (even valid surrogate pairs), so "handle_surrogates" might be a suitable name.

If the intent is for it to be "handle_lone_surrogates", I'm not sure the current implementation achieves that, as a valid surrogate pair will match re.compile('[\ud800-\uefff]+').

The rest looks OK to me, including the decompose_astrals() and compose_surrogate_pairs() functions. Regardless of any practical utility, the latter two seem useful for *educational* purposes when it comes to unicode, by making it clear how to switch between the single code point and dual code point representations of the astrals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Tue Mar 17 13:22:21 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Mar 2015 12:22:21 +0000
Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate
 escaped strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1426594941.27.0.189904906141.issue18814@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Oh, and yes, I agree a python-dev discussion would be a good idea.

>From my perspective, "rehandle_surrogateescape" is the key function for making it easier to check for malformed input data from operating system interfaces.

The other items I don't personally have a use case for, but they seem potentially valuable in make some key Unicode concepts a bit more discoverable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Tue Mar 17 13:28:54 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Mar 2015 12:28:54 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1426595334.07.0.888011612035.issue1553375@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Adding Robert Collins to the nosy list to see if the recent traceback changes make it easier to implement this one correctly.

Robert, for context, the general idea here is to be able to stitch the traceback for a caught exception together with the stack trace for the current frame in order to give a full stack trace for the caught exception, rather than just the stack trace up to the frame where it was caught.

----------
nosy: +rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Tue Mar 17 13:37:39 2015
From: report at bugs.python.org (M. Levinson)
Date: Tue, 17 Mar 2015 12:37:39 +0000
Subject: [issue22698] Add constants for ioctl request codes
In-Reply-To: <1413990723.24.0.56994728842.issue22698@psf.upfronthosting.co.za>
Message-ID: <1426595859.43.0.390758646258.issue22698@psf.upfronthosting.co.za>


M. Levinson added the comment:

In addition to ioctl constants from Linux, it would also be very helpful
to add the constants from NetBSD et al. that are described in their ioctl(2) man page: http://man.netbsd.org/man/ioctl+2+NetBSD-current

Thank you!

----------
nosy: +mrl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22698>
_______________________________________

From report at bugs.python.org  Tue Mar 17 14:22:59 2015
From: report at bugs.python.org (Joshua J Cogliati)
Date: Tue, 17 Mar 2015 13:22:59 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_g++_module_compile_fails_with_=E2=80=98=5FAtom?=
 =?utf-8?q?ic=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426598579.73.0.193119869615.issue23644@psf.upfronthosting.co.za>


Joshua J Cogliati added the comment:

>Hum, I'm lost with the problem with C++ :-( What is your use case? Do >you want to compile CPython with C++? Or compile a third-party >extension with C++ and this extension includes "Python.h" which >includes "pyatomic.h".

My use case is I have C++ code that I want to use from a extension.  The extension includes Python.h, which includes pyatomic.h.  Thank you for looking into this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Tue Mar 17 14:44:45 2015
From: report at bugs.python.org (Edward)
Date: Tue, 17 Mar 2015 13:44:45 +0000
Subject: [issue23687] Stacktrace identifies wrong line in multiline list
 comprehension
Message-ID: <1426599885.89.0.0578302709073.issue23687@psf.upfronthosting.co.za>


New submission from Edward:

This code:

z = [
        ["Y" for y in None
        ] for x in range(4)
    ]

produces this stacktrace in both Python 2.7 and 3.4:

Traceback (most recent call last):
  File "/Users/edwsmith/dev/untitled4/test.py", line 7, in <module>
    ] for x in range(4)
  File "/Users/edwsmith/dev/untitled4/test.py", line 7, in <listcomp>
    ] for x in range(4)
TypeError: 'NoneType' object is not iterable

Of course my code was slightly more complex, but I lost a fair amount of time troubleshooting how the 'for x in range(4)' was evaluating to None, when really, it was the inner comprehension that was failing.

Ideally the stack trace would say:

Traceback (most recent call last):
  File "/Users/edwsmith/dev/untitled4/test.py", line 6, in <module>
    ["Y" for y in None
  File "/Users/edwsmith/dev/untitled4/test.py", line 6, in <listcomp>
    ["Y" for y in None
TypeError: 'NoneType' object is not iterable

----------
components: Interpreter Core
messages: 238290
nosy: ers81239
priority: normal
severity: normal
status: open
title: Stacktrace identifies wrong line in multiline list comprehension
type: behavior
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23687>
_______________________________________

From report at bugs.python.org  Tue Mar 17 14:48:15 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 17 Mar 2015 13:48:15 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1426600094.98.0.573155960295.issue2292@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Tue Mar 17 14:50:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 13:50:05 +0000
Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable
 (on POSIX)
In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za>
Message-ID: <1426600205.5.0.259237678226.issue23458@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ok, so Python 3.4 works as expected on Mac OS X 10.4. It's probably because Python 3.4 uses ioctl() if available. Maybe ioctl() works, but not fcntl().

os.urandom() only *tries* to make the file descriptor non-inheritable. It would be possible to backport some features of the PEP 446 but the code would be much more complex.

Please apply issue23458_tiger.patch, it's ok to skip the test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23458>
_______________________________________

From report at bugs.python.org  Tue Mar 17 14:52:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 13:52:15 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_g++_module_compile_fails_with_=E2=80=98=5FAtom?=
 =?utf-8?q?ic=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426600335.49.0.795461591922.issue23644@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Joshua: Can you please try to compile your extension with Py_LIMITED_API defined? Ex: "#define Py_LIMITED_API 0x03030000" at the top of your C file, or g++ -DPy_LIMITED_API=0x03030000.

And can you also please try to patch Python with pystate_cplusplus.patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Tue Mar 17 15:24:08 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 17 Mar 2015 14:24:08 +0000
Subject: [issue23684] urlparse() documentation does not account for default
 scheme
In-Reply-To: <1426556382.03.0.776976224321.issue23684@psf.upfronthosting.co.za>
Message-ID: <1426602248.37.0.277821367764.issue23684@psf.upfronthosting.co.za>


Demian Brecht added the comment:

+1 to the change, but I'd propose maybe "value of *scheme*" given the tables are inline with both urlsplit and urlparse docs?

----------
nosy: +demian.brecht

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23684>
_______________________________________

From report at bugs.python.org  Tue Mar 17 15:26:04 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Tue, 17 Mar 2015 14:26:04 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write
 ?
Message-ID: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>


New submission from Wolfgang Maier:

I thought I'd go back to work on a test patch for issue21560 today, but now I'm puzzled by the explicit handling of memoryviews in gzip.GzipFile.write.
The method is defined as:

    def write(self,data):
        self._check_closed()
        if self.mode != WRITE:
            import errno
            raise OSError(errno.EBADF, "write() on read-only GzipFile object")

        if self.fileobj is None:
            raise ValueError("write() on closed GzipFile object")

        # Convert data type if called by io.BufferedWriter.
        if isinstance(data, memoryview):
            data = data.tobytes()

        if len(data) > 0:
            self.size = self.size + len(data)
            self.crc = zlib.crc32(data, self.crc) & 0xffffffff
            self.fileobj.write( self.compress.compress(data) )
            self.offset += len(data)

        return len(data)

So for some reason, when it gets passed data as a meoryview it will first copy its content to a bytes object and I do not understand why.
zlib.crc32 and zlib.compress seem to be able to deal with memoryviews so the only sepcial casing that seems required here is in determining the byte length of the data, which I guess needs to use memoryview.nbytes. I've prepared a patch (overlapping the one for issue21560) that avoids copying the data and seems to work fine.

Did I miss something about the importance of the tobytes conversion ?

----------
components: Library (Lib)
messages: 238294
nosy: wolma
priority: normal
severity: normal
status: open
title: unnecessary copying of memoryview in gzip.GzipFile.write ?
type: resource usage
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Tue Mar 17 15:27:07 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Tue, 17 Mar 2015 14:27:07 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write
 ?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1426602427.28.0.175938836505.issue23688@psf.upfronthosting.co.za>


Changes by Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de>:


----------
keywords: +patch
Added file: http://bugs.python.org/file38521/memoryview_write.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Tue Mar 17 15:32:59 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 14:32:59 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write
 ?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1426602779.22.0.334655034229.issue23688@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The patch looks good to be me, but it lacks an unit test. Can you please add a simple unit test to ensure that it's possible to memoryview to write(), and that the result is correct? (ex: uncompress and ensure that you get the same content)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Tue Mar 17 15:33:11 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 14:33:11 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write
 ?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1426602791.09.0.948077270429.issue23688@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +serhiy.storchaka
type: resource usage -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Tue Mar 17 15:48:43 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 17 Mar 2015 14:48:43 +0000
Subject: [issue23625] load_module() docs: zipped eggs are not loaded.
In-Reply-To: <1425986086.94.0.227506635369.issue23625@psf.upfronthosting.co.za>
Message-ID: <1426603723.77.0.065448454049.issue23625@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

https://pythonhosted.org/setuptools/

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23625>
_______________________________________

From report at bugs.python.org  Tue Mar 17 15:49:31 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 17 Mar 2015 14:49:31 +0000
Subject: [issue22931] cookies with square brackets in value
In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za>
Message-ID: <1426603771.67.0.423080915194.issue22931@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Thanks for the report Mark, updating this patch to be more backwards compatible was on my to-do list. I've attached a new patch that simply adds the new characters to the legal value set.

It does look like that's the commit that introduced this issue, but the change was made for good reason.

----------
Added file: http://bugs.python.org/file38522/issue22931_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22931>
_______________________________________

From report at bugs.python.org  Tue Mar 17 15:52:02 2015
From: report at bugs.python.org (SMRUTI RANJAN SAHOO)
Date: Tue, 17 Mar 2015 14:52:02 +0000
Subject: [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1426603922.49.0.670973941923.issue12855@psf.upfronthosting.co.za>


SMRUTI RANJAN SAHOO added the comment:

i think in this, "line \fone\nline two\n" ,the space after line taking some garbage value or you can say hex value of "\".  so that's why that is showing some hex value. if you write "\n " instead of"\" then you can't find that hex value. i attached my idle image here.

----------
nosy: +SMRUTI RANJAN SAHOO
Added file: http://bugs.python.org/file38523/python.JPG

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Tue Mar 17 15:53:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Mar 2015 14:53:28 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426604008.55.0.585280191479.issue2211@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch with extended and unified tests. Also fixed one bug. I have left comments about some changes on Rietveld.

----------
Added file: http://bugs.python.org/file38524/issue2211_6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Tue Mar 17 15:54:26 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 17 Mar 2015 14:54:26 +0000
Subject: [issue22931] cookies with square brackets in value
In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za>
Message-ID: <1426604066.0.0.496506439636.issue22931@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


Removed file: http://bugs.python.org/file38522/issue22931_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22931>
_______________________________________

From report at bugs.python.org  Tue Mar 17 15:54:42 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 17 Mar 2015 14:54:42 +0000
Subject: [issue22931] cookies with square brackets in value
In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za>
Message-ID: <1426604082.77.0.862823971637.issue22931@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


Added file: http://bugs.python.org/file38525/issue22931_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22931>
_______________________________________

From report at bugs.python.org  Tue Mar 17 16:19:52 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Mar 2015 15:19:52 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write
 ?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1426605592.52.0.601272070663.issue23688@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Better way is data = data.cast('B').

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Tue Mar 17 16:22:54 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 15:22:54 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write
 ?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1426605774.63.0.487311686342.issue23688@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Better way is data = data.cast('B').

Why is this cast required? Can you please elaborate? If some memoryview must be rejected, again, we need more unit tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Tue Mar 17 16:29:32 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 17 Mar 2015 15:29:32 +0000
Subject: [issue23685] Fix usage of PyMODINIT_FUNC
In-Reply-To: <1426587233.23.0.965954561717.issue23685@psf.upfronthosting.co.za>
Message-ID: <1426606172.65.0.389438839251.issue23685@psf.upfronthosting.co.za>


Steve Dower added the comment:

I don't think we should be using PyMODINIT_FUNC for builtin modules, since that will make the init functions publicly available from python35.dll. That said, I do like being able to be consistent here... can we define PyMODINIT_FUNC differently when building pythoncore? That at least would keep the definitions in the same place if we ever change it (and since there's an open PEP regarding extension modules, it doesn't seem impossible).

The change for pyexpat looks right, since that's an external module. I have no ideas why PyMODINIT_FUNC wouldn't always be defined there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23685>
_______________________________________

From report at bugs.python.org  Tue Mar 17 16:44:14 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 15:44:14 +0000
Subject: [issue23685] Fix usage of PyMODINIT_FUNC
In-Reply-To: <1426587233.23.0.965954561717.issue23685@psf.upfronthosting.co.za>
Message-ID: <1426607054.07.0.158839985643.issue23685@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"I don't think we should be using PyMODINIT_FUNC for builtin modules, since that will make the init functions publicly available from python35.dll."

Do you mean that my change on PC/config.c is wrong?

For example, Modules/arraymodule.c already contains:

"PyMODINIT_FUNC PyInit_array(void)".

Is the PyInit_array symbol exported today or not on Windows?

If you think that the PyInit_array symbol should be private, maybe there is already an issue in Modules/arraymodule.c?

"can we define PyMODINIT_FUNC differently when building pythoncore?"

We can add a different macro for builtin modules. Using the issue #11410, we may use it to hide the symbols: __attribute__((visibility("hidden"))).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23685>
_______________________________________

From report at bugs.python.org  Tue Mar 17 16:47:16 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Tue, 17 Mar 2015 15:47:16 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write
 ?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1426607236.21.0.251050910068.issue23688@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

Here is a patch with memoryview tests.
Are tests and code patches supposed to go in one file or separate ones ?

----------
Added file: http://bugs.python.org/file38526/test_memoryview_write.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Tue Mar 17 16:50:31 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Tue, 17 Mar 2015 15:50:31 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write
 ?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1426607431.12.0.692271897462.issue23688@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

@Serhiy:
Why would data = data.cast('B') be required ? When would the memoryview not be in 'B' format already ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Tue Mar 17 16:51:55 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 17 Mar 2015 15:51:55 +0000
Subject: [issue23685] Fix usage of PyMODINIT_FUNC
In-Reply-To: <1426587233.23.0.965954561717.issue23685@psf.upfronthosting.co.za>
Message-ID: <1426607515.77.0.111645765934.issue23685@psf.upfronthosting.co.za>


Steve Dower added the comment:

Just had a look in Include/pyport.h and we're already defining PyMODINIT_FUNC differently for building core, so all your changes should be fine. The redefinition you removed from pyexpat.c was clearly never meant to be used for builtin modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23685>
_______________________________________

From report at bugs.python.org  Tue Mar 17 17:05:29 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Mar 2015 16:05:29 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write
 ?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1426608329.84.0.294073087995.issue23688@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

memoryview is converted to bytes because len() for memoryview returns a size of first dimension (a number of items for one-dimension view), not a number of bytes.

>>> m = memoryview(array.array('I', [1, 2, 3]))
>>> len(m)
3
>>> len(m.tobytes())
12
>>> len(m.cast('B'))
12

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Tue Mar 17 17:09:58 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Tue, 17 Mar 2015 16:09:58 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write
 ?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1426608598.45.0.561439289926.issue23688@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

> memoryview is converted to bytes because len() for memoryview returns a size of first dimension (a number of items for one-dimension view), not a number of bytes.
> 
>>>> m = memoryview(array.array('I', [1, 2, 3]))
>>>> len(m)
> 3
>>>> len(m.tobytes())
> 12
>>>> len(m.cast('B'))
> 12

Right, I was aware of this. But are you saying that my proposed solution (using memoryview.nbytes) is wrong ? If so, then cast is certainly an option and should still outperform tobytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Tue Mar 17 17:14:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Mar 2015 16:14:15 +0000
Subject: [issue18814] Add codecs.convert_surrogateescape to "clean" surrogate
 escaped strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1426608855.57.0.334146909903.issue18814@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Note that provided Python implementations are rather a proof of concept. After discussion I'll provide more efficient C implementations, that should be 1-2 orders faster (and infinitely fast for common case of ASCII strings).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18814>
_______________________________________

From report at bugs.python.org  Tue Mar 17 17:44:02 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 16:44:02 +0000
Subject: [issue23685] Fix usage of PyMODINIT_FUNC
In-Reply-To: <1426587233.23.0.965954561717.issue23685@psf.upfronthosting.co.za>
Message-ID: <1426610642.52.0.375270727154.issue23685@psf.upfronthosting.co.za>


STINNER Victor added the comment:

builtin_modules.patch: add _PyBUILTIN_MODINIT_FUNC macro and use it on modules which are builtins on POSIX.

I checked: it's not necessary to modify Modules/config.c to make the symbol hidden: only the C code in Modules/ need to set the attribute on the function.

So Modules/config.c, Modules/config.c.in, Modules/makesetup, PC/config.c, Tools/freeze/makeconfig.py, ... are unchanged by the patch.

--

On Linux with GCC >= 4.0, you can test manually to hide PyInit_xxx symbols using:

#define _PyBUILTIN_MODINIT_FUNC __attribute__((visibility("hidden"))) PyObject*

----------
Added file: http://bugs.python.org/file38527/builtin_modules.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23685>
_______________________________________

From report at bugs.python.org  Tue Mar 17 17:53:27 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Mar 2015 16:53:27 +0000
Subject: [issue23685] Fix usage of PyMODINIT_FUNC
In-Reply-To: <1426587233.23.0.965954561717.issue23685@psf.upfronthosting.co.za>
Message-ID: <20150317165324.30734.61717@psf.io>


Roundup Robot added the comment:

New changeset 22a0c925a7c2 by Victor Stinner in branch 'default':
Issue #23685: Fix usage of PyMODINIT_FUNC in _json, _scproxy, nis, pyexpat
https://hg.python.org/cpython/rev/22a0c925a7c2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23685>
_______________________________________

From report at bugs.python.org  Tue Mar 17 17:54:11 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 16:54:11 +0000
Subject: [issue23685] Fix usage of PyMODINIT_FUNC
In-Reply-To: <1426587233.23.0.965954561717.issue23685@psf.upfronthosting.co.za>
Message-ID: <1426611251.27.0.719614098361.issue23685@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I commited PyMODINIT_FUNC.patch without the useless change on PC/config.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23685>
_______________________________________

From report at bugs.python.org  Tue Mar 17 17:56:20 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Tue, 17 Mar 2015 16:56:20 +0000
Subject: [issue23689] Memory leak in Modules/sre_lib.h
Message-ID: <1426611380.23.0.46113718722.issue23689@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

In Modules/sre_lib.h on line 882 [1], a block of memory is allocated. If SRE(match) function later terminates abruptly, either because of a signal or because subsequent memory allocation fails, this block is never released.

[1] https://hg.python.org/cpython/file/c89f7c34e356/Modules/sre_lib.h#l882

----------
components: Regular Expressions
messages: 238313
nosy: abacabadabacaba, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Memory leak in Modules/sre_lib.h
type: resource usage
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23689>
_______________________________________

From report at bugs.python.org  Tue Mar 17 17:56:49 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 17 Mar 2015 16:56:49 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
 "chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1426611409.94.0.261463028795.issue12319@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Updated patch changes the following:

+ Removes support for trailers in requests as they're not supported
+ If Transfer-Encoding is explicitly set by the client, it's assumed that the caller will handle all encoding (backwards compatibility)
+ Fixed a bug where chunk size was being sent as decimal instead of hex

----------
Added file: http://bugs.python.org/file38528/issue12319_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12319>
_______________________________________

From report at bugs.python.org  Tue Mar 17 17:57:04 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 16:57:04 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write
 ?
In-Reply-To: <1426608598.45.0.561439289926.issue23688@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbSUYEXA+NqxRE_YkBMAhTrzZj9Ts=+ZfFS_ptKqD2FRQ@mail.gmail.com>


STINNER Victor added the comment:

> Are tests and code patches supposed to go in one file or separate ones ?

It's more convinient to have a single patch with both changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Tue Mar 17 18:04:35 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Tue, 17 Mar 2015 17:04:35 +0000
Subject: [issue23690] re functions never release GIL
Message-ID: <1426611875.32.0.330312694867.issue23690@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

Looks like function in re module (match, fullmatch and so on) don't release GIL, even though these operations can take much time. As a result, other threads can't run while a pattern is being matched, and thread switching doesn't happen as well.

----------
components: Regular Expressions
messages: 238316
nosy: abacabadabacaba, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re functions never release GIL
type: resource usage
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23690>
_______________________________________

From report at bugs.python.org  Tue Mar 17 18:06:24 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 17 Mar 2015 17:06:24 +0000
Subject: [issue21076] Turn signal.SIG* constants into enums
In-Reply-To: <1395935330.94.0.38028035584.issue21076@psf.upfronthosting.co.za>
Message-ID: <1426611984.15.0.0630940198445.issue21076@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Working on issue23673 I saw this in the new signal.py:

+def _enum_to_int(value):
+    """Convert an IntEnum member to a numeric value.
+    If it's not a IntEnum member return the value itself.
+    """
+    try:
+        return int(value)
+    except (ValueError, TypeError):
+        return value

The SIG, etc, constants are based on IntEnum, so they are already numeric values, and this function is unnecessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21076>
_______________________________________

From report at bugs.python.org  Tue Mar 17 18:08:56 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 17 Mar 2015 17:08:56 +0000
Subject: [issue23685] Fix usage of PyMODINIT_FUNC
In-Reply-To: <1426587233.23.0.965954561717.issue23685@psf.upfronthosting.co.za>
Message-ID: <1426612136.52.0.621159989389.issue23685@psf.upfronthosting.co.za>


Steve Dower added the comment:

Sounds good. Wasn't quite sure if you were after any effect or just consistency :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23685>
_______________________________________

From report at bugs.python.org  Tue Mar 17 18:09:23 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 17 Mar 2015 17:09:23 +0000
Subject: [issue21076] Turn signal.SIG* constants into enums
In-Reply-To: <1395935330.94.0.38028035584.issue21076@psf.upfronthosting.co.za>
Message-ID: <1426612163.59.0.280992665929.issue21076@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Removing the 'enum_to_int' function would also take care of the accepting inappropriate types problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21076>
_______________________________________

From report at bugs.python.org  Tue Mar 17 18:09:24 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 17:09:24 +0000
Subject: [issue23689] Memory leak in Modules/sre_lib.h
In-Reply-To: <1426611380.23.0.46113718722.issue23689@psf.upfronthosting.co.za>
Message-ID: <1426612164.29.0.404556120059.issue23689@psf.upfronthosting.co.za>


STINNER Victor added the comment:

There is maybe a bug. Can you show an example of regex and a text where the memory leak occurs? You can use the tracemalloc module to check if there is a memory leak. Or use sys.getcounts() if you compiled Python in debug mode.

sre_lib.h is very complex, it uses the C instruction "goto" with regex bytecodes.

"DO_JUMP(JUMP_REPEAT, jump_repeat, ctx->pattern+ctx->pattern[0]);" calls "goto entrace" to execute following bytecodes, but later it comes back after DO_JUMP() with the "jump_repeat:" label:

https://hg.python.org/cpython/file/c89f7c34e356/Modules/sre_lib.h#l1180

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23689>
_______________________________________

From report at bugs.python.org  Tue Mar 17 18:13:13 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 17:13:13 +0000
Subject: [issue23690] re functions never release GIL
In-Reply-To: <1426611875.32.0.330312694867.issue23690@psf.upfronthosting.co.za>
Message-ID: <1426612393.63.0.982980909866.issue23690@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Supporting to release the GIL would require to redesign the _sre module.

For example, the getstring() gets a "view" of a Python string, it doesn't copy the string. So we must hold the GIL, otherwise the Python string can be modified by other threads. Copying a very long string may be slower than just match the pattern :-/

During the pattern matching, other Python functions are called, these functions require the GIL to be hold. Example: PyObject_Malloc().

----------
nosy: +haypo
type: resource usage -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23690>
_______________________________________

From report at bugs.python.org  Tue Mar 17 18:16:54 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 17:16:54 +0000
Subject: [issue11410] Use GCC visibility attrs in PyAPI_*
In-Reply-To: <1299391945.72.0.037942723875.issue11410@psf.upfronthosting.co.za>
Message-ID: <1426612614.39.0.898280589408.issue11410@psf.upfronthosting.co.za>


STINNER Victor added the comment:

In the issue #23685, I proposed a patch to add _PyBUILTIN_MODINIT_FUNC for builtin modules. It makes possible to hide PyInit_xxx symbols of builtin symbols with __attribute__((visibility("hidden"))). It also avoids to export these privates symbols on Windows in the Python DLL (and on Linux in the Python .so library).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11410>
_______________________________________

From report at bugs.python.org  Tue Mar 17 18:17:06 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Tue, 17 Mar 2015 17:17:06 +0000
Subject: [issue23691] re.finditer iterator is not reentrant,
 but doesn't protect against nested calls to __next__
Message-ID: <1426612626.66.0.267835433945.issue23691@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

Iterator returned by re.finditer includes a SRE_STATE value, which is not designed to be used concurrently. However, it is possible to call __next__ on such iterator while another such call is in progress, e.g. from a signal handler. This may result in corruption of SRE_STATE structure.

----------
components: Regular Expressions
messages: 238323
nosy: abacabadabacaba, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.finditer iterator is not reentrant, but doesn't protect against nested calls to __next__
type: crash
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23691>
_______________________________________

From report at bugs.python.org  Tue Mar 17 18:22:18 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Tue, 17 Mar 2015 17:22:18 +0000
Subject: [issue23689] Memory leak in Modules/sre_lib.h
In-Reply-To: <1426611380.23.0.46113718722.issue23689@psf.upfronthosting.co.za>
Message-ID: <1426612938.14.0.1569762231.issue23689@psf.upfronthosting.co.za>


Evgeny Kapun added the comment:

Memory leak only happens if match operation terminates abruptly, e.g. because of SIGINT. In this case, DO_JUMP doesn't come back.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23689>
_______________________________________

From report at bugs.python.org  Tue Mar 17 18:31:39 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Tue, 17 Mar 2015 17:31:39 +0000
Subject: [issue23690] re functions never release GIL
In-Reply-To: <1426611875.32.0.330312694867.issue23690@psf.upfronthosting.co.za>
Message-ID: <1426613499.74.0.90097340294.issue23690@psf.upfronthosting.co.za>


Evgeny Kapun added the comment:

Aren't Python strings immutable?

Also, match functions still permit execution of signal handlers, which can execute any Python code.

If GIL is needed during matching, can it be released temporarily to permit thread switching?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23690>
_______________________________________

From report at bugs.python.org  Tue Mar 17 18:44:24 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Tue, 17 Mar 2015 17:44:24 +0000
Subject: [issue23689] Memory leak in Modules/sre_lib.h
In-Reply-To: <1426611380.23.0.46113718722.issue23689@psf.upfronthosting.co.za>
Message-ID: <1426614264.52.0.298075190443.issue23689@psf.upfronthosting.co.za>


Evgeny Kapun added the comment:

Tracemalloc code:

    import re
    import signal
    import tracemalloc

    class AlarmError(Exception):
        pass
    def handle_alarm(signal, frame):
        raise AlarmError
    signal.signal(signal.SIGALRM, handle_alarm)

    s1 = tracemalloc.take_snapshot()
    for _ in range(20):
        try:
            signal.alarm(1)
            re.match('(?:a|a|(?=b)){1000}', 'a'*999)
            raise RuntimeError
        except AlarmError:
            pass
    s2 = tracemalloc.take_snapshot()
    res = s2.compare_to(s1, 'lineno')
    for e in res[:10]:
        print(e)

For me, it shows almost 3 MiB allocated in re.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23689>
_______________________________________

From report at bugs.python.org  Tue Mar 17 19:00:24 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Mar 2015 18:00:24 +0000
Subject: [issue23689] Memory leak in Modules/sre_lib.h
In-Reply-To: <1426611380.23.0.46113718722.issue23689@psf.upfronthosting.co.za>
Message-ID: <1426615224.77.0.00352875697298.issue23689@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23689>
_______________________________________

From report at bugs.python.org  Tue Mar 17 19:13:15 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 17 Mar 2015 18:13:15 +0000
Subject: [issue23325] Turn SIG_DFL and SIG_IGN into functions
In-Reply-To: <1422304710.21.0.213579052731.issue23325@psf.upfronthosting.co.za>
Message-ID: <1426615995.96.0.666552095953.issue23325@psf.upfronthosting.co.za>


Ethan Furman added the comment:

A private method is being added to Enum to better support Enum replacement of constants, part of which includes changing __reduce_ex__ to return the string of the name.

These changes answer points 1 and 4.

Point 2 would be nice, but seems somewhat less important if Enums are being used.

Point 3 -- I don't see how 'Signal(xxx, yyy)' is more complicated than 'Signal(xxx, zzz)'?

----------
nosy: +barry, eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23325>
_______________________________________

From report at bugs.python.org  Tue Mar 17 19:31:58 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Mar 2015 18:31:58 +0000
Subject: [issue23689] Memory leak in Modules/sre_lib.h
In-Reply-To: <1426611380.23.0.46113718722.issue23689@psf.upfronthosting.co.za>
Message-ID: <1426617118.14.0.793623806089.issue23689@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be this patch helps.

----------
keywords: +patch
stage:  -> patch review
versions: +Python 2.7, Python 3.5
Added file: http://bugs.python.org/file38529/sre_clean_repeat_data.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23689>
_______________________________________

From report at bugs.python.org  Tue Mar 17 19:35:09 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Tue, 17 Mar 2015 18:35:09 +0000
Subject: [issue433030] SRE: Atomic Grouping (?>...) is not supported
Message-ID: <1426617309.14.0.86163903897.issue433030@psf.upfronthosting.co.za>


Changes by Evgeny Kapun <abacabadabacaba at gmail.com>:


----------
nosy: +abacabadabacaba

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue433030>
_______________________________________

From report at bugs.python.org  Tue Mar 17 19:41:39 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Mar 2015 18:41:39 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write
 ?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1426617699.21.0.00532244107233.issue23688@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

You patch is correct Wolfgang, but with cast('B') the patch would be smaller (no need to replace len(data) to nbytes).

While we are here, it is possible to add the support of general byte-like objects.

if not isinstance(data, bytes):
    data = memoryview(data).cast('B')

isinstance() check is just for optimization, it can be omitted if doesn't affect a performance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Tue Mar 17 19:49:23 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Tue, 17 Mar 2015 18:49:23 +0000
Subject: [issue9134] sre bug: lastmark_save/restore
In-Reply-To: <1277932738.21.0.537266945796.issue9134@psf.upfronthosting.co.za>
Message-ID: <1426618163.17.0.578147896213.issue9134@psf.upfronthosting.co.za>


Changes by Evgeny Kapun <abacabadabacaba at gmail.com>:


----------
nosy: +abacabadabacaba

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9134>
_______________________________________

From report at bugs.python.org  Tue Mar 17 19:49:44 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Tue, 17 Mar 2015 18:49:44 +0000
Subject: [issue23692] Undocumented feature prevents re module from finding
 certain matches
Message-ID: <1426618184.57.0.811463464384.issue23692@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

This pattern matches:

    re.match('(?:()|(?(1)()|z)){2}(?(2)a|z)', 'a')

But this doesn't:

    re.match('(?:()|(?(1)()|z)){0,2}(?(2)a|z)', 'a')

The difference is that {2} is replaced by {0,2}. This shouldn't prevent the pattern from matching anywhere where it matched before.

The reason for this misbehavior is a feature which is designed to protect re engine from infinite loops, but in fact it sometimes prevents patterns from matching where they should. I think that this feature should be at least properly documented, by properly I mean that it should be possible to reconstruct the exact behavior from documentation, as the implementation is not particularly easy to understand.

----------
components: Regular Expressions
messages: 238330
nosy: abacabadabacaba, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Undocumented feature prevents re module from finding certain matches
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23692>
_______________________________________

From report at bugs.python.org  Tue Mar 17 20:17:39 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 17 Mar 2015 19:17:39 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426619858.98.0.946211303835.issue2211@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Thanks for the updates Serhiy. All look good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Tue Mar 17 20:40:47 2015
From: report at bugs.python.org (Joshua J Cogliati)
Date: Tue, 17 Mar 2015 19:40:47 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_g++_module_compile_fails_with_=E2=80=98=5FAtom?=
 =?utf-8?q?ic=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426621247.61.0.913062285073.issue23644@psf.upfronthosting.co.za>


Joshua J Cogliati added the comment:

> @Joshua: Can you please try to compile your extension with  Py_LIMITED_API defined? Ex: "#define Py_LIMITED_API 0x03030000" at the top of your C file, or g++ -DPy_LIMITED_API=0x03030000.

It fails in that case, because SWIG is using functions that are not part of the Py_LIMITED_API.  

> And can you also please try to patch Python with pystate_cplusplus.patch?

With the pystate_cplusplus.patch I was able to compile both min_example.tar.gz and my actual extension.  So I with your patch, it does work.  Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Tue Mar 17 20:54:01 2015
From: report at bugs.python.org (Joshua J Cogliati)
Date: Tue, 17 Mar 2015 19:54:01 +0000
Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler
 if using ccache
In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za>
Message-ID: <1426622041.33.0.586558181247.issue8027@psf.upfronthosting.co.za>


Joshua J Cogliati added the comment:

This bug is still in Python 3.5.0a2 (but first issue 23644 needs to be fixed before g++ can be used at all)

Attached is a patch for Python 3.5.0.

----------
versions: +Python 3.5
Added file: http://bugs.python.org/file38530/fix-distutils-350.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8027>
_______________________________________

From report at bugs.python.org  Tue Mar 17 20:56:04 2015
From: report at bugs.python.org (Joshua J Cogliati)
Date: Tue, 17 Mar 2015 19:56:04 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_g++_module_compile_fails_with_=E2=80=98=5FAtom?=
 =?utf-8?q?ic=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426622164.79.0.268572595883.issue23644@psf.upfronthosting.co.za>


Joshua J Cogliati added the comment:

Once this is fixed, maybe issue 8027 can be fixed as well in 3.5.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Tue Mar 17 21:31:54 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 20:31:54 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1426624314.77.0.923466844815.issue1553375@psf.upfronthosting.co.za>


Robert Collins added the comment:

That should be straightforward - its just sequence suffix/prefix overlap detection, and FrameSummary (unlike frames) can be compared with ==. So yes, I think it makes it easier. It's not on my immediate itch-scratching though, but if someone were to poke at it and need any feedback / thoughts I'd be delighted to do so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Tue Mar 17 21:34:25 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 20:34:25 +0000
Subject: [issue23631] 3.5 (a2) traceback regression snarls Idle
In-Reply-To: <1426022728.67.0.0261421184633.issue23631@psf.upfronthosting.co.za>
Message-ID: <1426624465.08.0.0173095187916.issue23631@psf.upfronthosting.co.za>


Robert Collins added the comment:

Closing, though ideally Terry can confirm it is fully fixed for him.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23631>
_______________________________________

From report at bugs.python.org  Tue Mar 17 21:55:09 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Mar 2015 20:55:09 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <20150317205506.4213.73158@psf.io>


Roundup Robot added the comment:

New changeset 1ebf8d5b7d60 by Robert Collins in branch 'default':
Issue #18983: Allow selection of output units in timeit.
https://hg.python.org/cpython/rev/1ebf8d5b7d60

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Tue Mar 17 21:59:45 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Mar 2015 20:59:45 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <20150317205943.16924.48523@psf.io>


Roundup Robot added the comment:

New changeset ed34dd00405e by Robert Collins in branch 'default':
Fix patch attribution for issue 18983.
https://hg.python.org/cpython/rev/ed34dd00405e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Tue Mar 17 22:01:42 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 21:01:42 +0000
Subject: [issue18983] Specify time unit for timeit CLI
In-Reply-To: <1378674956.86.0.740860392271.issue18983@psf.upfronthosting.co.za>
Message-ID: <1426626102.01.0.118869939976.issue18983@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
nosy: +rbcollins
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18983>
_______________________________________

From report at bugs.python.org  Tue Mar 17 22:07:31 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 17 Mar 2015 21:07:31 +0000
Subject: [issue23631] 3.5 (a2) traceback regression snarls Idle
In-Reply-To: <1426022728.67.0.0261421184633.issue23631@psf.upfronthosting.co.za>
Message-ID: <1426626451.0.0.936831156799.issue23631@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: needs patch -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23631>
_______________________________________

From report at bugs.python.org  Tue Mar 17 22:16:03 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 17 Mar 2015 21:16:03 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <1426626963.04.0.0828978222896.issue23606@psf.upfronthosting.co.za>


eryksun added the comment:

Say I need to use ctypes to call _wsopen_s to open a file without write sharing. If I read you correctly, you're saying I'll need to know it's exported by api-ms-win-crt-stdio-l1-1-0.dll? Does the 'l1-1-0' suffix reflect a version number that will be incremented over time? If so, how about adding an API that maps 'stdio' to the version that Python is linked against?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23606>
_______________________________________

From report at bugs.python.org  Tue Mar 17 22:22:00 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 17 Mar 2015 21:22:00 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426627320.26.0.286190215797.issue2211@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Tue Mar 17 22:24:45 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 21:24:45 +0000
Subject: [issue23183] timeit CLI best of 3: undocumented output format
In-Reply-To: <1420620799.47.0.00516438922368.issue23183@psf.upfronthosting.co.za>
Message-ID: <1426627485.87.0.769756675769.issue23183@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
nosy: +rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23183>
_______________________________________

From report at bugs.python.org  Tue Mar 17 22:25:27 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 21:25:27 +0000
Subject: [issue23183] timeit CLI best of 3: undocumented output format
In-Reply-To: <1420620799.47.0.00516438922368.issue23183@psf.upfronthosting.co.za>
Message-ID: <1426627527.3.0.85040958121.issue23183@psf.upfronthosting.co.za>


Robert Collins added the comment:

Here is a patch with some prose - feedback appreciated!

----------
keywords: +patch
Added file: http://bugs.python.org/file38531/issue-23183-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23183>
_______________________________________

From report at bugs.python.org  Tue Mar 17 22:25:40 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 21:25:40 +0000
Subject: [issue23183] timeit CLI best of 3: undocumented output format
In-Reply-To: <1420620799.47.0.00516438922368.issue23183@psf.upfronthosting.co.za>
Message-ID: <1426627540.14.0.667532409977.issue23183@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23183>
_______________________________________

From report at bugs.python.org  Tue Mar 17 22:32:11 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 21:32:11 +0000
Subject: [issue23552] Have timeit warn about runs that are not independent of
 each other
In-Reply-To: <1425156172.0.0.931116052614.issue23552@psf.upfronthosting.co.za>
Message-ID: <1426627931.33.0.39926122895.issue23552@psf.upfronthosting.co.za>


Robert Collins added the comment:

I think for PyPI its actually important here - the JIT'd state of the code is essentially global state being mutated - you can't assess how fast the code is without first warming up the JIT, and if it warms up half way through your fastest run, you're still not actually finding out what you might want to find out.

E.g. do you want to know:
 - how fast is this unjitted [e.g. CLI's]
 - how fast will this be once its hot [e.g. services]

Personally, I think as a first approximation, warning about massive variance is a good thing. We could add an option to turn it off, and we could also look at hooking properly into the jit to allow detection of stable state and benchmark only from there on in. But those extra things don't detract from the utility of warning about suspect runs.

----------
nosy: +rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23552>
_______________________________________

From report at bugs.python.org  Tue Mar 17 22:32:37 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 21:32:37 +0000
Subject: [issue23690] re functions never release GIL
In-Reply-To: <1426611875.32.0.330312694867.issue23690@psf.upfronthosting.co.za>
Message-ID: <1426627957.11.0.716091439999.issue23690@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Aren't Python strings immutable?

Yes. But the re module supports more types than just str and bytes. For example, bytearray is also accepted:

>>> re.match(b'^abc', b'abc')
<_sre.SRE_Match object; span=(0, 3), match=b'abc'>
>>> re.match(b'^abc', bytearray(b'abc'))
<_sre.SRE_Match object; span=(0, 3), match=b'abc'>

> Also, match functions still permit execution of signal handlers, which can execute any Python code.

Correct, signal handlers are called. If you mutate the string currently used in the pattern matching, you can probably crash Python. I hope that nobody does such ugly things in Python signal handlers :-)

> If GIL is needed during matching, can it be released temporarily to permit thread switching?

It's possible to modify the _sre module to release the GIL in some cases. It's possible to release the GIL for immutables string, and keep the GIL for mutable strings. To do this, you have to audit the source code. First, ensure that no global variable is used. For example, the "state" must not be shared (it's ok, it's allocated on the stack, thread stacks are not shared).

If you start to release the GIL, you have to search for all functions which must be called with the GIL hold. For example, memory allocators, but also all functions manipulating Python objects. Hint: seach "PyObject*". For example, getslice() must be called with the GIL hold.

Since the GIL is a lock, you should benchmark to ensure that sequences of acquire/release the GIL doesn't kill performances with a single thread, and with multiple threads. Anyway, a benchmark will be needed.

To be clear: I'm *not* interested to optimize the _sre module to release the GIL (to support parallel executions).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23690>
_______________________________________

From report at bugs.python.org  Tue Mar 17 22:35:19 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 21:35:19 +0000
Subject: [issue23689] Memory leak in Modules/sre_lib.h
In-Reply-To: <1426611380.23.0.46113718722.issue23689@psf.upfronthosting.co.za>
Message-ID: <1426628119.95.0.00585480427924.issue23689@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh cool, you wrote a script to reproduce the issue! And Serhiy wrote a patch, great! Great job guys.

sre_clean_repeat_data.patch looks good to me.

@Serhiy: Can you try the example to ensure that it fixes the issue? If yes, go ahead!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23689>
_______________________________________

From report at bugs.python.org  Tue Mar 17 22:43:48 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 21:43:48 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write
 ?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1426628628.35.0.00976295947648.issue23688@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> While we are here, it is possible to add the support of general byte-like objects.

With and without the patch, write() accepts bytes, bytearray and memoryview. Which other byte-like types do you know?

writeframesraw() method of aifc, sunau and wave modules use this pattern:

    if not isinstance(data, (bytes, bytearray)):
        data = memoryview(data).cast('B')

We can maybe reuse it in gzip module?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Tue Mar 17 22:53:54 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 21:53:54 +0000
Subject: [issue23552] Have timeit warn about runs that are not independent of
 each other
In-Reply-To: <1425156172.0.0.931116052614.issue23552@psf.upfronthosting.co.za>
Message-ID: <1426629234.17.0.526807187067.issue23552@psf.upfronthosting.co.za>


Robert Collins added the comment:

Reviewed on rietvald.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23552>
_______________________________________

From report at bugs.python.org  Tue Mar 17 22:54:18 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 21:54:18 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1426629258.24.0.631343157305.issue6422@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
nosy: +rbcollins
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Tue Mar 17 22:54:49 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Mar 2015 21:54:49 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_g++_module_compile_fails_with_=E2=80=98=5FAtom?=
 =?utf-8?q?ic=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <20150317215446.30044.628@psf.io>


Roundup Robot added the comment:

New changeset cb05b6d7aacd by Victor Stinner in branch 'default':
Issue #23644: Fix issues with C++ when compiling Python extensions
https://hg.python.org/cpython/rev/cb05b6d7aacd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Tue Mar 17 22:57:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 21:57:57 +0000
Subject: =?utf-8?q?=5Bissue23644=5D_g++_module_compile_fails_with_=E2=80=98=5FAtom?=
 =?utf-8?q?ic=E2=80=99_does_not_name_a_type?=
In-Reply-To: <1426172340.82.0.788562357439.issue23644@psf.upfronthosting.co.za>
Message-ID: <1426629477.7.0.232740121785.issue23644@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"With the pystate_cplusplus.patch I was able to compile both min_example.tar.gz and my actual extension.  So I with your patch, it does work.  Thank you."

Cool! I applied this simple patch instead of trying to write an ugly glue in pyatomic.h between C and C++.

C and C++ simply look to be incompatible for handling atomic types :-/ The good news is that we don't them atomic types for Python extensions, only to compile Python core.

Thanks for the report. I prefer to detect such annoying issue before a ".0" release (3.5.0). FYI it's a regression introduced by the issue #22038 which started to use <stdatomic.h> (but it's now fixed).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23644>
_______________________________________

From report at bugs.python.org  Tue Mar 17 22:59:03 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 21:59:03 +0000
Subject: [issue22038] Implement atomic operations on non-x86 platforms
In-Reply-To: <1406049852.33.0.466915172772.issue22038@psf.upfronthosting.co.za>
Message-ID: <1426629543.31.0.148039983764.issue22038@psf.upfronthosting.co.za>


STINNER Victor added the comment:

<stdatomic.h> is not compatible with C++: I disabled completly pyatomic.h on C++. pyatomic.h is only needed by Python core, not to compile Python extensions, so it's not an issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22038>
_______________________________________

From report at bugs.python.org  Tue Mar 17 23:09:39 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 17 Mar 2015 22:09:39 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <1426630179.79.0.911840242853.issue23606@psf.upfronthosting.co.za>


Steve Dower added the comment:

Pretty much, except the entry point DLL version won't increment unless there's a breaking change to the API. So you have to know where it's from, but (AIUI) the l1-0-0 file will always be available. At some point it may turn into a wrapper rather than a redirect, but that doesn't really matter.

I'm not sure there's any better way to provide access to the functions other than adding them to msvcrtmodule. It's more work, but far more friendly. I hope we have a pretty low bar for adding functions to that module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23606>
_______________________________________

From report at bugs.python.org  Tue Mar 17 23:16:10 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Mar 2015 22:16:10 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426628628.35.0.00976295947648.issue23688@psf.upfronthosting.co.za>
Message-ID: <1844057.3rvGZ4Q5zV@raxxla>


Serhiy Storchaka added the comment:

> With and without the patch, write() accepts bytes, bytearray and memoryview.
> Which other byte-like types do you know?

The "bytes-like object" term is used as an alias of "an instance of type that 
supports buffer protocol". Besides bytes, bytearray and memoryview, this is 
array.array and NumPy arrays. file.write() supports arbitrary bytes-like 
objects, including array.array and NumPy arrays.

> writeframesraw() method of aifc, sunau and wave modules use this pattern:

Yes, I wrote this code, if I remember correct.

----------
title: unnecessary copying of memoryview in gzip.GzipFile.write ? -> unnecessary copying of memoryview in gzip.GzipFile.write?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Tue Mar 17 23:18:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Mar 2015 22:18:55 +0000
Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable
 (on POSIX)
In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za>
Message-ID: <20150317221852.70040.19078@psf.io>


Roundup Robot added the comment:

New changeset 730bbd1499ba by Ned Deily in branch '2.7':
Issue #23458: Skip test_urandom_fd_non_inheritable on OS X 10.4 since
https://hg.python.org/cpython/rev/730bbd1499ba

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23458>
_______________________________________

From report at bugs.python.org  Tue Mar 17 23:19:10 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 22:19:10 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1426630750.43.0.846950277708.issue6422@psf.upfronthosting.co.za>


Robert Collins added the comment:

I'm confused by the feedback on the patch. It adds a single new function, doesn't alter the public interface for any existing functions, and seems fit for purpose. Could someone help me understand how its deficient?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Tue Mar 17 23:34:37 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 22:34:37 +0000
Subject: [issue23693] timeit accuracy could be better
Message-ID: <1426631677.96.0.782828300886.issue23693@psf.upfronthosting.co.za>


New submission from Robert Collins:

In #6422 Haypo suggested making the timeit reports much better. This is a new ticket just for that. See https://bitbucket.org/haypo/misc/src/tip/python/benchmark.py and http://bugs.python.org/issue6422?@ok_message=issue%206422%20nosy%2C%20nosy_count%2C%20stage%20edited%20ok&@template=item#msg164216

----------
components: Library (Lib)
messages: 238353
nosy: haypo, rbcollins
priority: normal
severity: normal
stage: needs patch
status: open
title: timeit accuracy could be better
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23693>
_______________________________________

From report at bugs.python.org  Tue Mar 17 23:35:00 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 22:35:00 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1426631700.1.0.20102917802.issue6422@psf.upfronthosting.co.za>


Robert Collins added the comment:

Filed #23693 for the accuracy thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Tue Mar 17 23:39:16 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 22:39:16 +0000
Subject: [issue19495] context manager for measuring duration of blocks of code
In-Reply-To: <1383588451.25.0.545990193953.issue19495@psf.upfronthosting.co.za>
Message-ID: <1426631956.85.0.691714601992.issue19495@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
nosy: +rbcollins
title: Enhancement for timeit: measure time to run blocks of code using 'with' -> context manager for measuring duration of blocks of code

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19495>
_______________________________________

From report at bugs.python.org  Tue Mar 17 23:39:59 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 22:39:59 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>
Message-ID: <1426631999.28.0.46890189366.issue23648@psf.upfronthosting.co.za>


STINNER Victor added the comment:

In msg196555, Charles-Fran?ois Natali wrote:

"""
>From a cursory look, the main files affected would be:
Modules/fcntlmodule.c
Modules/ossaudiodev.c
Modules/posixmodule.c
Modules/selectmodule.c
Modules/selectmodule.c
Modules/signalmodule.c
Modules/socketmodule.c
Modules/syslogmodule.c
"""

For syslog, I tested the following code and I don't get any InterruptedError. The return type of the C functions openlog(), syslog() and closelog() is void: no result. So I don't see how they could fail because of a signal. Code of my test:
---
import syslog
import signal

hit = 0

def noop(*args):
    global hit
    hit += 1

signal.signal(signal.SIGALRM, noop)
t = 1e-6
nlog = 10**2
signal.setitimer(signal.ITIMER_REAL, t, t)
for i in range(nlog):
    syslog.openlog()
    syslog.syslog("test %s")
    syslog.closelog()
signal.signal(signal.SIGALRM, signal.SIG_IGN)

print(nlog, "logs")
print(hit, "signals")
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Tue Mar 17 23:43:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Mar 2015 22:43:54 +0000
Subject: [issue23552] Have timeit warn about runs that are not independent of
 each other
In-Reply-To: <1425156172.0.0.931116052614.issue23552@psf.upfronthosting.co.za>
Message-ID: <1426632234.13.0.925654815151.issue23552@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that emits a warning using the warnings module. The warning is output to stderr and can be suppressed with the -Wignore option, as all other warnings.

$ ./python -m timeit -n1 -r 10 -s "import time, random" -- "time.sleep(random.random())"
1 loops, best of 10: 79.6 msec per loop
:0: UserWarning: These test results likely aren't reliable.  The worst
time was more than four times slower than the best time.
$ ./python -Wignore -m timeit -n1 -r 10 -s "import time, random" -- "time.sleep(random.random())"
1 loops, best of 10: 16.2 msec per loop

----------
Added file: http://bugs.python.org/file38532/timeit_python_warning.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23552>
_______________________________________

From report at bugs.python.org  Wed Mar 18 00:03:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Mar 2015 23:03:55 +0000
Subject: [issue23552] Have timeit warn about runs that are not independent of
 each other
In-Reply-To: <1425156172.0.0.931116052614.issue23552@psf.upfronthosting.co.za>
Message-ID: <1426633435.55.0.853371002342.issue23552@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Implemented Robert's suggestion.

$ ./python -m timeit -n1 -r 10 -s "import time, random" -- "time.sleep(random.random())"
1 loops, best of 10: 30.2 msec per loop
:0: UserWarning: The test results are likely unreliable. The worst
time (946 msec) was more than four times slower than the best time.

----------
Added file: http://bugs.python.org/file38533/timeit_python_warning_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23552>
_______________________________________

From report at bugs.python.org  Wed Mar 18 00:04:12 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Mar 2015 23:04:12 +0000
Subject: [issue23552] Have timeit warn about runs that are not independent of
 each other
In-Reply-To: <1425156172.0.0.931116052614.issue23552@psf.upfronthosting.co.za>
Message-ID: <1426633452.49.0.323291595171.issue23552@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file38532/timeit_python_warning.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23552>
_______________________________________

From report at bugs.python.org  Wed Mar 18 00:19:38 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 23:19:38 +0000
Subject: [issue23694] PEP 475: handle EINTR in fileutils.c
Message-ID: <1426634378.41.0.681041892498.issue23694@psf.upfronthosting.co.za>


New submission from STINNER Victor:

fileutils.c must be modified to retry when a function fails with EINTR: see the PEP 475.

I'm working on a patch.

----------
messages: 238358
nosy: haypo
priority: normal
severity: normal
status: open
title: PEP 475: handle EINTR in fileutils.c
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23694>
_______________________________________

From report at bugs.python.org  Wed Mar 18 00:27:26 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Mar 2015 23:27:26 +0000
Subject: [issue23694] PEP 475: handle EINTR in fileutils.c
In-Reply-To: <1426634378.41.0.681041892498.issue23694@psf.upfronthosting.co.za>
Message-ID: <20150317232723.24232.86068@psf.io>


Roundup Robot added the comment:

New changeset 0b99d7043a99 by Victor Stinner in branch 'default':
Issue #23694: Enhance _Py_open(), it now raises exceptions
https://hg.python.org/cpython/rev/0b99d7043a99

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23694>
_______________________________________

From report at bugs.python.org  Wed Mar 18 00:28:00 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 23:28:00 +0000
Subject: [issue23683] allow timeit to run expensive reset code per repeats
In-Reply-To: <1426553264.53.0.0690817239564.issue23683@psf.upfronthosting.co.za>
Message-ID: <1426634880.48.0.917197835281.issue23683@psf.upfronthosting.co.za>


Robert Collins added the comment:

bah, nevermind - I failed to get that setup is called once per loop regardless - I might consider this a doc issue, or perhaps I was just fuzzy brained.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23683>
_______________________________________

From report at bugs.python.org  Wed Mar 18 00:29:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Mar 2015 23:29:50 +0000
Subject: [issue23693] timeit accuracy could be better
In-Reply-To: <1426631677.96.0.782828300886.issue23693@psf.upfronthosting.co.za>
Message-ID: <1426634990.5.0.736567717796.issue23693@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue21988.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23693>
_______________________________________

From report at bugs.python.org  Wed Mar 18 00:42:08 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 17 Mar 2015 23:42:08 +0000
Subject: [issue23677] Mention dict and set comps in library reference
In-Reply-To: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za>
Message-ID: <1426635728.38.0.509149075996.issue23677@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

That was embarrassing, hopefully this is rather better.

----------
nosy: +BreamoreBoy
Added file: http://bugs.python.org/file38534/issue23677_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23677>
_______________________________________

From report at bugs.python.org  Wed Mar 18 00:47:46 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 17 Mar 2015 23:47:46 +0000
Subject: [issue18828] urljoin behaves differently with custom and standard
 schemas
In-Reply-To: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za>
Message-ID: <1426636066.67.0.067024573674.issue18828@psf.upfronthosting.co.za>


Demian Brecht added the comment:

> I haven?t heard any arguments against this option yet, and it didn?t break any tests.

Pre patch:

>>> urljoin('mailto:foo@', 'bar.com')
'bar.com'

Post patch:

>>> urljoin('mailto:foo@', 'bar.com')
'mailto:bar.com/bar.com'

I'm taking an educated guess here based on a marginal amount of research (there are just a few registered schemes at http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml that should be understood), but it /seems/ like perhaps the current behaviour is intended to safeguard against joining non-hierarchical schemes in which case you'd get nonsensical values. It does seem a little odd to me, but I definitely prefer the former behaviour to the latter.

I think that short term, Madison's suggestion about documenting uses_relative would be an easy win and can be applied to all branches. Long term though, I think it would be nice to have a generalized urljoin() method that accounts for most (if not all) classifications of url schemes.

Thoughts?

----------
nosy: +demian.brecht

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18828>
_______________________________________

From report at bugs.python.org  Wed Mar 18 00:49:30 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 17 Mar 2015 23:49:30 +0000
Subject: [issue18828] urljoin behaves differently with custom and standard
 schemas
In-Reply-To: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za>
Message-ID: <1426636170.36.0.089367199835.issue18828@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
stage:  -> patch review
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18828>
_______________________________________

From report at bugs.python.org  Wed Mar 18 00:53:27 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Mar 2015 23:53:27 +0000
Subject: [issue23693] timeit accuracy could be better
In-Reply-To: <1426631677.96.0.782828300886.issue23693@psf.upfronthosting.co.za>
Message-ID: <1426636407.9.0.0723239353891.issue23693@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Not only I'm too lazy to compute manually the number of loops and repeat, but also I don't trust myself. It's even worse when someone publishs results of a micro-benchmark. I don't trust how the benchmark was calibrated. In my experience, micro-benchmark are polluted by noise in timings, so results are not reliable. 

benchmarks.py calibration is based on time, whereas timeit uses hardcoded constants (loops=1000000, repeat=3) which can be modified on the command line.

benchmarks.py has 3 main parameters:

- minimum duration of a single run (--min-time): 100 ms by default
- maximum total duration of the benchmark: benchmark.py does its best to respect this duration, but it can be longer: 1 second by default
- minimum repeat: 5 by default

The minimum duration is increased if the clock resolution is bad (1 ms or more). It's the case on Windows for time.clock() on Python 2 for example. Extract of benchmark.py:

    min_time = max(self.config.min_time, timer_precision * 100)

The estimation of the number of loops is not reliable, but it's written to be "fast". Since I run a micro-benchmark many times, I don't want to wait too long. It's not a power of 10, but an arbitrary integer number. Usually, when running benchmark.py multiple times, the number of loops is different each time. It's not really a big issue, but it probably makes results more difficult to compare.

My constrain is max_time. The tested function may not have a linear duration (time = time_one_iteration * loops).

https://bitbucket.org/haypo/misc/src/348bfd6108e9985b3c2298d2745eb5ddfe7042e6/python/benchmark.py?at=default#cl-416

Repeat a test at least 5 times is a compromise between the stability of the result and the total duration of the benchmark.

Feel free to reuse my code to enhance time.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23693>
_______________________________________

From report at bugs.python.org  Wed Mar 18 01:18:02 2015
From: report at bugs.python.org (Paddy McCarthy)
Date: Wed, 18 Mar 2015 00:18:02 +0000
Subject: [issue23695] idiom for clustering a data series into n-length groups
Message-ID: <1426637882.4.0.0938827316057.issue23695@psf.upfronthosting.co.za>


New submission from Paddy McCarthy:

In the zip section of the documentation, e.g. https://docs.python.org/3/library/functions.html#zip There is mention of an idiom for clustering a data series into n-length groups that I seem to only come across when people are explaining how it works on blog entries such as the three mentioned here: http://www.reddit.com/r/programming/comments/2z4rv4/a_function_for_partitioning_python_arrays/cpfvwun?context=3

It is not a straight-forward bit of code and so I think it should either be explained in more detail in the documentation or removed as an idiom, or I guess it could be encapsulated in a function and added to the stdlib.

----------
assignee: docs at python
components: Documentation
messages: 238365
nosy: Paddy McCarthy, docs at python
priority: normal
severity: normal
status: open
title: idiom for clustering a data series into n-length groups
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/issue23695>
_______________________________________

From report at bugs.python.org  Wed Mar 18 01:46:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Mar 2015 00:46:24 +0000
Subject: [issue23694] PEP 475: handle EINTR in fileutils.c
In-Reply-To: <1426634378.41.0.681041892498.issue23694@psf.upfronthosting.co.za>
Message-ID: <20150318004621.7265.54924@psf.io>


Roundup Robot added the comment:

New changeset cfe541c694f3 by Victor Stinner in branch 'default':
Issue #23694: Enhance _Py_fopen(), it now raises an exception on error
https://hg.python.org/cpython/rev/cfe541c694f3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23694>
_______________________________________

From report at bugs.python.org  Wed Mar 18 01:53:46 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 00:53:46 +0000
Subject: [issue23694] PEP 475: handle EINTR in fileutils.c
In-Reply-To: <1426634378.41.0.681041892498.issue23694@psf.upfronthosting.co.za>
Message-ID: <1426640026.24.0.345748436778.issue23694@psf.upfronthosting.co.za>


STINNER Victor added the comment:

fileutils_eintr.patch: handle EINTR for open, fopen and dup (only on Linux for dup in _Py_dup).

_Py_wfopen() and _Py_fopen() are not modified because callers are not really prepared to handle exceptions. These functions are mostly used during early steps of Python initializations. If someone is motived, you can propose a patch for these functions.

For other functions (cwd, readlink, etc.), it's not clear to me if we can get EINTR or not.

----------
keywords: +patch
Added file: http://bugs.python.org/file38535/fileutils_eintr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23694>
_______________________________________

From report at bugs.python.org  Wed Mar 18 01:53:54 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 00:53:54 +0000
Subject: [issue23694] PEP 475: handle EINTR in fileutils.c
In-Reply-To: <1426634378.41.0.681041892498.issue23694@psf.upfronthosting.co.za>
Message-ID: <1426640034.27.0.279414942002.issue23694@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23694>
_______________________________________

From report at bugs.python.org  Wed Mar 18 01:58:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 00:58:17 +0000
Subject: [issue23696] zipimport: chain ImportError to OSError
Message-ID: <1426640296.98.0.079062899559.issue23696@psf.upfronthosting.co.za>


New submission from STINNER Victor:

To work on the issue #23694, I refactored the C function _Py_fopen_obj() to raise an exception on error. I noticed the that zipimport replaces the current exception with ZipImportError.

Attached patch chains the ZipImportError to the OSError to provide more context on error. For example, you can see in the unit test that ZipImportError was caused by a permission error.

Is it ok to require ZipImport.__context__ to be an OSError in the unit test? Can it be added to "zipimport spec"? If not, the test may be splitted to only check __context__ in a test decorated with @cpython_only.

----------
files: zipimporterror_oserror.patch
keywords: patch
messages: 238368
nosy: brett.cannon, haypo, ncoghlan
priority: normal
severity: normal
status: open
title: zipimport: chain ImportError to OSError
versions: Python 3.5
Added file: http://bugs.python.org/file38536/zipimporterror_oserror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23696>
_______________________________________

From report at bugs.python.org  Wed Mar 18 02:00:03 2015
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 18 Mar 2015 01:00:03 +0000
Subject: [issue23695] idiom for clustering a data series into n-length groups
In-Reply-To: <1426637882.4.0.0938827316057.issue23695@psf.upfronthosting.co.za>
Message-ID: <1426640403.89.0.670598704095.issue23695@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I think an example should suffice:

>>> s = [1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> n = 3
>>> zip(*[iter(s)]*n)
[(1, 2, 3), (4, 5, 6), (7, 8, 9)]

----------
nosy: +ethan.furman
versions:  -Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23695>
_______________________________________

From report at bugs.python.org  Wed Mar 18 02:00:45 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 18 Mar 2015 01:00:45 +0000
Subject: [issue9782] _multiprocessing.c warnings under 64-bit Windows
In-Reply-To: <1283776985.14.0.464453735202.issue9782@psf.upfronthosting.co.za>
Message-ID: <1426640445.78.0.948843994458.issue9782@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Where do we currently stand with all compiler warnings, I'm still seeing some but I recall that we've other open issues about this problem?

----------
nosy: +serhiy.storchaka, steve.dower, zach.ware
versions: +Python 3.4, Python 3.5 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9782>
_______________________________________

From report at bugs.python.org  Wed Mar 18 02:01:04 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 18 Mar 2015 01:01:04 +0000
Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable
 (on POSIX)
In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za>
Message-ID: <1426640464.69.0.00462660287787.issue23458@psf.upfronthosting.co.za>


Ned Deily added the comment:

The buildbot is now green -> closed.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23458>
_______________________________________

From report at bugs.python.org  Wed Mar 18 03:31:14 2015
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 18 Mar 2015 02:31:14 +0000
Subject: [issue23529] Limit decompressed data when reading from LZMAFile and
 BZ2File
In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za>
Message-ID: <1426645874.26.0.290549655316.issue23529@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

If you want to add support for buffer_size=0 in a separate patch/issue I think that's fine. But in that case I would not add a buffer_size parameter now at all. IMO, not having it is better as having it but not supporting zero (even if it's documented that's pretty surprising).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23529>
_______________________________________

From report at bugs.python.org  Wed Mar 18 04:20:20 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Mar 2015 03:20:20 +0000
Subject: [issue23697] Module level map & submit for concurrent.futures
Message-ID: <1426648820.66.0.638337601517.issue23697@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Currently, concurrent.futures requires you to explicitly create and manage the lifecycle of a dedicated executor to handle multithreaded and multiprocess dispatch of concurrent activities.

It may be beneficial to provide module level tmap(), pmap(), tsubmit() and psubmit() APIs that use a default ThreadExecutor and/or ProcessExecutor instance to provide concurrent execution, with reasonable default settings for the underlying thread & process pools.

(Longer names like map_thread, and map_process would also be possible, but tmap & pmap are much easier to type and seem sufficient for mnemonic purposes)

This would allow usage like:

  done, not_done = wait(tmap(func, data))

and:

  for f in as_completed(tmap(func, data)):
    result = f.result()

Ways to explicitly set and get the default thread and process pools would also need to be provided, perhaps based on the design of the event loop management interface in the asyncio module.

----------
messages: 238373
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Module level map & submit for concurrent.futures

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23697>
_______________________________________

From report at bugs.python.org  Wed Mar 18 04:29:29 2015
From: report at bugs.python.org (Jeremy Goss)
Date: Wed, 18 Mar 2015 03:29:29 +0000
Subject: [issue23207] logging.basicConfig does not validate keyword arguments
In-Reply-To: <1420813239.75.0.476507944816.issue23207@psf.upfronthosting.co.za>
Message-ID: <1426649369.29.0.832919474571.issue23207@psf.upfronthosting.co.za>


Jeremy Goss added the comment:

The argument validation in basicConfig has introduced another problem.
I cannot pass in an optional filename/filemode argument pair.

Previously, I passed in an optional logfile argument from ArgumentParser (which could be None). Now, I get a ValueError because filemode is not popped if filename is None.

logging.basicConfig(..., filename=args.logfile, filemode="w")
...
ValueError: Unrecognised argument(s): filemode

Suggested fix to place mode assignment alongside filename in basicConfig():
    filename = kwargs.pop("filename", None)
    mode = kwargs.pop("filemode", 'a')
    if filename:
        h = FileHandler(filename, mode)

----------
nosy: +Jeremy Goss

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23207>
_______________________________________

From report at bugs.python.org  Wed Mar 18 05:03:30 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 18 Mar 2015 04:03:30 +0000
Subject: [issue23695] idiom for clustering a data series into n-length groups
In-Reply-To: <1426637882.4.0.0938827316057.issue23695@psf.upfronthosting.co.za>
Message-ID: <1426651410.77.0.332907844021.issue23695@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23695>
_______________________________________

From report at bugs.python.org  Wed Mar 18 05:27:57 2015
From: report at bugs.python.org (Doug Rohm)
Date: Wed, 18 Mar 2015 04:27:57 +0000
Subject: [issue19351] python msi installers - silent mode
In-Reply-To: <1382450332.98.0.946317884841.issue19351@psf.upfronthosting.co.za>
Message-ID: <1426652877.94.0.360026067854.issue19351@psf.upfronthosting.co.za>


Doug Rohm added the comment:

I realize this hasn't been commented on for a long time, but I'm noticing the same issue trying to do a silent install with the 3.4.3 x64 windows installer.  The 3.4.2 x64 windows installer worked perfectly fine, but I can't seem to get the registry and add/remove entries to work with 3.4.3.  I tried fiddling with ALLUSERS="1" and ALLUSERS="" and the results were the same.

Were there any changes to the windows x64 installer from 3.4.2 to 3.4.3 in regards to this issue?

----------
nosy: +drohm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19351>
_______________________________________

From report at bugs.python.org  Wed Mar 18 05:36:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 18 Mar 2015 04:36:55 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1426653415.04.0.0486094319733.issue23688@psf.upfronthosting.co.za>


Martin Panter added the comment:

I would say that the current patch looks correct enough, in that it would still get the correct lengths when a memoryview() object is passed in. The zlib module?s crc32() function and compress() method already seem to support arbitrary bytes-like objects.

But to make GzipFile.write() also accept arbitrary bytes-like objects, you probably only need to change the code calculating the length to something like:

with memoryview(data) as view:
    length = view.nbytes

# Go on to call compress(data) and crc32(data)

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Wed Mar 18 05:59:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 18 Mar 2015 04:59:49 +0000
Subject: [issue19495] context manager for measuring duration of blocks of code
In-Reply-To: <1383588451.25.0.545990193953.issue19495@psf.upfronthosting.co.za>
Message-ID: <1426654789.37.0.858690449635.issue19495@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19495>
_______________________________________

From report at bugs.python.org  Wed Mar 18 06:09:47 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Mar 2015 05:09:47 +0000
Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces
In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za>
Message-ID: <1426655387.2.0.701167165657.issue23441@psf.upfronthosting.co.za>


R. David Murray added the comment:

The CLI is a UI.  We're using readline facilities (ie: "the terminal") to improve it.  And people cut and paste from the interactive terminal, so I think the presence of tab characters is a negative from that perspective as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23441>
_______________________________________

From report at bugs.python.org  Wed Mar 18 06:10:00 2015
From: report at bugs.python.org (Paddy McCarthy)
Date: Wed, 18 Mar 2015 05:10:00 +0000
Subject: [issue23695] idiom for clustering a data series into n-length groups
In-Reply-To: <1426637882.4.0.0938827316057.issue23695@psf.upfronthosting.co.za>
Message-ID: <1426655400.98.0.647621659507.issue23695@psf.upfronthosting.co.za>


Paddy McCarthy added the comment:

Hmmm. It seems that the problem isn't to do with the fact that it works, or how to apply it; the problem is with *how* it works. 

Making it an idiom means that too many will use it without knowing why it works which could lead to later maintenance issues. I think a better description of how it works may be needed for the docs.

Unfortunately my description of the how at http://paddy3118.blogspot.co.uk/2012/12/that-grouping-by-zipiter-trick-explained.html was not written with the docs in mind, but you are welcome to any part or the whole, for the Python docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23695>
_______________________________________

From report at bugs.python.org  Wed Mar 18 07:33:05 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Wed, 18 Mar 2015 06:33:05 +0000
Subject: [issue23698] Fix documentation for multiprocessing.Manager
Message-ID: <1426660385.12.0.0389729473261.issue23698@psf.upfronthosting.co.za>


New submission from Anand B Pillai:

multiprocessing.Manager seems to have an inconsistency in behaviour/documentation or both.

The behaviour inconsistency is documented in the attached test script which should run for both Python2 and Python3. 

Briefly, multiprocessing.managers.BaseManager class starts a Python subprocess only after a call to its "start" method. Whereas its subclass, multiprocessing.managers.SyncManager does at the time of object creation. This is undocumented and against the base classe's documented behaviour.

Also, the SyncManager is more commonly advertised via the facade multiprocessing.Manager() which is again at odds with the BaseManager's interface in that,

1. It takes no arguments (Python2) and different arguments (Python 3).
2. You can't call "start" on it but you can call "start" if you initialize it via multiprocessing.managers.SyncManager directly (!)
3. Even if you can't call a start on it, apparently you can shut it down via a call to "shutdown"
4. When you try to start such a manager you get a strange AssertionError complaining the state is not INITIAL. A better error is required here.

Please find the attached file for all the sequence of tests done.

Suggested changes are,

1. Fix the inconsistency in documented behaviour between SyncManager and its base class. Either don't start the child process upon object creation or document it.
2. Fix the inconsistency in SyncManager object creation interface and behaviour via "mulitprocessing.Manager()" and directly via "multiprocessing.managers.SyncManager(...)" . One should be able to start both objects cleanly. And the former should also take the address argument. If not document it properly.
3. The AssertionError when trying to start the SyncManager object obtained via a call to "multiprocessing.Manager()" looks like a bug. It should be fixed - otherwise a bette error should be raised and documentation updated.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: mp_test.py
messages: 238379
nosy: docs at python, pythonhacker
priority: normal
severity: normal
status: open
title: Fix documentation for multiprocessing.Manager
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38537/mp_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23698>
_______________________________________

From report at bugs.python.org  Wed Mar 18 07:33:43 2015
From: report at bugs.python.org (Frank Millman)
Date: Wed, 18 Mar 2015 06:33:43 +0000
Subject: [issue23677] Mention dict and set comps in library reference
In-Reply-To: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za>
Message-ID: <1426660423.06.0.112807205291.issue23677@psf.upfronthosting.co.za>


Frank Millman added the comment:

Lists and tuples are described like this -

class list([iterable]) 
Lists may be constructed in several ways:
[...]

class tuple([iterable]) 
Tuples may be constructed in a number of ways:
[...]

I think a similar approach to Dicts and Sets could make sense -

class dict([**kwarg])
Dicts may be constructed in a number of ways:

- Using a pair of braces to denote the empty dict: {}
- Placing a comma-separated list of key: value pairs within braces: {'jack': 4098, 'sjoerd': 4127} or {4098: 'jack', 4127: 'sjoerd'}
- Using a dict comprehension: {k: v for k, v in iterable}
- Using the dict() built-in: dict() or dict(**kwarg) or dict(mapping, **kwarg) or dict(iterable, **kwarg) 

Add a new example -

f = {k: v for k, v in [('one', 1), ('two', 2), ('three', 3)]}


class set([iterable])
class frozenset([iterable])
Sets may be constructed in a number of ways:

- Non-empty sets (not frozensets) can be created by placing a comma-separated list of elements within braces, for example: {'jack', 'sjoerd'}
- Non-empty sets (not frozensets) can be created by using a set comprehension: {x for x in iterable}
- Using the set() or frozenset() built-in


The 'bullet-point' construction is not really necessary for Sets, but it would make it consistent with the others.


A related point (I can raise a separate Issue if preferred) -

For me, the power of comprehensions lies in their 'filtering' ability. This is not mentioned in any of the above examples, so newcomers may wonder why they should use them.

We don't want to make the examples too complicated. Maybe just add 'if ...' to the example, and provide a cross-reference to Section 6.2.4 in the Language Reference (Displays for lists, sets and dictionaries).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23677>
_______________________________________

From report at bugs.python.org  Wed Mar 18 08:03:01 2015
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 18 Mar 2015 07:03:01 +0000
Subject: [issue23694] PEP 475: handle EINTR in fileutils.c
In-Reply-To: <1426640034.3.0.904207692052.issue23694@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM39x_sOufXNMpn_mfUQEUvaMCi4uZn4hmSe3jy4SXFhNg@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

LGTM.

Note that dup() cannot fail with EINTR, it is non-blocking: dup2() can
fail, because f the target FD is open, it has to close it, but not
dup().

See e.g. this man page from my Debian:
       EINTR  The dup2() or dup3() call was interrupted by a signal;
see signal(7).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23694>
_______________________________________

From report at bugs.python.org  Wed Mar 18 09:50:09 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Mar 2015 08:50:09 +0000
Subject: [issue23207] logging.basicConfig does not validate keyword arguments
In-Reply-To: <1420813239.75.0.476507944816.issue23207@psf.upfronthosting.co.za>
Message-ID: <20150318085006.7239.30498@psf.io>


Roundup Robot added the comment:

New changeset d3b420807a86 by Vinay Sajip in branch '3.4':
Issue #23207: Improved kwarg validation.
https://hg.python.org/cpython/rev/d3b420807a86

New changeset 7ff0d7b50b36 by Vinay Sajip in branch 'default':
Issue #23207: merged fix from 3.4.
https://hg.python.org/cpython/rev/7ff0d7b50b36

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23207>
_______________________________________

From report at bugs.python.org  Wed Mar 18 09:50:25 2015
From: report at bugs.python.org (Vadim Markovtsev)
Date: Wed, 18 Mar 2015 08:50:25 +0000
Subject: [issue14073] allow per-thread atexit()
In-Reply-To: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za>
Message-ID: <1426668625.24.0.450696118355.issue14073@psf.upfronthosting.co.za>


Vadim Markovtsev added the comment:

I agree that there must be some way to join the threads before exiting, with a callback or anything else. Currently, my thread pool implementation has to monkey patch sys.exit and register SIGINT handler to shutdown itself and avoid the hangup (100+ LoC to cover all possible exceptions). I am working on a big framework and demanding from users to call "thread pool shutdown" function before exit would be yet another thing they must remember and just impossible in some cases. It would ruin the whole abstraction. Python is not C, you know.

----------
nosy: +Vadim Markovtsev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14073>
_______________________________________

From report at bugs.python.org  Wed Mar 18 09:51:59 2015
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 18 Mar 2015 08:51:59 +0000
Subject: [issue23500] Argument Clinic: multiple macro definition
In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za>
Message-ID: <1426668719.29.0.988489131495.issue23500@psf.upfronthosting.co.za>


Larry Hastings added the comment:

What do you think of this approach?  Now a "Destination" object behaves like an array of text accumulators.  If you ask for one that doesn't exist it's created for you.  When the Destination is dumped, the output from each accumulator is joined together, like buffer[0] + buffer[1] + buffer[2].  (You can even specify negative indices, if you want text that goes *before* the default text accumulator.)

With this approach, all the #ifndef stanzas are at the end of the emitted text.

----------
Added file: http://bugs.python.org/file38538/larry.ac_multiple_macro_definitions.diff.3.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23500>
_______________________________________

From report at bugs.python.org  Wed Mar 18 09:52:18 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Wed, 18 Mar 2015 08:52:18 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1426668738.75.0.0757435516758.issue23688@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

Thanks everyone for the lively discussion ! 

I like Serhiy's idea of making write work with arbitrary objects supporting the buffer protocol. In fact, I noticed before that GzipFile.write misbehaves with array.array input. It pretends to accept that, but it'll use len(data) for calculating the zip file metadata so reading from the file will later fail. I was assuming then that fixing that would be too complicated for a rather exotic usecase, but now that I see how simple it really is I think it should be done.

As for the concrete implementation, I guess an isinstance(data, bytes) check to speed up treatment of the most common input is a good idea, but I am not convinced that bytearray deserves the same attention.

Regarding memoryview.cast('B') vs memoryview.nbytes, I see Serhiy's point of keeping the patch size smaller. Personally though, I find use of nbytes much more self-explanatory than cast('B') the purpose of which was not immediately obvious to me. So I would opt for better readability of the final code rather than optimizing patch size, but I would be ok with either solution since it is not about the essence of the patch anyway.

Finally, the bug I report in issue21560 would be fixed as a side-effect of this patch here (because trying to get a memoryview from str would throw an early TypeError). Still, I think it would be a good idea to try to write to the wrapped fileobj *before* updating self.size and self.crc to be protected from unforeseen errors. So maybe we could include that change in the patch here ?

With all that the final code section could look like this:

        if isinstance(data, bytes):
            length = len(data)
        else:
            data = memoryview(data)
            length = data.nbytes

        if length > 0:
            self.fileobj.write( self.compress.compress(data) )
            self.size = self.size + length
            self.crc = zlib.crc32(data, self.crc) & 0xffffffff
            self.offset += length

        return length

One remaining detail then would be whether one would want to catch the TypeError possibly raised by the memoryview constructor to turn it into something less confusing (after all many users will not know what a memoryview has to do with all this). The above code would throw (with str input for example):

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/home/wolma/gzip-bug/Lib/gzip.py", line 340, in write
    data = memoryview(data)
TypeError: memoryview: a bytes-like object is required, not 'str'

Maybe, this could be turned into:

TypeError: must be bytes / bytes-like object, not 'str'  ?

to be consistent with the corresponding error in 'wt' mode ?

Let me know which of the above options you favour and I'll provide a new patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Wed Mar 18 09:55:20 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 08:55:20 +0000
Subject: [issue23694] PEP 475: handle EINTR in fileutils.c
In-Reply-To: <CAH_1eM39x_sOufXNMpn_mfUQEUvaMCi4uZn4hmSe3jy4SXFhNg@mail.gmail.com>
Message-ID: <CAMpsgwYqUCRX_vrcNhtPhC23G2SHL2nsEvneUaCrqYbAEQVqHA@mail.gmail.com>


STINNER Victor added the comment:

Charles-Fran?ois Natali added the comment:
> Note that dup() cannot fail with EINTR, it is non-blocking: dup2() can
> fail, because f the target FD is open, it has to close it, but not
> dup().

Oh right, I misread the manual page. I will leave _Py_dup() unchanged.
Thanks for the review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23694>
_______________________________________

From report at bugs.python.org  Wed Mar 18 10:00:48 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Mar 2015 09:00:48 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <20150318090043.63570.50893@psf.io>


Roundup Robot added the comment:

New changeset 88e1151e8e02 by Serhiy Storchaka in branch 'default':
Issue #2211: Updated the implementation of the http.cookies.Morsel class.
https://hg.python.org/cpython/rev/88e1151e8e02

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Wed Mar 18 10:02:36 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Wed, 18 Mar 2015 09:02:36 +0000
Subject: [issue23689] Memory leak in Modules/sre_lib.h
In-Reply-To: <1426611380.23.0.46113718722.issue23689@psf.upfronthosting.co.za>
Message-ID: <1426669356.78.0.996650099492.issue23689@psf.upfronthosting.co.za>


Evgeny Kapun added the comment:

This patch doesn't fix the issue. The problem is that the list starting with state->repeat doesn't necessarily contains all repeat contexts that are allocated. Indeed, here [1] and here [2] repeat contexts are temporarily removed from the list. If the match procedure terminates abruptly, they are not added back.

[1] https://hg.python.org/cpython/file/c89f7c34e356/Modules/sre_lib.h#l963
[2] https://hg.python.org/cpython/file/c89f7c34e356/Modules/sre_lib.h#l1002

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23689>
_______________________________________

From report at bugs.python.org  Wed Mar 18 10:05:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Mar 2015 09:05:18 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426669518.04.0.471019366231.issue2211@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Renamed __copy__ to copy, because copy.copy() doesn't need these changes and original report was about the copy() method.

Thank you for your contribution and for your responsiveness Demian.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Wed Mar 18 10:20:26 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 18 Mar 2015 09:20:26 +0000
Subject: [issue23697] Module level map & submit for concurrent.futures
In-Reply-To: <1426648820.66.0.638337601517.issue23697@psf.upfronthosting.co.za>
Message-ID: <1426670426.14.0.342311555283.issue23697@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +bquinlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23697>
_______________________________________

From report at bugs.python.org  Wed Mar 18 10:21:56 2015
From: report at bugs.python.org (Martin Sekera)
Date: Wed, 18 Mar 2015 09:21:56 +0000
Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces
In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za>
Message-ID: <1426670516.2.0.379002119564.issue23441@psf.upfronthosting.co.za>


Martin Sekera added the comment:

But tab characters are rendered by the terminal into spaces. During stdout processing, when the term encounters a \t (0x09), it inserts (into the term buffer that is displayed to the user) as many spaces (0x20) as needed to move the cursor to the nearest tab-stop (setterm --tabs will display them for you). Why do we need to duplicate this inside Python?

There are no copy&paste issues either, try it yourself: when you copy and paste tab-indented text from the terminal, your text will contain spaces instead of tabs (at whatever width you have your terminal tab stops configured for).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23441>
_______________________________________

From report at bugs.python.org  Wed Mar 18 10:23:07 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 09:23:07 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>
Message-ID: <1426670587.12.0.00982047718453.issue23648@psf.upfronthosting.co.za>


STINNER Victor added the comment:

test_eintr.py: program to check if a Python function can fail with InterruptedError. Modify func() to test a function. (The program checks select.select(), currently it fails with InterruptedError.)

----------
Added file: http://bugs.python.org/file38539/test_eintr.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Wed Mar 18 10:24:24 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 18 Mar 2015 09:24:24 +0000
Subject: [issue23698] Fix documentation for multiprocessing.Manager
In-Reply-To: <1426660385.12.0.0389729473261.issue23698@psf.upfronthosting.co.za>
Message-ID: <1426670664.08.0.220654885926.issue23698@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +davin, sbt
versions:  -Python 3.2, Python 3.3, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23698>
_______________________________________

From report at bugs.python.org  Wed Mar 18 10:26:09 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Wed, 18 Mar 2015 09:26:09 +0000
Subject: [issue2636] Adding a new regex module (compatible with re)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1426670769.36.0.703764329652.issue2636@psf.upfronthosting.co.za>


Changes by Evgeny Kapun <abacabadabacaba at gmail.com>:


----------
nosy: +abacabadabacaba

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Wed Mar 18 10:36:52 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 18 Mar 2015 09:36:52 +0000
Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces
In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za>
Message-ID: <1426671412.22.0.516518036743.issue23441@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think it would really depend on the particular terminal. Sakura (a Unix terminal using the VTE library, like Gnome Terminal) copied the tab literally:

$ printf 'tab\ttab|sp   sp\n'
tab	tab|sp   sp  <== COPIED
$ hexdump -C
tab	tab|sp   sp  <== PASTED
00000000  74 61 62 09 74 61 62 7c  73 70 20 20 20 73 70 0a  |tab.tab|sp   sp.|
00000010

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23441>
_______________________________________

From report at bugs.python.org  Wed Mar 18 10:47:19 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 09:47:19 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>
Message-ID: <1426672039.32.0.262518702664.issue23648@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I found a way to get a list of functions which can fail with EINTR: search for TEMP_FAILURE_RETRY in the source code of the glibc. TEMP_FAILURE_RETRY:
https://www.gnu.org/software/libc/manual/html_node/Interrupted-Primitives.html#Interrupted-Primitives

Following functions are called with TEMP_FAILURE_RETRY (in glibc code, doc and examples):

- accept, send, sendfile, sendmsg, accept4, connect, sendto, recvmsg
- write, writev, read, readv, pwrite
- fdatasync, fsync
- waitpid
- select, poll
- mq_send, mq_timedsend, mq_receive, mq_timedreceive
- clock_nanosleep, timer_settime, nanosleep
- posix_fallocate
- sem_wait, sem_timedwait, sem_trywait
- aio_suspend
- fcntl(F_SETLK)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Wed Mar 18 10:48:09 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 09:48:09 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>
Message-ID: <1426672089.08.0.00180701100339.issue23648@psf.upfronthosting.co.za>


STINNER Victor added the comment:

stat manual page of SCO documentation says that stat() can fail with EINTR, but I don't see this error in latest Linux manual page. I tested manually, and I failed to see stat() failing with InterruptedError.
http://uw714doc.sco.com/en/man/html.2/stat.2.html

So only a few system calls on the filesystem (open, read, write, close, fsync, ...) can fail with EINTR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Wed Mar 18 10:51:24 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 09:51:24 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426672284.55.0.541226732196.issue2211@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> New changeset 88e1151e8e02 by Serhiy Storchaka in branch 'default':
> Issue #2211: Updated the implementation of the http.cookies.Morsel class.
> https://hg.python.org/cpython/rev/88e1151e8e02

I don't understand why, but test_pickle started to fail with this change.

See 3.x buildbots for errors. Example:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/5858/steps/test/logs/stdio

----------
nosy: +haypo
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Wed Mar 18 11:08:40 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 10:08:40 +0000
Subject: [issue23694] PEP 475: handle EINTR in fileutils.c
In-Reply-To: <1426634378.41.0.681041892498.issue23694@psf.upfronthosting.co.za>
Message-ID: <1426673320.51.0.352003110169.issue23694@psf.upfronthosting.co.za>


STINNER Victor added the comment:

All functions which can fail with EINTR now retries the function on EINTR. I close the issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23694>
_______________________________________

From report at bugs.python.org  Wed Mar 18 11:25:42 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 10:25:42 +0000
Subject: [issue23685] Fix usage of PyMODINIT_FUNC
In-Reply-To: <1426587233.23.0.965954561717.issue23685@psf.upfronthosting.co.za>
Message-ID: <1426674342.22.0.0824128618827.issue23685@psf.upfronthosting.co.za>


STINNER Victor added the comment:

builtin_modules.patch looks complex. It can be simplified by using the Py_BUILD_CORE define.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23685>
_______________________________________

From report at bugs.python.org  Wed Mar 18 11:31:25 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Mar 2015 10:31:25 +0000
Subject: [issue23694] PEP 475: handle EINTR in fileutils.c
In-Reply-To: <1426634378.41.0.681041892498.issue23694@psf.upfronthosting.co.za>
Message-ID: <20150318103122.16922.71832@psf.io>


Roundup Robot added the comment:

New changeset ed25e945cdc2 by Victor Stinner in branch 'default':
Issue #23694: Handle EINTR in _Py_open() and _Py_fopen_obj()
https://hg.python.org/cpython/rev/ed25e945cdc2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23694>
_______________________________________

From report at bugs.python.org  Wed Mar 18 11:31:25 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Mar 2015 10:31:25 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <20150318103122.16922.39164@psf.io>


Roundup Robot added the comment:

New changeset 4fb829f8c04d by Victor Stinner in branch 'default':
Issue #23605: Fix os.walk(topdown=True), don't cache entry.is_symlink() because
https://hg.python.org/cpython/rev/4fb829f8c04d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Wed Mar 18 11:33:48 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 10:33:48 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1426674828.11.0.910089402544.issue23605@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I commited fast_bottom-up.patch to fix the regression of os.walk().

> Could you please add a test based on my example (i.e. converting symlinks to a directory during walking) and may be other (creating new directory and adding it to the dirs list)?

Sorry, I'm not interested to write new tests.

> Is it worth to mention in the os.walk() doc that topdown=False can be faster?

I didn't touch the doc yet.

I keep the issue open a few weeks to see if someone is interested to optimize os.walk() further, write new tests, enhance the doc, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Wed Mar 18 11:38:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Mar 2015 10:38:20 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426675100.34.0.262347286147.issue2211@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Victor.

This patch should fix pickling/unpickling.

Interesting, we should check all other cases when instance attribute was converted to a property. They are potentially break pickle compatibility.

----------
Added file: http://bugs.python.org/file38540/http_cookies_morsel_pickle.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Wed Mar 18 11:40:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Mar 2015 10:40:38 +0000
Subject: [issue23456] asyncio: add missing @coroutine decorators
In-Reply-To: <1423778398.48.0.478290226002.issue23456@psf.upfronthosting.co.za>
Message-ID: <20150318104035.114150.11828@psf.io>


Roundup Robot added the comment:

New changeset 6f7ed6e95ea8 by Victor Stinner in branch '3.4':
Issue #23456: Add missing @coroutine decorators in asyncio
https://hg.python.org/cpython/rev/6f7ed6e95ea8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23456>
_______________________________________

From report at bugs.python.org  Wed Mar 18 11:41:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 10:41:08 +0000
Subject: [issue23456] asyncio: add missing @coroutine decorators
In-Reply-To: <1423778398.48.0.478290226002.issue23456@psf.upfronthosting.co.za>
Message-ID: <1426675268.22.0.755422763319.issue23456@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23456>
_______________________________________

From report at bugs.python.org  Wed Mar 18 11:48:31 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 10:48:31 +0000
Subject: [issue23353] generator bug with exception: tstate->exc_value is not
 cleared after an except block
In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za>
Message-ID: <1426675711.93.0.801848685387.issue23353@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Antoine: exctests.patch looks good to me, can you commit it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23353>
_______________________________________

From report at bugs.python.org  Wed Mar 18 11:49:40 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 10:49:40 +0000
Subject: [issue23333] asyncio: add a new Protocol.connection_failed() method
In-Reply-To: <1422398373.98.0.602533535675.issue23333@psf.upfronthosting.co.za>
Message-ID: <1426675780.41.0.588419084274.issue23333@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The consensus looks to be to reject this feature, so I close the issue. I already commits a compromise: log an error in debug mode.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23333>
_______________________________________

From report at bugs.python.org  Wed Mar 18 11:51:20 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 10:51:20 +0000
Subject: [issue22861] [2.7] ssl._dnsname_match() and unicode
In-Reply-To: <1415883149.43.0.395853503644.issue22861@psf.upfronthosting.co.za>
Message-ID: <1426675880.79.0.682207611316.issue22861@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm not convinced myself that it's a real issue, and I worked around it in Trollius, so I close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22861>
_______________________________________

From report at bugs.python.org  Wed Mar 18 11:52:20 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 10:52:20 +0000
Subject: [issue22984] test_json.test_endless_recursion(): "Fatal Python error:
 Cannot recover from stack overflow." on x86 XP-4 3.x buildbot
In-Reply-To: <1417554919.08.0.0786746086364.issue22984@psf.upfronthosting.co.za>
Message-ID: <1426675940.75.0.663039576307.issue22984@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The buildbot is broken, it cannot compile anymore. So I just close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22984>
_______________________________________

From report at bugs.python.org  Wed Mar 18 11:53:04 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 10:53:04 +0000
Subject: [issue22971] test_pickle: "Fatal Python error: Cannot recover from
 stack overflow." on FreeBSD buildbot
In-Reply-To: <1417430775.66.0.180152689809.issue22971@psf.upfronthosting.co.za>
Message-ID: <1426675984.68.0.371721925887.issue22971@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I didn't see this failure recently, so I just close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22971>
_______________________________________

From report at bugs.python.org  Wed Mar 18 11:53:36 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 10:53:36 +0000
Subject: [issue21735]
 test_threading.test_main_thread_after_fork_from_nonmain_thread()
 hangs on the FreeBSD 10 buildbot
In-Reply-To: <1402585767.95.0.817144752371.issue21735@psf.upfronthosting.co.za>
Message-ID: <1426676016.93.0.472319530963.issue21735@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I didn't see this error recently, so I just close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21735>
_______________________________________

From report at bugs.python.org  Wed Mar 18 11:55:27 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 10:55:27 +0000
Subject: [issue23303] test_license_exists_at_url() of test_site fails on "x86
 XP-4 3.4" buildbot
In-Reply-To: <1421962203.05.0.381123323956.issue23303@psf.upfronthosting.co.za>
Message-ID: <1426676127.96.0.965987157125.issue23303@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Builder x86 XP-4 3.4 is green again. I close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23303>
_______________________________________

From report at bugs.python.org  Wed Mar 18 11:56:04 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 10:56:04 +0000
Subject: [issue20600] test_create_server_ssl_verify_failed() failure on "PPC64
 AIX 3.x" buildbot
In-Reply-To: <1392136781.96.0.859159765022.issue20600@psf.upfronthosting.co.za>
Message-ID: <1426676164.02.0.242292348892.issue20600@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Since nobody looks to care of AIX, I just close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20600>
_______________________________________

From report at bugs.python.org  Wed Mar 18 12:00:29 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 11:00:29 +0000
Subject: [issue12304] expose signalfd(2) in the signal module
In-Reply-To: <1307660456.9.0.497118052372.issue12304@psf.upfronthosting.co.za>
Message-ID: <1426676429.1.0.258132452872.issue12304@psf.upfronthosting.co.za>


STINNER Victor added the comment:

signalfd is very useful for event-driven frameworks like Twisted or asyncio. asyncio doesn't use it, and I didn't see any request to support it yet. asyncio uses signal.set_wakeup_fd() which looks to be enough, and it is now available on all platforms (including Windows).

I'm not interested to write the structure to unpack the 128 bytes structure of signalfd, nor to update my patch. I just close the issue.

Reopen the issue or open a new one if you are interested by signalfd.

Anyway, there is already a third-party Python module providing signalfd() for Python 2 and Python 3:
https://pypi.python.org/pypi/python-signalfd

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12304>
_______________________________________

From report at bugs.python.org  Wed Mar 18 12:01:03 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 11:01:03 +0000
Subject: [issue12500] Skip test_ssl.test_connect_ex() on connection error
In-Reply-To: <1309854315.46.0.604055413236.issue12500@psf.upfronthosting.co.za>
Message-ID: <1426676463.06.0.448697504399.issue12500@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> @Victor would you like to follow up with your patch?

No. So I just close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12500>
_______________________________________

From report at bugs.python.org  Wed Mar 18 12:02:04 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 11:02:04 +0000
Subject: [issue14555] clock_gettime/settime/getres: Add more clock identifiers
In-Reply-To: <1334183358.11.0.0329195703165.issue14555@psf.upfronthosting.co.za>
Message-ID: <1426676524.77.0.789687685789.issue14555@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm no more really interested to add these identifiers. So I just close the issue.

----------
nosy: +haypo
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14555>
_______________________________________

From report at bugs.python.org  Wed Mar 18 12:03:32 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 11:03:32 +0000
Subject: [issue15599] test_threaded_import fails sporadically on Windows and
 FreeBSD
In-Reply-To: <1344473974.14.0.584788696764.issue15599@psf.upfronthosting.co.za>
Message-ID: <1426676612.5.0.826881060889.issue15599@psf.upfronthosting.co.za>


STINNER Victor added the comment:

No real activity on this issue. Since the issue is sporadic and I'm not interested to work on it, I just close the issue as out of date.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15599>
_______________________________________

From report at bugs.python.org  Wed Mar 18 12:04:56 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 11:04:56 +0000
Subject: [issue15612] Rewrite StringIO to use the _PyUnicodeWriter API
In-Reply-To: <1344565830.56.0.384034899089.issue15612@psf.upfronthosting.co.za>
Message-ID: <1426676696.24.0.97859731199.issue15612@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm no more interested to work on this issue, and it's not clear that _PyUnicodeWriter is always faster. Switch from a list to _PyUnicodeWriter on a specific event would make the code much more complex. I prefer to just close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15612>
_______________________________________

From report at bugs.python.org  Wed Mar 18 12:05:54 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 11:05:54 +0000
Subject: [issue17515] Add sys.setasthook() to allow to use a custom AST
 optimizer
In-Reply-To: <1363913891.37.0.731570464343.issue17515@psf.upfronthosting.co.za>
Message-ID: <1426676754.0.0.607475643852.issue17515@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm not more interested to work on my astoptimizer project, and nobody looks to need sys.setasthook(), so I prefer to close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17515>
_______________________________________

From report at bugs.python.org  Wed Mar 18 12:06:35 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 11:06:35 +0000
Subject: [issue17628] str==str: compare the first character before calling
 memcmp()
In-Reply-To: <1365024552.84.0.0461498193244.issue17628@psf.upfronthosting.co.za>
Message-ID: <1426676795.87.0.907695144396.issue17628@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The benefit of any change is unclear. I'm not more interested to work on such optimization, so I just close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17628>
_______________________________________

From report at bugs.python.org  Wed Mar 18 12:07:14 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 11:07:14 +0000
Subject: [issue18507] import_init() should not use Py_FatalError() but return
 an error
In-Reply-To: <1374269951.83.0.221076121181.issue18507@psf.upfronthosting.co.za>
Message-ID: <1426676834.57.0.864272472879.issue18507@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue was more a reminder for myself (TODO list). I'm no more interested to work on the issue, so I just close it.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18507>
_______________________________________

From report at bugs.python.org  Wed Mar 18 12:07:40 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 11:07:40 +0000
Subject: [issue19233] test_io.test_interrupted_write_retry_text() hangs on
 Solaris 10 and FreeBSD 7.2
In-Reply-To: <1381582482.49.0.0638429802819.issue19233@psf.upfronthosting.co.za>
Message-ID: <1426676860.23.0.304508276067.issue19233@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19233>
_______________________________________

From report at bugs.python.org  Wed Mar 18 12:08:09 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 11:08:09 +0000
Subject: [issue19654] test_tkinter sporadic skipped on "x86 Tiger 3.x" buildbot
In-Reply-To: <1384868641.08.0.388268151531.issue19654@psf.upfronthosting.co.za>
Message-ID: <1426676889.81.0.650394093695.issue19654@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19654>
_______________________________________

From report at bugs.python.org  Wed Mar 18 12:08:59 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 11:08:59 +0000
Subject: [issue19748] test_time failures on AIX
In-Reply-To: <1385296584.36.0.0978202241603.issue19748@psf.upfronthosting.co.za>
Message-ID: <1426676939.36.0.934111280654.issue19748@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm no more interested to work on this issue, I prefer to close it.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19748>
_______________________________________

From report at bugs.python.org  Wed Mar 18 12:21:16 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Mar 2015 11:21:16 +0000
Subject: [issue23500] Argument Clinic: multiple macro definition
In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za>
Message-ID: <1426677676.86.0.0574554593485.issue23500@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This looks as generalization of my patch. It produces the same output. I left comments on Rietveld, but in any case the patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23500>
_______________________________________

From report at bugs.python.org  Wed Mar 18 13:06:57 2015
From: report at bugs.python.org (Alexei Romanov)
Date: Wed, 18 Mar 2015 12:06:57 +0000
Subject: [issue23689] Memory leak in Modules/sre_lib.h
In-Reply-To: <1426611380.23.0.46113718722.issue23689@psf.upfronthosting.co.za>
Message-ID: <1426680417.34.0.554817709398.issue23689@psf.upfronthosting.co.za>


Changes by Alexei Romanov <drednout.by at gmail.com>:


----------
nosy: +alexei.romanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23689>
_______________________________________

From report at bugs.python.org  Wed Mar 18 13:42:39 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 12:42:39 +0000
Subject: [issue20114] Sporadic failure of test_semaphore_tracker() of
 test_multiprocessing_forkserver on FreeBSD 9 buildbot
In-Reply-To: <1388751464.62.0.0417954391884.issue20114@psf.upfronthosting.co.za>
Message-ID: <1426682559.58.0.187353473022.issue20114@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20114>
_______________________________________

From report at bugs.python.org  Wed Mar 18 13:44:24 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 12:44:24 +0000
Subject: [issue19816] test.regrtest: use tracemalloc to detect memory leaks?
In-Reply-To: <1385574567.13.0.658193624023.issue19816@psf.upfronthosting.co.za>
Message-ID: <1426682664.67.0.85929023423.issue19816@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm no more interested to work on this issue. regrtest.patch is unstable, and I don't know how to make it more reliable. Antoine's allocation counter is enough right now.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19816>
_______________________________________

From report at bugs.python.org  Wed Mar 18 13:44:59 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 12:44:59 +0000
Subject: [issue11410] Use GCC visibility attrs in PyAPI_*
In-Reply-To: <1299391945.72.0.037942723875.issue11410@psf.upfronthosting.co.za>
Message-ID: <1426682699.57.0.674850741458.issue11410@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also the issue #19569: "Use __attribute__((deprecated)) to warn usage of deprecated functions and macros".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11410>
_______________________________________

From report at bugs.python.org  Wed Mar 18 13:46:37 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 12:46:37 +0000
Subject: [issue19564] test_context() of test_multiprocessing_spawn hangs on
 "x86 Gentoo Non-Debug 3.x" buildbot
In-Reply-To: <1384293991.33.0.242857083412.issue19564@psf.upfronthosting.co.za>
Message-ID: <1426682797.5.0.189869580705.issue19564@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I didn't see this sporadic failure recently. The buildbot is now offline. I close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19564>
_______________________________________

From report at bugs.python.org  Wed Mar 18 13:59:13 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Mar 2015 12:59:13 +0000
Subject: [issue19428] marshal: error cases are not documented
In-Reply-To: <1383007288.06.0.856513082934.issue19428@psf.upfronthosting.co.za>
Message-ID: <20150318125910.70030.71402@psf.io>


Roundup Robot added the comment:

New changeset 1e4605542ac4 by Victor Stinner in branch 'default':
Issue #19428: Handle PyMarshal_Read*() errors in run_pyc_file()
https://hg.python.org/cpython/rev/1e4605542ac4

New changeset acb4d43955f6 by Victor Stinner in branch '3.4':
Issue #19428: Document that PyMarshal_ReadLongFromFile() and
https://hg.python.org/cpython/rev/acb4d43955f6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19428>
_______________________________________

From report at bugs.python.org  Wed Mar 18 13:59:21 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 12:59:21 +0000
Subject: [issue19428] marshal: error cases are not documented
In-Reply-To: <1383007288.06.0.856513082934.issue19428@psf.upfronthosting.co.za>
Message-ID: <1426683561.52.0.597200096809.issue19428@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19428>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:00:25 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 13:00:25 +0000
Subject: [issue12568] Add functions to get the width in columns of a character
In-Reply-To: <1310683436.9.0.375403702242.issue12568@psf.upfronthosting.co.za>
Message-ID: <1426683625.96.0.607698924656.issue12568@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Since no consensus was found on the definition of the function, and this issue has no activity since 2 years, I close the issue as out of date.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12568>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:06:20 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Mar 2015 13:06:20 +0000
Subject: [issue12155] queue example doesn't stop worker threads
In-Reply-To: <1306146151.16.0.671326557503.issue12155@psf.upfronthosting.co.za>
Message-ID: <20150318130616.7263.8604@psf.io>


Roundup Robot added the comment:

New changeset b44ec269abda by Victor Stinner in branch 'default':
Issue #12155: Fix queue doc example to join threads
https://hg.python.org/cpython/rev/b44ec269abda

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12155>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:06:34 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 13:06:34 +0000
Subject: [issue12155] queue example doesn't stop worker threads
In-Reply-To: <1306146151.16.0.671326557503.issue12155@psf.upfronthosting.co.za>
Message-ID: <1426683994.63.0.824267669429.issue12155@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.5 -Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12155>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:15:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Mar 2015 13:15:07 +0000
Subject: [issue11726] clarify that linecache only works on files that can be
 decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <20150318131504.63576.18156@psf.io>


Roundup Robot added the comment:

New changeset 51341af466e3 by Victor Stinner in branch '3.4':
Issue #11726: clarify linecache doc: linecache is written to cache Python
https://hg.python.org/cpython/rev/51341af466e3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11726>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:19:56 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Mar 2015 13:19:56 +0000
Subject: [issue11726] clarify that linecache only works on files that can be
 decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <20150318131950.11896.22985@psf.io>


Roundup Robot added the comment:

New changeset 01cb2107cbc3 by Victor Stinner in branch '3.4':
Issue #11726: Fix linecache example in the doc
https://hg.python.org/cpython/rev/01cb2107cbc3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11726>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:21:11 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 13:21:11 +0000
Subject: [issue11726] clarify that linecache only works on files that can be
 decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <1426684871.6.0.646684831804.issue11726@psf.upfronthosting.co.za>


STINNER Victor added the comment:

4 years to fix this minor documentation issue, I feel ashamed...

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11726>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:21:20 2015
From: report at bugs.python.org (Davin Potts)
Date: Wed, 18 Mar 2015 13:21:20 +0000
Subject: [issue23698] Fix documentation for multiprocessing.Manager
In-Reply-To: <1426660385.12.0.0389729473261.issue23698@psf.upfronthosting.co.za>
Message-ID: <1426684880.83.0.474957031225.issue23698@psf.upfronthosting.co.za>


Davin Potts added the comment:

This is closely related to issue23510.  The two issues are reacting to the same underlying inconsistency though in this issue the problem is more generally (and clearly) stated whereas issue23510 is more concerned with the consequences to using these as Context Managers.

The solution that gets implemented here should address both issues.

As mentioned in issue23510, I have a working fix though am looking for ways to further minimize the impact to existing code that uses Manager/SyncManager -- simply documenting the current inconsistent state is inadequate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23698>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:21:51 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Mar 2015 13:21:51 +0000
Subject: [issue23624] str.center inconsistent with format "^"
In-Reply-To: <1425966835.2.0.36838695627.issue23624@psf.upfronthosting.co.za>
Message-ID: <1426684911.28.0.0640477346659.issue23624@psf.upfronthosting.co.za>


R. David Murray added the comment:

I would write it:

   "{:^{width}}".format(title, width=width)

By the way, in case it isn't clear, we acknowledge that in a perfect world center would work "right", but our judgment is that the pain of fixing it outweighs the benefit.  Our collective consensus on that could be shifted, but someone would have to be willing to argue it convincingly to the community (ie: not on the bug tracker).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23624>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:22:37 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 13:22:37 +0000
Subject: [issue20574] Implement incremental decoder for cp65001
In-Reply-To: <1391951905.18.0.272262636483.issue20574@psf.upfronthosting.co.za>
Message-ID: <1426684957.18.0.213750591875.issue20574@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20574>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:25:42 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 13:25:42 +0000
Subject: [issue20614] test.script_helper should copy SYSTEMROOT environment
 variable for __cleanenv=True
In-Reply-To: <1392287165.51.0.792620084259.issue20614@psf.upfronthosting.co.za>
Message-ID: <1426685142.6.0.96627043398.issue20614@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> There is a single test which uses __cleanenv=True: test_hash.

The test pass on Windows and this issue is old. I prefer to simplify close it.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20614>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:27:27 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 13:27:27 +0000
Subject: [issue20717] test_4_daemon_threads() fails randomly on "x86 Windows
 Server 2003 [SB] 3.x"
In-Reply-To: <1392973435.96.0.316031564004.issue20717@psf.upfronthosting.co.za>
Message-ID: <1426685247.06.0.93791423726.issue20717@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20717>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:27:54 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 13:27:54 +0000
Subject: [issue20719] testPythonOrg() of test_robotparser fails with the new
 www.python.org website
In-Reply-To: <1392974419.69.0.59989767526.issue20719@psf.upfronthosting.co.za>
Message-ID: <1426685274.94.0.678409962942.issue20719@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue has been worked around.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20719>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:28:53 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 13:28:53 +0000
Subject: [issue21644] Optimize bytearray(int) constructor to use calloc()
In-Reply-To: <1401740758.16.0.943124117891.issue21644@psf.upfronthosting.co.za>
Message-ID: <1426685333.05.0.468643161974.issue21644@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm not interested to work on this optimization, so I just close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21644>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:29:40 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 13:29:40 +0000
Subject: [issue21734] compilation of the _ctypes module fails on OpenIndiana:
 ffi_prep_closure_loc symbol is missing
In-Reply-To: <1402585546.51.0.39402588592.issue21734@psf.upfronthosting.co.za>
Message-ID: <1426685380.2.0.640179270922.issue21734@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue has been fixed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21734>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:30:34 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 13:30:34 +0000
Subject: [issue21788] Rework Python finalization
In-Reply-To: <1402990827.19.0.536092854004.issue21788@psf.upfronthosting.co.za>
Message-ID: <1426685434.05.0.883949629077.issue21788@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue was more a reminder for myself (TODO). I'm no more interesting to work on it, so I close it.

The Python finalization is very fragile. I prefer to not touch it again :-p

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21788>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:31:59 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 13:31:59 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1426685519.14.0.0215161818086.issue21955@psf.upfronthosting.co.za>


STINNER Victor added the comment:

What's the status of this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21955>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:38:38 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Mar 2015 13:38:38 +0000
Subject: [issue23687] Stacktrace identifies wrong line in multiline list
 comprehension
In-Reply-To: <1426599885.89.0.0578302709073.issue23687@psf.upfronthosting.co.za>
Message-ID: <1426685918.25.0.106796180378.issue23687@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is a specific case of the more general problem discussed in issue 12458.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Tracebacks should contain the first line of continuation lines

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23687>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:39:04 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Mar 2015 13:39:04 +0000
Subject: [issue12458] Tracebacks should contain the first line of continuation
 lines
In-Reply-To: <1309499207.17.0.676241559437.issue12458@psf.upfronthosting.co.za>
Message-ID: <1426685944.53.0.427791460065.issue12458@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +ers81239

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12458>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:40:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Mar 2015 13:40:35 +0000
Subject: [issue19569] Use __attribute__((deprecated)) to warn usage of
 deprecated functions and macros
In-Reply-To: <1384348276.8.0.185765824651.issue19569@psf.upfronthosting.co.za>
Message-ID: <1426686035.28.0.147519155856.issue19569@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19569>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:42:20 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 13:42:20 +0000
Subject: [issue22333] test_threaded_import.test_parallel_meta_path() failed on
 x86 Windows7 3.x
In-Reply-To: <1409815961.59.0.0325236414674.issue22333@psf.upfronthosting.co.za>
Message-ID: <1426686140.53.0.0633512852032.issue22333@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I didn't see this failure recently, I close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22333>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:42:37 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Mar 2015 13:42:37 +0000
Subject: [issue22181] os.urandom() should use Linux 3.17 getrandom() syscall
In-Reply-To: <1407713563.4.0.264701036097.issue22181@psf.upfronthosting.co.za>
Message-ID: <20150318134233.63578.15012@psf.io>


Roundup Robot added the comment:

New changeset 1fc32bf069ff by Victor Stinner in branch 'default':
Issue #22181: On Linux, os.urandom() now uses the new getrandom() syscall if
https://hg.python.org/cpython/rev/1fc32bf069ff

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22181>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:42:56 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 13:42:56 +0000
Subject: [issue22181] os.urandom() should use Linux 3.17 getrandom() syscall
In-Reply-To: <1407713563.4.0.264701036097.issue22181@psf.upfronthosting.co.za>
Message-ID: <1426686176.01.0.0460655239329.issue22181@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22181>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:43:22 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 18 Mar 2015 13:43:22 +0000
Subject: [issue23699] Add a macro to ease writing rich comparisons
Message-ID: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

Rich comparison functions of many builtin types include a block of boilerplate which can be consolidated in a macro. The macro can be useful for third-party extensions as well as CPython itself.

See this e-mail for a longer write-up: https://mail.python.org/pipermail/python-ideas/2015-March/032564.html

----------
files: 0001-Define-Py_RICHCOMPARE-to-ease-writing-rich-compariso.patch
keywords: patch
messages: 238441
nosy: encukou
priority: normal
severity: normal
status: open
title: Add a macro to ease writing rich comparisons
type: enhancement
Added file: http://bugs.python.org/file38541/0001-Define-Py_RICHCOMPARE-to-ease-writing-rich-compariso.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23699>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:44:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 13:44:08 +0000
Subject: [issue22521] ctypes compilation fails on FreeBSD: Undefined symbol
 "ffi_call_win32"
In-Reply-To: <1412075710.94.0.470127563443.issue22521@psf.upfronthosting.co.za>
Message-ID: <1426686248.6.0.407639243679.issue22521@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FreeBSD 6.4 buildbot is broken (hg update fails), FreeBSD 7.2 is offline. I close the issue.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22521>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:45:11 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 18 Mar 2015 13:45:11 +0000
Subject: [issue23699] Add a macro to ease writing rich comparisons
In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za>
Message-ID: <1426686311.32.0.770286801735.issue23699@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

Here is a patch that uses the macro in all the places it can help.

----------
Added file: http://bugs.python.org/file38542/0002-Use-Py_RICHCOMPARE-in-rich-comparisons.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23699>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:48:49 2015
From: report at bugs.python.org (Tim Graham)
Date: Wed, 18 Mar 2015 13:48:49 +0000
Subject: [issue22931] cookies with square brackets in value
In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za>
Message-ID: <1426686529.71.0.884505379875.issue22931@psf.upfronthosting.co.za>


Changes by Tim Graham <timograham at gmail.com>:


----------
nosy: +Tim.Graham

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22931>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:51:18 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 18 Mar 2015 13:51:18 +0000
Subject: [issue23696] zipimport: chain ImportError to OSError
In-Reply-To: <1426640296.98.0.079062899559.issue23696@psf.upfronthosting.co.za>
Message-ID: <1426686678.95.0.27309105649.issue23696@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +twouters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23696>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:54:52 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 18 Mar 2015 13:54:52 +0000
Subject: [issue23624] str.center inconsistent with format "^"
In-Reply-To: <1425966835.2.0.36838695627.issue23624@psf.upfronthosting.co.za>
Message-ID: <1426686892.9.0.860804378754.issue23624@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I agree with David: It's unfortunate, but too late to change.

FWIW, since the goal is to replace just str.center, I'd write this as:

def my_center(s, width):
    return format(s, '^' + str(width))

As soon as you're mixing in other formatting, then str.center couldn't have been used, anyway, so no sense bringing all of str.format to bear on the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23624>
_______________________________________

From report at bugs.python.org  Wed Mar 18 14:55:39 2015
From: report at bugs.python.org (koobs)
Date: Wed, 18 Mar 2015 13:55:39 +0000
Subject: [issue22521] ctypes compilation fails on FreeBSD: Undefined symbol
 "ffi_call_win32"
In-Reply-To: <1412075710.94.0.470127563443.issue22521@psf.upfronthosting.co.za>
Message-ID: <1426686939.03.0.192662778462.issue22521@psf.upfronthosting.co.za>


koobs added the comment:

FWIW, see #23042

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22521>
_______________________________________

From report at bugs.python.org  Wed Mar 18 15:08:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 14:08:17 +0000
Subject: [issue22521] ctypes compilation fails on FreeBSD: Undefined symbol
 "ffi_call_win32"
In-Reply-To: <1412075710.94.0.470127563443.issue22521@psf.upfronthosting.co.za>
Message-ID: <1426687697.33.0.787741307327.issue22521@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution: out of date -> duplicate
superseder:  -> Python 2.7.9 ctypes module doesn't build on FreeBSD x86

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22521>
_______________________________________

From report at bugs.python.org  Wed Mar 18 15:08:20 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 14:08:20 +0000
Subject: [issue23042] ctypes module doesn't build on FreeBSD x86
In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za>
Message-ID: <1426687700.01.0.87121196336.issue23042@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Python 3.4 and 3.5 are also affected: I marked issue #22521 as a duplicate of this issue.

----------
nosy: +haypo
title: Python 2.7.9 ctypes module doesn't build on FreeBSD x86 -> ctypes module doesn't build on FreeBSD x86
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23042>
_______________________________________

From report at bugs.python.org  Wed Mar 18 15:16:24 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 14:16:24 +0000
Subject: [issue23654] infinite loop in faulthandler._stack_overflow
In-Reply-To: <1426200687.84.0.455927631723.issue23654@psf.upfronthosting.co.za>
Message-ID: <1426688184.47.0.203043546846.issue23654@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> It occurs to me that the right way to deal with this is with
> __attribute__ ((optimize ("no-optimize-sibling-calls")))
> on the function where it matters (stack_overflow()).

Can you please write a patch for that with the right #ifdef to only add it to ICC?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23654>
_______________________________________

From report at bugs.python.org  Wed Mar 18 15:28:34 2015
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 18 Mar 2015 14:28:34 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426688914.88.0.195782688331.issue2211@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Thanks for the follow up Serhiy, LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Wed Mar 18 15:39:27 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Mar 2015 14:39:27 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1426689567.69.0.475136757489.issue22906@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Wed Mar 18 15:49:42 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Mar 2015 14:49:42 +0000
Subject: [issue22906] PEP 479: Change StopIteration handling inside generators
In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za>
Message-ID: <1426690182.46.0.221007824875.issue22906@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Bumped to release blocker so we make sure to look at this at the PyCon sprints, if not before. (I'm assuming Larry's not taking release blocker literally for the 3.5 alphas)

As Neil notes, this patch needs some explicit tests for the new behaviour when the future flag is set.

>From a docs point of view, the changes to the language reference itself currently seem surprisingly small, but I haven't looked through in detail to see where other updates might be needed, or how the already modified section could be better updated to account for the impact of the __future__ directive (the current update there doesn't mention that the behaviour is in the process of changing)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22906>
_______________________________________

From report at bugs.python.org  Wed Mar 18 15:54:23 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 Mar 2015 14:54:23 +0000
Subject: [issue15787] PEP 3121, 384 Refactoring
In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za>
Message-ID: <1426690463.9.0.14140852755.issue15787@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15787>
_______________________________________

From report at bugs.python.org  Wed Mar 18 16:13:14 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Mar 2015 15:13:14 +0000
Subject: [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1426691594.05.0.415636667402.issue12855@psf.upfronthosting.co.za>


R. David Murray added the comment:

SMRUTI: \f is the python escape code for the ASCII formfeed character.  It is the handling of that ASCII character (among others) that this issue is discussing.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Wed Mar 18 16:17:06 2015
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Wed, 18 Mar 2015 15:17:06 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
Message-ID: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>


New submission from Bohuslav "Slavek" Kabrda:

This bug is very similar to #18879, the only difference is that _TemporaryFileWrapper.__iter__ is the problem (in #18879, __getattr__ was fixed, but __iter__ was not). The real world use case that helped me find this bug is at the bottom of this report, this is a simple reproducer:


>>> import tempfile
>>> for l in tempfile.NamedTemporaryFile(mode='a+b'):
...     print(l)
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: readline of closed file


I'm attaching a patch that fixes this (+ testcase).

Note: I actually discovered this while using


>>> from urllib.request import urlopen
>>> for l in urlopen('ftp://<some_ftp>'):
...     print(l)
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: readline of closed file


Opening FTP uses urllib.response, which in turn uses tempfile._TemporaryFileWrapper, which makes this example fail.

----------
components: Library (Lib)
files: python-3.4-tempfile-iter.patch
keywords: patch
messages: 238451
nosy: bkabrda
priority: normal
severity: normal
status: open
title: tempfile.NamedTemporaryFile can close too early if used as iterator
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38543/python-3.4-tempfile-iter.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Wed Mar 18 16:23:28 2015
From: report at bugs.python.org (=?utf-8?q?Mat=C4=9Bj_Stuchl=C3=ADk?=)
Date: Wed, 18 Mar 2015 15:23:28 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426692208.78.0.864583997277.issue23700@psf.upfronthosting.co.za>


Changes by Mat?j Stuchl?k <matej.stuchlik at gmail.com>:


----------
nosy: +sYnfo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Wed Mar 18 16:24:18 2015
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 18 Mar 2015 15:24:18 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426692258.32.0.467601420719.issue23700@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman, georg.brandl, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Wed Mar 18 16:31:50 2015
From: report at bugs.python.org (Davin Potts)
Date: Wed, 18 Mar 2015 15:31:50 +0000
Subject: [issue23042] ctypes module doesn't build on FreeBSD x86
In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za>
Message-ID: <1426692710.82.0.505516786966.issue23042@psf.upfronthosting.co.za>


Davin Potts added the comment:

To provide supporting information, using the i386 release of FreeBSD 10.1:

* ctypes fails to build with the latest from Python 2.7 branch with the message:

    build/temp.freebsd-10.1-RELEASE-i386-2.7-pydebug/usr/home/davin/pycoredev/cpython/Modules/_ctypes/libffi/src/x86/ffi.o: In function `ffi_prep_closure_loc':
    /usr/home/davin/pycoredev/cpython/Modules/_ctypes/libffi/src/x86/ffi.c:677: undefined reference to `ffi_closure_FASTCALL'
    /usr/home/davin/pycoredev/cpython/Modules/_ctypes/libffi/src/x86/ffi.c:683: undefined reference to `ffi_closure_THISCALL'
    /usr/home/davin/pycoredev/cpython/Modules/_ctypes/libffi/src/x86/ffi.c:689: undefined reference to `ffi_closure_STDCALL'
    /usr/bin/ld: build/lib.freebsd-10.1-RELEASE-i386-2.7-pydebug/_ctypes.so: hidden symbol `ffi_closure_FASTCALL' isn't defined
    /usr/bin/ld: final link failed: Nonrepresentable section on output
    cc: error: linker command failed with exit code 1 (use -v to see invocation)
    
    ...
    
    Failed to build these modules:
    _ctypes                                               


* Note that the above failure message was described in issue22521 by @Danya.Alexeyevsky

* ctypes also fails to build with the latest from default/3.5 branch with the very same message


Apparently the compilation failure messages differ between FreeBSD 8.3 and 10.1 (both i386).

----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23042>
_______________________________________

From report at bugs.python.org  Wed Mar 18 16:33:52 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Mar 2015 15:33:52 +0000
Subject: [issue23695] idiom for clustering a data series into n-length groups
In-Reply-To: <1426637882.4.0.0938827316057.issue23695@psf.upfronthosting.co.za>
Message-ID: <1426692832.72.0.434657822358.issue23695@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think it would be both helpful and sufficient to add a gloss, perhaps something like: "this passes zip ``n`` references to the *same* iterator, which means zip calls that single iterator ``n`` times for each tuple it creates; zip thus outputs tuples consisting of ``n`` length chunks from the iterator ``s``".

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23695>
_______________________________________

From report at bugs.python.org  Wed Mar 18 16:34:33 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Mar 2015 15:34:33 +0000
Subject: [issue23699] Add a macro to ease writing rich comparisons
In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za>
Message-ID: <1426692873.67.0.481294762765.issue23699@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Such macros would make the code cleaner. But I don't think it should be provided as a part of API. It isn't hard to implement, it doesn't provide essential functionality of Python, and it doesn't hide implementation defined CPython internals. I rather consider it as private helper, so it should be declared with underscore prefix and inside the #ifndef Py_LIMITED_API/#endif block.

I don't see an implementation of Py_RICHCOMPARE. In any case I think it would be better to make the op parameter the first parameter.

----------
components: +Interpreter Core
nosy: +serhiy.storchaka
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23699>
_______________________________________

From report at bugs.python.org  Wed Mar 18 16:47:42 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 15:47:42 +0000
Subject: [issue23042] ctypes module doesn't build on FreeBSD x86
In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za>
Message-ID: <1426693662.86.0.635963518909.issue23042@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23042>
_______________________________________

From report at bugs.python.org  Wed Mar 18 16:48:51 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Mar 2015 15:48:51 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426693731.75.0.296898920872.issue23700@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka
stage:  -> patch review
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Wed Mar 18 16:53:44 2015
From: report at bugs.python.org (Zach Byrne)
Date: Wed, 18 Mar 2015 15:53:44 +0000
Subject: [issue21955] ceval.c: implement fast path for integers with a single
 digit
In-Reply-To: <1405069827.92.0.324101531394.issue21955@psf.upfronthosting.co.za>
Message-ID: <1426694024.27.0.224996334135.issue21955@psf.upfronthosting.co.za>


Zach Byrne added the comment:

I haven't looked at it since I posted the benchmark results for 21955_2.patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21955>
_______________________________________

From report at bugs.python.org  Wed Mar 18 17:04:19 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Mar 2015 16:04:19 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <20150318160414.24234.36426@psf.io>


Roundup Robot added the comment:

New changeset d68cc584bc7d by Serhiy Storchaka in branch 'default':
Restored backward compatibility of pickling http.cookies.Morsel.  It was
https://hg.python.org/cpython/rev/d68cc584bc7d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Wed Mar 18 17:24:36 2015
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 18 Mar 2015 16:24:36 +0000
Subject: [issue23699] Add a macro to ease writing rich comparisons
In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za>
Message-ID: <1426695876.0.0.338894786392.issue23699@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23699>
_______________________________________

From report at bugs.python.org  Wed Mar 18 17:33:47 2015
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 18 Mar 2015 16:33:47 +0000
Subject: [issue23699] Add a macro to ease writing rich comparisons
In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za>
Message-ID: <1426696427.06.0.177373970118.issue23699@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan at bytereef.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23699>
_______________________________________

From report at bugs.python.org  Wed Mar 18 17:42:06 2015
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 18 Mar 2015 16:42:06 +0000
Subject: [issue23699] Add a macro to ease writing rich comparisons
In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za>
Message-ID: <1426696926.73.0.207619147548.issue23699@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Hmm, at least for the version at

  https://mail.python.org/pipermail/python-ideas/2015-March/032564.html

I'm not sure if the optimizer will produce the same
code as for the switch statement.  Did you look at
the asm?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23699>
_______________________________________

From report at bugs.python.org  Wed Mar 18 17:47:07 2015
From: report at bugs.python.org (Joshua J Cogliati)
Date: Wed, 18 Mar 2015 16:47:07 +0000
Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler
 if using ccache
In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za>
Message-ID: <1426697227.28.0.459587710939.issue8027@psf.upfronthosting.co.za>


Joshua J Cogliati added the comment:

Here is an example to use to test for this bug.

Proper use on my computer (PYTHONPATH may need adjusting on other systems):

Python2:
cd small_example
python setup.py build_ext build install --prefix=`pwd`
export PYTHONPATH=`pwd`/lib64/python2.7/site-packages
cd test
python a_test.py
# outputs 3

Python3:
cd small_example
python3 setup.py build_ext build install --prefix=`pwd`
export PYTHONPATH=`pwd`/lib64/python3.4/site-packages
cd test
python3 a_test.py
# outputs 3

Clean files:
rm -Rf build/ lib/ lib64/ example/example.py example/example_wrap.cpp *~ example/__pycache__/

Check for the bug:
export CXX="env BAR=FOO g++"
or
export CXX="ccache g++"
etc
Then run either the Python2 or Python3 test, and it will fail if this bug has not been fixed.

----------
nosy: +haypo
Added file: http://bugs.python.org/file38544/small_example.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8027>
_______________________________________

From report at bugs.python.org  Wed Mar 18 17:51:06 2015
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 18 Mar 2015 16:51:06 +0000
Subject: [issue23655] Memory corruption using pickle over pipe to subprocess
In-Reply-To: <1426229235.01.0.332656133041.issue23655@psf.upfronthosting.co.za>
Message-ID: <1426697466.52.0.8789153293.issue23655@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23655>
_______________________________________

From report at bugs.python.org  Wed Mar 18 17:51:10 2015
From: report at bugs.python.org (Claudiu Popa)
Date: Wed, 18 Mar 2015 16:51:10 +0000
Subject: [issue23701] Drop extraneous comment from winreg.QueryValue's
 docstring
Message-ID: <1426697470.53.0.824194712699.issue23701@psf.upfronthosting.co.za>


New submission from Claudiu Popa:

winreg.QueryValue's docstring has an "interesting" comment at the end:

"But the underlying API call doesn't return the type, Lame Lame Lame, DONT USE THIS!!!"

The documentation (https://docs.python.org/3.4/library/winreg.html#winreg.QueryValue) already mentions the shortcomings of QueryValue. This comment should be removed or at least rewritten in a more serious note.

----------
components: Library (Lib)
files: drop_winreg_string.patch
keywords: patch
messages: 238459
nosy: Claudiu.Popa, loewis, steve.dower
priority: low
severity: normal
status: open
title: Drop extraneous comment from winreg.QueryValue's docstring
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38545/drop_winreg_string.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23701>
_______________________________________

From report at bugs.python.org  Wed Mar 18 18:06:42 2015
From: report at bugs.python.org (Wei Wu)
Date: Wed, 18 Mar 2015 17:06:42 +0000
Subject: [issue23566] RFE: faulthandler.register() should support file
 descriptors
In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za>
Message-ID: <1426698402.49.0.337354766797.issue23566@psf.upfronthosting.co.za>


Wei Wu added the comment:

The updated patch refactored test code a little bit according to the latest review comments by Victor.

----------
Added file: http://bugs.python.org/file38546/issue23566_fd_tests_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23566>
_______________________________________

From report at bugs.python.org  Wed Mar 18 18:09:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Mar 2015 17:09:31 +0000
Subject: [issue23699] Add a macro to ease writing rich comparisons
In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za>
Message-ID: <1426698571.32.0.533621250921.issue23699@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

gcc -O3 generates a sequence of cmp-s.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23699>
_______________________________________

From report at bugs.python.org  Wed Mar 18 18:18:06 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 18 Mar 2015 17:18:06 +0000
Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler
 if using ccache
In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za>
Message-ID: <1426699086.78.0.186147851982.issue8027@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Does the patch fix things on Mac OS X and Linux?

----------
assignee: eric.araujo -> 
versions:  -3rd party, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8027>
_______________________________________

From report at bugs.python.org  Wed Mar 18 18:25:10 2015
From: report at bugs.python.org (Joshua J Cogliati)
Date: Wed, 18 Mar 2015 17:25:10 +0000
Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler
 if using ccache
In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za>
Message-ID: <1426699510.12.0.939916374218.issue8027@psf.upfronthosting.co.za>


Joshua J Cogliati added the comment:

> Does the patch fix things on Mac OS X and Linux?

So far as I can tell, the code in question is to do something so
that CXX variables like:
export CXX="env BAR=FOO g++"
work better.  However, it is broken for that case, and since it has
been broken since at least python 2.6, I think it would be better to
remove the code, as my patches do.

My patches do fix things for me on Linux on my case of:
export CXX="ccache g++"
and do not make things worse for the env case.

I can check on OSX if you like.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8027>
_______________________________________

From report at bugs.python.org  Wed Mar 18 18:36:25 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Mar 2015 17:36:25 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426700185.4.0.222092826822.issue2211@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Wed Mar 18 18:42:37 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Mar 2015 17:42:37 +0000
Subject: [issue22334] test_tcl.test_split() fails on "x86 FreeBSD 7.2 3.x"
 buildbot
In-Reply-To: <1409817164.01.0.942615937948.issue22334@psf.upfronthosting.co.za>
Message-ID: <1426700557.94.0.181828558607.issue22334@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I suggest just upgrade Tcl on this buildbot to release version of 8.6. Or downgrade to release version of 8.5 or 8.4. No need to test Python with beta version of Tcl. 8.6.0 was released years ago.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22334>
_______________________________________

From report at bugs.python.org  Wed Mar 18 19:33:26 2015
From: report at bugs.python.org (Paul Moore)
Date: Wed, 18 Mar 2015 18:33:26 +0000
Subject: [issue23701] Drop extraneous comment from winreg.QueryValue's
 docstring
In-Reply-To: <1426697470.53.0.824194712699.issue23701@psf.upfronthosting.co.za>
Message-ID: <1426703606.95.0.703127106844.issue23701@psf.upfronthosting.co.za>


Changes by Paul Moore <p.f.moore at gmail.com>:


----------
nosy: +paul.moore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23701>
_______________________________________

From report at bugs.python.org  Wed Mar 18 20:01:54 2015
From: report at bugs.python.org (Paddy McCarthy)
Date: Wed, 18 Mar 2015 19:01:54 +0000
Subject: [issue23695] idiom for clustering a data series into n-length groups
In-Reply-To: <1426637882.4.0.0938827316057.issue23695@psf.upfronthosting.co.za>
Message-ID: <1426705314.74.0.703763895546.issue23695@psf.upfronthosting.co.za>


Paddy McCarthy added the comment:

I like R. David Murray's suggestion, but I am also aware of how it works and so cannot judge how it would look to the intermediate Python programmer who knows iterators and zip, but is new to this grouper; (who I think should be the target audience).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23695>
_______________________________________

From report at bugs.python.org  Wed Mar 18 20:13:00 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 18 Mar 2015 19:13:00 +0000
Subject: [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <1426705980.89.0.0928975984441.issue11468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Raymond, in the meanwhile can the proposed patch be applied?
I don't think it's necessary to show that you need to import a module in order to test its functions.  Using modules also has the disadvantage that people might not know what result to expect if they are not familiar with the functions of that module (e.g. the only functions that return True/False in the math module seem to be isfinite/isnan/isinf), whereas everyone should know basic string methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11468>
_______________________________________

From report at bugs.python.org  Wed Mar 18 20:16:16 2015
From: report at bugs.python.org (Joshua J Cogliati)
Date: Wed, 18 Mar 2015 19:16:16 +0000
Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler
 if using ccache
In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za>
Message-ID: <1426706176.18.0.275070512555.issue8027@psf.upfronthosting.co.za>


Joshua J Cogliati added the comment:

On OSX 10.10.1,

With the small_example, and with python 3.4.3 and:
$ export CXX="env BAR=FOO g++"
$ python3 setup.py build_ext build install --prefix=`pwd`
running build_ext
building '_example' extension
swigging example/example.i to example/example_wrap.cpp
swig -python -c++ -py3 -Iexample -o example/example_wrap.cpp example/example.i
creating build
creating build/temp.macosx-10.10-x86_64-3.4
creating build/temp.macosx-10.10-x86_64-3.4/example
gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Iexample -I/Users/jjc/bug/py343/include/python3.4m -c example/example_wrap.cpp -o build/temp.macosx-10.10-x86_64-3.4/example/example_wrap.o
gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Iexample -I/Users/jjc/bug/py343/include/python3.4m -c example/example.cxx -o build/temp.macosx-10.10-x86_64-3.4/example/example.o
creating build/lib.macosx-10.10-x86_64-3.4
creating build/lib.macosx-10.10-x86_64-3.4/example
env -bundle -undefined dynamic_lookup build/temp.macosx-10.10-x86_64-3.4/example/example_wrap.o build/temp.macosx-10.10-x86_64-3.4/example/example.o -o build/lib.macosx-10.10-x86_64-3.4/example/_example.so
env: illegal option -- b
usage: env [-i] [name=value ...] [utility [argument ...]]
error: command 'env' failed with exit status 1


So, as is, python 3.4.3 fails.

With the same as above, but with the fix-distutils-342.patch applied:
$ export CXX="env BAR=FOO g++"
$ python3 setup.py build_ext build install --prefix=`pwd`
running build_ext
building '_example' extension
swigging example/example.i to example/example_wrap.cpp
swig -python -c++ -py3 -Iexample -o example/example_wrap.cpp example/example.i
creating build
creating build/temp.macosx-10.10-x86_64-3.4
creating build/temp.macosx-10.10-x86_64-3.4/example
gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Iexample -I/Users/jjc/bug/py343m/include/python3.4m -c example/example_wrap.cpp -o build/temp.macosx-10.10-x86_64-3.4/example/example_wrap.o
gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Iexample -I/Users/jjc/bug/py343m/include/python3.4m -c example/example.cxx -o build/temp.macosx-10.10-x86_64-3.4/example/example.o
creating build/lib.macosx-10.10-x86_64-3.4
creating build/lib.macosx-10.10-x86_64-3.4/example
gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.10-x86_64-3.4/example/example_wrap.o build/temp.macosx-10.10-x86_64-3.4/example/example.o -o build/lib.macosx-10.10-x86_64-3.4/example/_example.so
running build
running build_py
copying example/example.py -> build/lib.macosx-10.10-x86_64-3.4/example
copying example/__init__.py -> build/lib.macosx-10.10-x86_64-3.4/example
running install
running install_lib
creating /Users/jjc/bug/small_example/lib
creating /Users/jjc/bug/small_example/lib/python3.4
creating /Users/jjc/bug/small_example/lib/python3.4/site-packages
creating /Users/jjc/bug/small_example/lib/python3.4/site-packages/example
copying build/lib.macosx-10.10-x86_64-3.4/example/__init__.py -> /Users/jjc/bug/small_example/lib/python3.4/site-packages/example
copying build/lib.macosx-10.10-x86_64-3.4/example/_example.so -> /Users/jjc/bug/small_example/lib/python3.4/site-packages/example
copying build/lib.macosx-10.10-x86_64-3.4/example/example.py -> /Users/jjc/bug/small_example/lib/python3.4/site-packages/example
byte-compiling /Users/jjc/bug/small_example/lib/python3.4/site-packages/example/__init__.py to __init__.cpython-34.pyc
byte-compiling /Users/jjc/bug/small_example/lib/python3.4/site-packages/example/example.py to example.cpython-34.pyc
running install_egg_info
Writing /Users/jjc/bug/small_example/lib/python3.4/site-packages/example-0.5-py3.4.egg-info
$ export PYTHONPATH=`pwd`/lib/python3.4/site-packages
$ cd test
$ python3 a_test.py 
3


So with the patch, it succeeds.  

> Does the patch fix things on Mac OS X and Linux?
Yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8027>
_______________________________________

From report at bugs.python.org  Wed Mar 18 20:48:34 2015
From: report at bugs.python.org (Paul Sokolovsky)
Date: Wed, 18 Mar 2015 19:48:34 +0000
Subject: [issue23702] docs.python.org/3/howto/descriptor.html still refers to
 "unbound methods"
Message-ID: <1426708114.47.0.635748134131.issue23702@psf.upfronthosting.co.za>


New submission from Paul Sokolovsky:

Under https://docs.python.org/3/howto/descriptor.html#functions-and-methods , there're several references to unbound methods (including in expected output from the interpreter).

As known, unbound methods are gone in Python3, so seeing those are confusing. (I didn't sharply know that unbound methods are gone from Py3, so was pretty confused by the examples there, comparing them with actual output of Cpython 3.4).

----------
assignee: docs at python
components: Documentation
messages: 238468
nosy: docs at python, pfalcon
priority: normal
severity: normal
status: open
title: docs.python.org/3/howto/descriptor.html still refers to "unbound methods"
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23702>
_______________________________________

From report at bugs.python.org  Wed Mar 18 21:28:03 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 18 Mar 2015 20:28:03 +0000
Subject: [issue23702] docs.python.org/3/howto/descriptor.html still refers to
 "unbound methods"
In-Reply-To: <1426708114.47.0.635748134131.issue23702@psf.upfronthosting.co.za>
Message-ID: <1426710483.29.0.760306937302.issue23702@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23702>
_______________________________________

From report at bugs.python.org  Wed Mar 18 21:36:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Mar 2015 20:36:59 +0000
Subject: [issue23545] Turn on extra warnings on GCC
In-Reply-To: <1425076183.98.0.20319163057.issue23545@psf.upfronthosting.co.za>
Message-ID: <1426711019.42.0.225387450777.issue23545@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm not well experienced with autoconf. Here is my attempt.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file38547/configure_extra_warnings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23545>
_______________________________________

From report at bugs.python.org  Wed Mar 18 22:25:13 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Mar 2015 21:25:13 +0000
Subject: [issue23353] generator bug with exception: tstate->exc_value is not
 cleared after an except block
In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za>
Message-ID: <20150318212509.4207.7468@psf.io>


Roundup Robot added the comment:

New changeset ac43268da908 by Antoine Pitrou in branch '3.4':
Issue #23353: improve exceptions tests for generators
https://hg.python.org/cpython/rev/ac43268da908

New changeset b29342f53174 by Antoine Pitrou in branch 'default':
Issue #23353: improve exceptions tests for generators
https://hg.python.org/cpython/rev/b29342f53174

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23353>
_______________________________________

From report at bugs.python.org  Wed Mar 18 22:25:33 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Mar 2015 21:25:33 +0000
Subject: [issue23353] generator bug with exception: tstate->exc_value is not
 cleared after an except block
In-Reply-To: <1422626936.33.0.830645939586.issue23353@psf.upfronthosting.co.za>
Message-ID: <1426713933.68.0.602235106301.issue23353@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23353>
_______________________________________

From report at bugs.python.org  Wed Mar 18 22:26:00 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Mar 2015 21:26:00 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <1426713960.83.0.368385638487.issue23632@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Do you want to review the patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Wed Mar 18 22:29:02 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 21:29:02 +0000
Subject: [issue23353] generator bug with exception: tstate->exc_value is not
 cleared after an except block
In-Reply-To: <1426713933.73.0.551304297703.issue23353@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZoF_i5qDX9RFhBk2AOZVdHKNmC0==jZYE-yZSyKvJhgA@mail.gmail.com>


STINNER Victor added the comment:

Thanks Antoine!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23353>
_______________________________________

From report at bugs.python.org  Wed Mar 18 22:33:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Mar 2015 21:33:27 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <1426714407.06.0.136887905714.issue23632@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Wed Mar 18 22:35:47 2015
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Wed, 18 Mar 2015 21:35:47 +0000
Subject: [issue17799] settrace docs are wrong about "c_call" events
In-Reply-To: <1366428980.14.0.538502026896.issue17799@psf.upfronthosting.co.za>
Message-ID: <1426714547.07.0.649015929696.issue17799@psf.upfronthosting.co.za>


Changes by Maries Ionel Cristian <ionel.mc at gmail.com>:


----------
nosy: +ionel.mc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17799>
_______________________________________

From report at bugs.python.org  Wed Mar 18 22:37:46 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 18 Mar 2015 21:37:46 +0000
Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler
 if using ccache
In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za>
Message-ID: <1426714666.3.0.271446653296.issue8027@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Thanks for the patch and the testing.  I?m not in a position to commit the patch; if no core developer does it in the coming week, feel free to ping python-dev to get action.  You can also hop onto IRC at any time and see if someone here can finish this.

----------
components:  -Distutils2
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8027>
_______________________________________

From report at bugs.python.org  Wed Mar 18 22:45:44 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Mar 2015 21:45:44 +0000
Subject: [issue22903] unittest creates non-picklable errors
In-Reply-To: <1416426552.76.0.140329555318.issue22903@psf.upfronthosting.co.za>
Message-ID: <1426715144.3.0.310710497129.issue22903@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file38548/pickle_module_import_failure.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22903>
_______________________________________

From report at bugs.python.org  Wed Mar 18 22:45:52 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Mar 2015 21:45:52 +0000
Subject: [issue22903] unittest creates non-picklable errors
In-Reply-To: <1416426552.76.0.140329555318.issue22903@psf.upfronthosting.co.za>
Message-ID: <1426715152.27.0.0360721975324.issue22903@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22903>
_______________________________________

From report at bugs.python.org  Wed Mar 18 22:52:57 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Mar 2015 21:52:57 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <1426715577.3.0.603225541899.issue23632@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I left few nitpicks on Rietveld, but in general the patch LGTM.

Oh, needed a documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Wed Mar 18 23:11:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 Mar 2015 22:11:18 +0000
Subject: [issue22903] unittest creates non-picklable errors
In-Reply-To: <1416426552.76.0.140329555318.issue22903@psf.upfronthosting.co.za>
Message-ID: <1426716678.97.0.719695216933.issue22903@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

classname is not used in _make_failed_test().

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22903>
_______________________________________

From report at bugs.python.org  Wed Mar 18 23:16:28 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Mar 2015 22:16:28 +0000
Subject: [issue23309] Hang on interpreter shutdown if daemon thread prints to
 stdout
In-Reply-To: <1422107560.4.0.0145420431804.issue23309@psf.upfronthosting.co.za>
Message-ID: <1426716988.87.0.33135363981.issue23309@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch with tests.

----------
Added file: http://bugs.python.org/file38549/bufio_lock_finalizing_fatal_error2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23309>
_______________________________________

From report at bugs.python.org  Wed Mar 18 23:30:56 2015
From: report at bugs.python.org (Robert Collins)
Date: Wed, 18 Mar 2015 22:30:56 +0000
Subject: [issue22903] unittest creates non-picklable errors
In-Reply-To: <1416426552.76.0.140329555318.issue22903@psf.upfronthosting.co.za>
Message-ID: <1426717856.38.0.319606522877.issue22903@psf.upfronthosting.co.za>


Robert Collins added the comment:

LGTM please commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22903>
_______________________________________

From report at bugs.python.org  Wed Mar 18 23:53:05 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Mar 2015 22:53:05 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <1426719185.39.0.70647503871.issue23632@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Updated patch addressing Serhiy's comments.

----------
Added file: http://bugs.python.org/file38550/memoryview_tuple_indexing2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Thu Mar 19 00:01:47 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Mar 2015 23:01:47 +0000
Subject: [issue22903] unittest creates non-picklable errors
In-Reply-To: <1416426552.76.0.140329555318.issue22903@psf.upfronthosting.co.za>
Message-ID: <20150318230144.30042.48305@psf.io>


Roundup Robot added the comment:

New changeset f3977f34cf6c by Antoine Pitrou in branch '3.4':
Issue #22903: The fake test case created by unittest.loader when it fails importing a test module is now picklable.
https://hg.python.org/cpython/rev/f3977f34cf6c

New changeset a1b5ac563d8d by Antoine Pitrou in branch 'default':
Issue #22903: The fake test case created by unittest.loader when it fails importing a test module is now picklable.
https://hg.python.org/cpython/rev/a1b5ac563d8d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22903>
_______________________________________

From report at bugs.python.org  Thu Mar 19 00:02:13 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Mar 2015 23:02:13 +0000
Subject: [issue22903] unittest creates non-picklable errors
In-Reply-To: <1416426552.76.0.140329555318.issue22903@psf.upfronthosting.co.za>
Message-ID: <1426719733.91.0.277803166731.issue22903@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22903>
_______________________________________

From report at bugs.python.org  Thu Mar 19 00:05:18 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 18 Mar 2015 23:05:18 +0000
Subject: [issue22941] IPv4Interface arithmetic changes subnet mask
In-Reply-To: <1416933717.58.0.234544639586.issue22941@psf.upfronthosting.co.za>
Message-ID: <1426719918.73.0.0548495909187.issue22941@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Thanks for trying this!
As discussed on python-dev, overflowing the netmask should raise an OverflowError. Also, some tests should be added to Lib/test/test_ipaddress.py.

----------
nosy: +pitrou
stage:  -> needs patch
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22941>
_______________________________________

From report at bugs.python.org  Thu Mar 19 01:28:30 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Mar 2015 00:28:30 +0000
Subject: [issue23673] IntEnum is unpicklable by previous Python versions
In-Reply-To: <1426432245.83.0.265780672947.issue23673@psf.upfronthosting.co.za>
Message-ID: <20150319002827.4215.18958@psf.io>


Roundup Robot added the comment:

New changeset c93d46fd85ee by Ethan Furman in branch 'default':
issue23673
https://hg.python.org/cpython/rev/c93d46fd85ee

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23673>
_______________________________________

From report at bugs.python.org  Thu Mar 19 01:32:51 2015
From: report at bugs.python.org (Hammerite)
Date: Thu, 19 Mar 2015 00:32:51 +0000
Subject: [issue23550] Add to unicodedata a function to query the "Quick_Check"
 property for a character
In-Reply-To: <1425147670.05.0.762030398058.issue23550@psf.upfronthosting.co.za>
Message-ID: <1426725171.9.0.511180077029.issue23550@psf.upfronthosting.co.za>


Hammerite added the comment:

I'm a registered contributor now, in case that is a roadblock.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23550>
_______________________________________

From report at bugs.python.org  Thu Mar 19 01:35:04 2015
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 19 Mar 2015 00:35:04 +0000
Subject: [issue20680] Pickle socket enums by names
In-Reply-To: <1392758039.35.0.851373733794.issue20680@psf.upfronthosting.co.za>
Message-ID: <1426725304.04.0.200147945225.issue20680@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Enum members that are replacing constants now pickle by name (see issue23673).

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> IntEnum is unpicklable by previous Python versions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20680>
_______________________________________

From report at bugs.python.org  Thu Mar 19 02:24:08 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Mar 2015 01:24:08 +0000
Subject: [issue23673] IntEnum is unpicklable by previous Python versions
In-Reply-To: <1426432245.83.0.265780672947.issue23673@psf.upfronthosting.co.za>
Message-ID: <20150319012401.30722.21111@psf.io>


Roundup Robot added the comment:

New changeset 5dd7b5fb65e7 by Ethan Furman in branch '3.4':
issue23673
https://hg.python.org/cpython/rev/5dd7b5fb65e7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23673>
_______________________________________

From report at bugs.python.org  Thu Mar 19 02:29:05 2015
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 19 Mar 2015 01:29:05 +0000
Subject: [issue23673] IntEnum is unpicklable by previous Python versions
In-Reply-To: <1426432245.83.0.265780672947.issue23673@psf.upfronthosting.co.za>
Message-ID: <1426728545.3.0.474288960678.issue23673@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23673>
_______________________________________

From report at bugs.python.org  Thu Mar 19 02:46:58 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 19 Mar 2015 01:46:58 +0000
Subject: [issue23550] Add to unicodedata a function to query the "Quick_Check"
 property for a character
In-Reply-To: <1425147670.05.0.762030398058.issue23550@psf.upfronthosting.co.za>
Message-ID: <1426729618.32.0.536657360026.issue23550@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23550>
_______________________________________

From report at bugs.python.org  Thu Mar 19 03:05:06 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 19 Mar 2015 02:05:06 +0000
Subject: [issue23550] Add to unicodedata a function to query the "Quick_Check"
 property for a character
In-Reply-To: <1425147670.05.0.762030398058.issue23550@psf.upfronthosting.co.za>
Message-ID: <1426730706.47.0.72558180059.issue23550@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Hammerite. Did you see the review comments on Rietveld?

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23550>
_______________________________________

From report at bugs.python.org  Thu Mar 19 03:58:11 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 Mar 2015 02:58:11 +0000
Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler
 if using ccache
In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za>
Message-ID: <1426733891.18.0.845618335006.issue8027@psf.upfronthosting.co.za>


Ned Deily added the comment:

The code in question was added a long time ago by Ronald as part of the initial OS X universal build support (3078fdb7cf3d for Issue1488098).  I'm not exactly sure what problem it was trying to solve ao I'm not sure that it's 100% safe to totally remove rather than try to fix it.  Ronald, do you recall?

----------
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8027>
_______________________________________

From report at bugs.python.org  Thu Mar 19 04:03:56 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 Mar 2015 03:03:56 +0000
Subject: [issue23289] concurrent.futures.Executor.map is not equivalent to map.
In-Reply-To: <1421844180.03.0.988670092885.issue23289@psf.upfronthosting.co.za>
Message-ID: <1426734236.51.0.585968605335.issue23289@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +bquinlan
versions:  -Python 3.2, Python 3.3, Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23289>
_______________________________________

From report at bugs.python.org  Thu Mar 19 04:24:11 2015
From: report at bugs.python.org (George Jenkins)
Date: Thu, 19 Mar 2015 03:24:11 +0000
Subject: [issue1182143] making builtin exceptions more informative
Message-ID: <1426735451.88.0.524525036034.issue1182143@psf.upfronthosting.co.za>


George Jenkins added the comment:

Hi, I attempted a solution for this a while back

Attached is a (git diff based) patch for review

Changes can also been seen at: https://bitbucket.org/bloomberg/cpython/pull-request/2/http-bugspythonorg-issue1182143-add-name/diff
(but note the changes in Misc/NEWS and Tools/msi/msi.py are not related / somehow got pulled into my changes by mercurial)

Please review/let me know of any other process required. Thanks!

----------
keywords: +patch
nosy: +George Jenkins
versions: +Python 3.5 -Python 3.2
Added file: http://bugs.python.org/file38551/Issue1182143_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1182143>
_______________________________________

From report at bugs.python.org  Thu Mar 19 07:09:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Mar 2015 06:09:47 +0000
Subject: [issue20680] Pickle socket enums by names
In-Reply-To: <1426725304.04.0.200147945225.issue20680@psf.upfronthosting.co.za>
Message-ID: <1480206.lt5CbyFqfb@raxxla>


Serhiy Storchaka added the comment:

Thanks Ethan.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20680>
_______________________________________

From report at bugs.python.org  Thu Mar 19 07:10:17 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Mar 2015 06:10:17 +0000
Subject: [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <1426745417.49.0.154572728303.issue11468@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Yes, go ahead an apply this patch.

----------
assignee: rhettinger -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11468>
_______________________________________

From report at bugs.python.org  Thu Mar 19 07:56:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Mar 2015 06:56:50 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <1426748210.32.0.256202620607.issue23632@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It would be good to add examples with multidimensional memoryviews. For example:

>>> a = array.array('l', [-11111111, 22222222, -33333333, 44444444])
>>> m = memoryview(a).cast('B').cast('l', [2, 2])
>>> m[0, 0]
-11111111
>>> m[1, 0]
-33333333
>>> m[-1, -1]
44444444

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Thu Mar 19 08:09:16 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 19 Mar 2015 07:09:16 +0000
Subject: [issue23703] urljoin() with no directory segments duplicates filename
Message-ID: <1426748956.21.0.814756519005.issue23703@psf.upfronthosting.co.za>


New submission from Martin Panter:

This is a regression caused by revision 901e4e52b20a. Before (e.g. Python 3.4):

>>> urljoin('a', 'b')
'b'

After:

>>> urljoin('a', 'b')
'b/b'

This was identified in <https://bugs.python.org/issue18828#msg238363> but is actually caused by the revision committed for Issue 22278.

----------
components: Library (Lib)
messages: 238493
nosy: demian.brecht, vadmium
priority: normal
severity: normal
status: open
title: urljoin() with no directory segments duplicates filename
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23703>
_______________________________________

From report at bugs.python.org  Thu Mar 19 08:11:14 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 19 Mar 2015 07:11:14 +0000
Subject: [issue22278] urljoin duplicate slashes
In-Reply-To: <1409075887.24.0.237889697027.issue22278@psf.upfronthosting.co.za>
Message-ID: <1426749074.0.0.619360168218.issue22278@psf.upfronthosting.co.za>


Martin Panter added the comment:

I opened Issue 23703 for a regression caused by this commit.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22278>
_______________________________________

From report at bugs.python.org  Thu Mar 19 08:11:27 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Mar 2015 07:11:27 +0000
Subject: [issue23704] Make deques a full MutableSequence by adding index(),
 insert(), and copy()
Message-ID: <1426749087.45.0.288673142528.issue23704@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
components: Library (Lib)
files: deque_insert_index_copy3.diff
keywords: patch
nosy: rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Make deques a full MutableSequence by adding index(), insert(), and copy()
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38552/deque_insert_index_copy3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23704>
_______________________________________

From report at bugs.python.org  Thu Mar 19 08:17:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Mar 2015 07:17:04 +0000
Subject: [issue23325] Turn SIG_DFL and SIG_IGN into functions
In-Reply-To: <1422304710.21.0.213579052731.issue23325@psf.upfronthosting.co.za>
Message-ID: <1426749424.83.0.994859044898.issue23325@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Currently the action parameter of signal.signal() can be SIG_DFL, SIG_IGN, or a callable Python object. Would be just a callable Python object. This is simpler.

The main benefit is that they will be better look in pydoc output.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23325>
_______________________________________

From report at bugs.python.org  Thu Mar 19 08:25:15 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Mar 2015 07:25:15 +0000
Subject: [issue23705] Speed-up deque.__contains__
Message-ID: <1426749915.16.0.735258813195.issue23705@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Help deques match the performance of lists for a __contains__ check.  Comparative timings are attached.

----------
assignee: rhettinger
components: Library (Lib)
files: deque_contains0.diff
keywords: patch
messages: 238496
nosy: rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Speed-up deque.__contains__
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file38553/deque_contains0.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23705>
_______________________________________

From report at bugs.python.org  Thu Mar 19 08:25:17 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 19 Mar 2015 07:25:17 +0000
Subject: [issue18828] urljoin behaves differently with custom and standard
 schemas
In-Reply-To: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za>
Message-ID: <1426749917.66.0.97983354883.issue18828@psf.upfronthosting.co.za>


Martin Panter added the comment:

I opened Issue 23703 about the funny doubled bar.com result. After backing out revision 901e4e52b20a, but with my patch here applied:

>>> urljoin('mailto:foo@', 'bar.com')
'mailto:bar.com'

which seems fairly sensible to me. A more awkward question is if this behaviour of my patch is reasonable:

>>> urljoin('mailto:person-foo/bar at example.net', 'bar.com')
'mailto:person-foo/bar.com'

Yet another option, similar to my ?any_scheme=True? flag, might be to change from the ?uses_relative? white-list to a ?not_relative? black-list of URL schemes, so that urljoin() works for arbitrary schemes except for ones like ?mailto:? that are in the hard-coded list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18828>
_______________________________________

From report at bugs.python.org  Thu Mar 19 08:25:42 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Mar 2015 07:25:42 +0000
Subject: [issue23705] Speed-up deque.__contains__
In-Reply-To: <1426749915.16.0.735258813195.issue23705@psf.upfronthosting.co.za>
Message-ID: <1426749942.8.0.299225017784.issue23705@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file38554/deque_contains_timings.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23705>
_______________________________________

From report at bugs.python.org  Thu Mar 19 08:25:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Mar 2015 07:25:59 +0000
Subject: [issue20204] pydocs fails for some C implemented classes
In-Reply-To: <1389271655.86.0.224685657695.issue20204@psf.upfronthosting.co.za>
Message-ID: <1426749959.44.0.0470739543652.issue20204@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20204>
_______________________________________

From report at bugs.python.org  Thu Mar 19 08:26:16 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Mar 2015 07:26:16 +0000
Subject: [issue23704] Make deques a full MutableSequence by adding index(),
 insert(), and copy()
Message-ID: <1426749976.67.0.787585766684.issue23704@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23704>
_______________________________________

From report at bugs.python.org  Thu Mar 19 08:54:03 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Thu, 19 Mar 2015 07:54:03 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426751643.19.0.917210544471.issue23700@psf.upfronthosting.co.za>


Changes by Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de>:


----------
nosy: +wolma

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Thu Mar 19 09:15:58 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 19 Mar 2015 08:15:58 +0000
Subject: [issue23703] urljoin() with no directory segments duplicates filename
In-Reply-To: <1426748956.21.0.814756519005.issue23703@psf.upfronthosting.co.za>
Message-ID: <1426752958.77.0.375698251163.issue23703@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23703>
_______________________________________

From report at bugs.python.org  Thu Mar 19 10:23:12 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 09:23:12 +0000
Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler
 if using ccache
In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za>
Message-ID: <1426756992.91.0.0124895914473.issue8027@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8027>
_______________________________________

From report at bugs.python.org  Thu Mar 19 10:32:41 2015
From: report at bugs.python.org (=?utf-8?q?Ugra_D=C3=A1niel?=)
Date: Thu, 19 Mar 2015 09:32:41 +0000
Subject: [issue23706] pathlib.Path.write_text should include a newline argument
Message-ID: <1426757561.17.0.481870343329.issue23706@psf.upfronthosting.co.za>


New submission from Ugra D?niel:

The new pathlib.Path [read|write]_[binary|text] methods will be very useful, one thing I miss badly is the newline argument for write_text.

In some cases text files need a specific line ending (independent from the platform the code is being executed on.) In my mind this is analogous to passing an explicit encoding argument.

Of course, one can always use built-in open for this scenario. It would be a nice addition anyway :)

----------
components: Library (Lib)
messages: 238498
nosy: daniel.ugra
priority: normal
severity: normal
status: open
title: pathlib.Path.write_text should include a newline argument
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23706>
_______________________________________

From report at bugs.python.org  Thu Mar 19 11:04:10 2015
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 19 Mar 2015 10:04:10 +0000
Subject: [issue23419] Faster default __reduce__ for classes without __init__
In-Reply-To: <1423479644.09.0.947345755494.issue23419@psf.upfronthosting.co.za>
Message-ID: <1426759450.56.0.0862220905578.issue23419@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

But isn't the result different?
NEWOBJ calls cls.__new__() and __init__ is skipped.
REDUCE calls cls(): both __new__ and __init__ are used.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23419>
_______________________________________

From report at bugs.python.org  Thu Mar 19 11:20:17 2015
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 19 Mar 2015 10:20:17 +0000
Subject: [issue23419] Faster default __reduce__ for classes without __init__
In-Reply-To: <1423479644.09.0.947345755494.issue23419@psf.upfronthosting.co.za>
Message-ID: <1426760417.45.0.553618887194.issue23419@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Sorry, I missed the important point:
"for classes without __init__"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23419>
_______________________________________

From report at bugs.python.org  Thu Mar 19 11:54:41 2015
From: report at bugs.python.org (Paul Moore)
Date: Thu, 19 Mar 2015 10:54:41 +0000
Subject: [issue23681] Have -b warn when directly comparing ints and bytes
In-Reply-To: <1426525530.11.0.0814957947674.issue23681@psf.upfronthosting.co.za>
Message-ID: <1426762481.95.0.999635140126.issue23681@psf.upfronthosting.co.za>


Paul Moore added the comment:

LGTM, just one minor comment in review.

----------
nosy: +paul.moore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23681>
_______________________________________

From report at bugs.python.org  Thu Mar 19 11:56:32 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 19 Mar 2015 10:56:32 +0000
Subject: [issue22181] os.urandom() should use Linux 3.17 getrandom() syscall
In-Reply-To: <1407713563.4.0.264701036097.issue22181@psf.upfronthosting.co.za>
Message-ID: <1426762592.55.0.373884249714.issue22181@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
stage: needs patch -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22181>
_______________________________________

From report at bugs.python.org  Thu Mar 19 12:17:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Mar 2015 11:17:55 +0000
Subject: [issue23001] Accept mutable bytes-like objects
In-Reply-To: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za>
Message-ID: <1426763875.3.0.874623438416.issue23001@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added versionchanged directives and fixed other documentation.

----------
Added file: http://bugs.python.org/file38555/accept_mutable_buffers_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23001>
_______________________________________

From report at bugs.python.org  Thu Mar 19 12:24:37 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 19 Mar 2015 11:24:37 +0000
Subject: [issue4395] Document auto __ne__ generation;
 provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1426764277.95.0.393244671784.issue4395@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4395>
_______________________________________

From report at bugs.python.org  Thu Mar 19 13:19:55 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 12:19:55 +0000
Subject: [issue23707] PEP 475: os.urandom() doesn't handle EINTR correctly
Message-ID: <1426767595.67.0.731351330983.issue23707@psf.upfronthosting.co.za>


New submission from STINNER Victor:

dev_urandom_python() retries read() if it fails with EINTR, but Python signal handlers are not called: PyErr_CheckSignals() is not called. It's important be able to interrupt a function by a signal, especially if it's blocking.

We need maybe a new _Py_read() function which would retry on EINTR. The code can be based on posix_read(). For open(), there is already _Py_open() which retries on EINTR (since the changeset ed25e945cdc2, issue #23694). It can be useful for FileIO.read().

dev_urandom_noraise() retries on EINTR without calling PyErr_CheckSignals(). It may be acceptable since this function is only called by _PyRandom_Init() at an early stage of Python initialization. Or maybe EINTR should call Py_FatalError()?

On Linux 3.18 (Fedora 21 with kernel 3.18.7-200.fc21.x86_64), reading 1 GB from /dev/urandom or getrandom() returns 0x1ffffff bytes (32 MB). It's not an issue, os.urandom() continues to read until it gets enough data.

I tried to interrupt os.urandom() on Python 3.4 (read) and Python 3.5 (getrandom): reading from /dev/urandom using a file descriptor or getrandom() have the same behaviour, none fail with EINTR. I checked syscalls using strace.

It looks like getrandom() only fails with EINTR when flags=GRND_RANDOM. So this issue is maybe more theoric.

----------
messages: 238503
nosy: haypo
priority: normal
severity: normal
status: open
title: PEP 475: os.urandom() doesn't handle EINTR correctly
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23707>
_______________________________________

From report at bugs.python.org  Thu Mar 19 13:43:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 12:43:17 +0000
Subject: [issue22181] os.urandom() should use Linux 3.17 getrandom() syscall
In-Reply-To: <1407713563.4.0.264701036097.issue22181@psf.upfronthosting.co.za>
Message-ID: <1426768997.66.0.747655129959.issue22181@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, test_os now fails on Linux because os.urandom() doesn't use a file descriptor anymore. The test should be skipped when getrandom() is used. The test is already skipped when getentropy() is used.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22181>
_______________________________________

From report at bugs.python.org  Thu Mar 19 13:50:36 2015
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Thu, 19 Mar 2015 12:50:36 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426769436.7.0.284440792953.issue23700@psf.upfronthosting.co.za>


Bohuslav "Slavek" Kabrda added the comment:

I'm attaching second version of the patch. It now contains link to this bug and a more real test case according to suggestion from the review.

One of the reviews of first patch version mentioned that there should be a better explanation of how this issue can be provoked. I think that the test shows it nice and there's no need to explain it in greater detail. Also, the comment references this bug, where anyone can find the explanation. (Fix for #18879 fixes pretty much the same in a different method and has very similar comment, so I think this should be fine.)

----------
Added file: http://bugs.python.org/file38556/python-3.4-tempfile-iter-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:07:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Mar 2015 13:07:18 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426770438.91.0.7267927051.issue23700@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee:  -> serhiy.storchaka
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:12:09 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 19 Mar 2015 13:12:09 +0000
Subject: [issue23042] ctypes module doesn't build on FreeBSD x86
In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za>
Message-ID: <1426770729.72.0.94096586259.issue23042@psf.upfronthosting.co.za>


Davin Potts added the comment:

Reading issue22634 suggests that perhaps this issue is not limited to FreeBSD -- issue22634 appears to suffer the same behavior on RHEL 6.4 and 5.5 when compiling to 32-bit (the -m32 compiler flag is being used there).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23042>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:16:26 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 19 Mar 2015 13:16:26 +0000
Subject: [issue22634] importing _ctypes failed: undefined symbol:
 ffi_call_win32
In-Reply-To: <1413316785.82.0.044196497806.issue22634@psf.upfronthosting.co.za>
Message-ID: <1426770986.34.0.631516207064.issue22634@psf.upfronthosting.co.za>


Davin Potts added the comment:

Comparing this to issue23042, this same behavior appears on i386 releases of FreeBSD 8.3 and 10.1 (the i386-RELEASE means it's 32-bit as opposed to 64-bit build).  Given that this issue is being triggered here with -m32 (triggers building of 32-bit binaries) and yet we don't appear to be having this issue on 64-bit builds, that could be a useful clue.

----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22634>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:18:04 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 19 Mar 2015 13:18:04 +0000
Subject: [issue22634] importing _ctypes failed: undefined symbol:
 ffi_call_win32
In-Reply-To: <1413316785.82.0.044196497806.issue22634@psf.upfronthosting.co.za>
Message-ID: <1426771084.08.0.722956849535.issue22634@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

This is likely also related to issue23042.

The precompiler #ifdefs were mixed up, causing Win32 code to be compiled in on other platforms as well.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22634>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:22:10 2015
From: report at bugs.python.org (Paul Moore)
Date: Thu, 19 Mar 2015 13:22:10 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426771330.53.0.569560146774.issue23700@psf.upfronthosting.co.za>


Paul Moore added the comment:

Agreed, the test is sufficient documentation. However, I can't make the test fail here (Windows 7, Python 3.4.3):

>py ti.py
b'spam\n' b'spam\n'
b'eggs\n' b'eggs\n'
b'beans\n' b'beans\n'
>cat ti.py
import tempfile

def test_iter():
    # getting iterator from a temporary file should keep it alive
    # as long as it's being iterated over
    lines = [b'spam\n', b'eggs\n', b'beans\n']
    def make_file():
        f = tempfile.NamedTemporaryFile(mode='w+b')
        f.write(b''.join(lines))
        f.seek(0)
        return iter(f)
    for i, l in enumerate(make_file()):
        print(l, lines[i])

test_iter()

Is it somehow OS-specific?

Regardless, the patch seems fine and I have no problem with it being applied.

----------
nosy: +paul.moore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:25:28 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Mar 2015 13:25:28 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <20150319132523.70036.19681@psf.io>


Roundup Robot added the comment:

New changeset 7fa741fe9425 by Serhiy Storchaka in branch '3.4':
Issue #23700: Iterator of NamedTemporaryFile now keeps a reference to
https://hg.python.org/cpython/rev/7fa741fe9425

New changeset c84a0b35999a by Serhiy Storchaka in branch 'default':
Issue #23700: Iterator of NamedTemporaryFile now keeps a reference to
https://hg.python.org/cpython/rev/c84a0b35999a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:27:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Mar 2015 13:27:42 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426771662.66.0.643239305753.issue23700@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your contribution Bohuslav.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:31:34 2015
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Thu, 19 Mar 2015 13:31:34 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426771894.48.0.951575415974.issue23700@psf.upfronthosting.co.za>


Bohuslav "Slavek" Kabrda added the comment:

Thank you!
To answer Paul's question: I honestly have no idea why this can't be reproduced on Windows. I managed to reproduce this in 100 % cases on various RPM-flavour Linux distros (Fedora, CentOS, RHEL) as well as on Debian and Ubuntu.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:33:30 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 13:33:30 +0000
Subject: [issue23708] PEP 475: Add _Py_read() and _Py_write() functions
Message-ID: <1426772010.62.0.268490898603.issue23708@psf.upfronthosting.co.za>


New submission from STINNER Victor:

To factorize code handling EINTR, I propose add 2 new functions to fileutils.h: _Py_read() and _Py_write().

Attached patch adds these functions and use them in the os and _io modules.

The code of the functions is based on the code from the os and _io modules. The main change is that the functions now truncate code if greater than PY_SSIZE_T_MAX. Other changes are just refactoring.

----------
files: py_read_write.patch
keywords: patch
messages: 238514
nosy: haypo
priority: normal
severity: normal
status: open
title: PEP 475: Add _Py_read() and _Py_write() functions
versions: Python 3.5
Added file: http://bugs.python.org/file38557/py_read_write.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23708>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:34:04 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 13:34:04 +0000
Subject: [issue23708] PEP 475: Add _Py_read() and _Py_write() functions
In-Reply-To: <1426772010.62.0.268490898603.issue23708@psf.upfronthosting.co.za>
Message-ID: <1426772044.37.0.467693115492.issue23708@psf.upfronthosting.co.za>


STINNER Victor added the comment:

select_write.patch: use _Py_write() in the select module.

----------
Added file: http://bugs.python.org/file38558/select_write.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23708>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:36:49 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 13:36:49 +0000
Subject: [issue23709] Refactor ossaudiodev: use _Py_read and _Py_write with
 the Py_buffer
Message-ID: <1426772209.38.0.996436244503.issue23709@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch enhances ossaudiodev to support buffer larger than 2 GB (replace the C int type with C Py_ssize_t). It uses the new _Py_read() and _Py_write() functions added in the issue #23708 with the Py_buffer API.

By the way, I don't understand the purpose of the input and output counters (icount and ocount fields of the oss_audio_t structure), they don't look to be used?!

----------
files: ossaudiodev.patch
keywords: patch
messages: 238516
nosy: haypo
priority: normal
severity: normal
status: open
title: Refactor ossaudiodev: use _Py_read and _Py_write with the Py_buffer
versions: Python 3.5
Added file: http://bugs.python.org/file38559/ossaudiodev.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23709>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:36:53 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 13:36:53 +0000
Subject: [issue23709] Refactor ossaudiodev: use _Py_read and _Py_write with
 the Py_buffer
In-Reply-To: <1426772209.38.0.996436244503.issue23709@psf.upfronthosting.co.za>
Message-ID: <1426772213.06.0.512443553456.issue23709@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
dependencies: +PEP 475: Add _Py_read() and _Py_write() functions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23709>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:37:29 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 13:37:29 +0000
Subject: [issue23708] PEP 475: Add _Py_read() and _Py_write() functions
In-Reply-To: <1426772010.62.0.268490898603.issue23708@psf.upfronthosting.co.za>
Message-ID: <1426772249.02.0.244937228532.issue23708@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I created the issue #23709 for the ossaudiodev module: "Refactor ossaudiodev: use _Py_read and _Py_write with the Py_buffer".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23708>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:37:38 2015
From: report at bugs.python.org (Paul Moore)
Date: Thu, 19 Mar 2015 13:37:38 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426772258.17.0.415163084908.issue23700@psf.upfronthosting.co.za>


Paul Moore added the comment:

Cool, no problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:38:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 13:38:08 +0000
Subject: [issue23707] PEP 475: os.urandom() doesn't handle EINTR correctly
In-Reply-To: <1426767595.67.0.731351330983.issue23707@psf.upfronthosting.co.za>
Message-ID: <1426772288.73.0.852294432249.issue23707@psf.upfronthosting.co.za>


STINNER Victor added the comment:

random.patch: fix the issue with the new _Py_read() function added by the issue #23708.

----------
dependencies: +PEP 475: Add _Py_read() and _Py_write() functions
keywords: +patch
Added file: http://bugs.python.org/file38560/random.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23707>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:40:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 13:40:51 +0000
Subject: [issue23709] Refactor ossaudiodev: use _Py_read and _Py_write with
 the Py_buffer
In-Reply-To: <1426772209.38.0.996436244503.issue23709@psf.upfronthosting.co.za>
Message-ID: <1426772451.86.0.982999361419.issue23709@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, I forgot to mention the advantage of using _Py_read() and _Py_write(): they retry read/write when interrupted by a signal, to support the PEP 475.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23709>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:41:21 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 13:41:21 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>
Message-ID: <1426772481.0.0.588017172753.issue23648@psf.upfronthosting.co.za>


STINNER Victor added the comment:

More issues:

- Issue #23707: os.urandom() doesn't handle EINTR correctly
- Issue #23708: Add _Py_read() and _Py_write() functions
- Issue #23709: Refactor ossaudiodev: use _Py_read and _Py_write with the Py_buffer

----------
dependencies: +PEP 475: Add _Py_read() and _Py_write() functions, PEP 475: os.urandom() doesn't handle EINTR correctly, Refactor ossaudiodev: use _Py_read and _Py_write with the Py_buffer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:51:58 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 19 Mar 2015 13:51:58 +0000
Subject: [issue23042] ctypes module doesn't build on FreeBSD x86
In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za>
Message-ID: <1426773118.48.0.320341870928.issue23042@psf.upfronthosting.co.za>


Davin Potts added the comment:

Attaching a patch which enabled successful compilation of ctypes on FreeBSD 10.1 i386-RELEASE in each of default/3.5, 3.4, and 2.7 branches.

This patch attempts to fix the incomplete logic regarding Windows target platforms in the ifdef's inside Modules/_ctypes/libffi/src/x86/ffi.c which at times tested for X86_WIN64 but not X86_WIN32 inside corresponding #else clauses (and vice versa).

This especially needs to be tested on a 32-bit Windows system -- I do not have one handy so help testing it there (and elsewhere) would be much appreciated.

----------
keywords: +patch
Added file: http://bugs.python.org/file38561/issue_23042_fix_windows_ifdefs_py35_and_py34_and_py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23042>
_______________________________________

From report at bugs.python.org  Thu Mar 19 14:54:21 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 19 Mar 2015 13:54:21 +0000
Subject: [issue23042] ctypes module doesn't build on FreeBSD x86
In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za>
Message-ID: <1426773261.17.0.217487298279.issue23042@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23042>
_______________________________________

From report at bugs.python.org  Thu Mar 19 15:01:06 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 19 Mar 2015 14:01:06 +0000
Subject: [issue22634] importing _ctypes failed: undefined symbol:
 ffi_call_win32
In-Reply-To: <1413316785.82.0.044196497806.issue22634@psf.upfronthosting.co.za>
Message-ID: <1426773666.51.0.071683587545.issue22634@psf.upfronthosting.co.za>


Davin Potts added the comment:

There is now a proposed patch on issue23042 which, having gone through those changes, may well address this issue too.

Testing that patch on multiple platforms (including the RHEL variants relevant here) would be much appreciated.

Thanks goes to @lemburg for doing the investigative work and providing the diffs that occurred to the Modules/_ctypes/libffi/src/x86/ffi.c file in the past -- that work made the patch possible to sort out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22634>
_______________________________________

From report at bugs.python.org  Thu Mar 19 15:03:12 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Thu, 19 Mar 2015 14:03:12 +0000
Subject: [issue23698] Fix documentation for multiprocessing.Manager
In-Reply-To: <1426660385.12.0.0389729473261.issue23698@psf.upfronthosting.co.za>
Message-ID: <1426773792.41.0.0655145281855.issue23698@psf.upfronthosting.co.za>


Anand B Pillai added the comment:

Is your patch uploaded anywhere ?

Anyway, before thinking whether this should be a patch or doc fix, one needs multiprocessing module author to possibly comment on the right behaviour expected here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23698>
_______________________________________

From report at bugs.python.org  Thu Mar 19 15:04:46 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Thu, 19 Mar 2015 14:04:46 +0000
Subject: [issue23698] Fix inconsistencies in behaviour and document it
 correctly for multiprocessing.Manager facade
In-Reply-To: <1426660385.12.0.0389729473261.issue23698@psf.upfronthosting.co.za>
Message-ID: <1426773886.56.0.990199002228.issue23698@psf.upfronthosting.co.za>


Changes by Anand B Pillai <abpillai at gmail.com>:


----------
title: Fix documentation for multiprocessing.Manager -> Fix inconsistencies in behaviour and document it correctly for multiprocessing.Manager facade

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23698>
_______________________________________

From report at bugs.python.org  Thu Mar 19 15:09:54 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 19 Mar 2015 14:09:54 +0000
Subject: [issue23698] Fix inconsistencies in behaviour and document it
 correctly for multiprocessing.Manager facade
In-Reply-To: <1426660385.12.0.0389729473261.issue23698@psf.upfronthosting.co.za>
Message-ID: <1426774194.27.0.476552141007.issue23698@psf.upfronthosting.co.za>


Davin Potts added the comment:

No, it's premature to share the start of my patch.

Very much agreed on getting that input/insight -- sbt (multiprocessing module maintainer and original author) was added to the nosy list yesterday too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23698>
_______________________________________

From report at bugs.python.org  Thu Mar 19 15:11:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 14:11:45 +0000
Subject: [issue23708] PEP 475: Add _Py_read() and _Py_write() functions
In-Reply-To: <1426772010.62.0.268490898603.issue23708@psf.upfronthosting.co.za>
Message-ID: <1426774305.64.0.329040111153.issue23708@psf.upfronthosting.co.za>


STINNER Victor added the comment:

With py_read_write.patch in debug mode, test_threading crash with an assertion error because of the issue #15751. Currently, it's not possible to call assert(PyGILState_Check()); inside Py_NewInterpreter(), while creating a subinterpreter (ex: _testcapi.run_in_subinterp()).

The workaround is to comment the assertion in _Py_read() and Py_write() until the issue #15751 is fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23708>
_______________________________________

From report at bugs.python.org  Thu Mar 19 15:18:17 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 19 Mar 2015 14:18:17 +0000
Subject: [issue16314] Support xz compression in distutils
In-Reply-To: <1351114378.64.0.718374634123.issue16314@psf.upfronthosting.co.za>
Message-ID: <1426774697.95.0.356044373786.issue16314@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Code and doc changes look good.  Will you add tests?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16314>
_______________________________________

From report at bugs.python.org  Thu Mar 19 15:26:47 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 14:26:47 +0000
Subject: [issue22634] importing _ctypes failed: undefined symbol:
 ffi_call_win32
In-Reply-To: <1413316785.82.0.044196497806.issue22634@psf.upfronthosting.co.za>
Message-ID: <1426775207.27.0.93303562765.issue22634@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22634>
_______________________________________

From report at bugs.python.org  Thu Mar 19 15:28:16 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 14:28:16 +0000
Subject: [issue23708] PEP 475: Add _Py_read() and _Py_write() functions
In-Reply-To: <1426772010.62.0.268490898603.issue23708@psf.upfronthosting.co.za>
Message-ID: <1426775296.48.0.660141040464.issue23708@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oops, there was a bug in FileIO.readall(), fixed in the new patch py_read_write-2.patch.

I also commented assert(PyGILState_Check()); to workaround the issue #15751.

----------
Added file: http://bugs.python.org/file38562/py_read_write-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23708>
_______________________________________

From report at bugs.python.org  Thu Mar 19 15:39:52 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 14:39:52 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>
Message-ID: <1426775992.64.0.0760549591616.issue23648@psf.upfronthosting.co.za>


STINNER Victor added the comment:

signal.sigwaitinfo() raises InterruptedError if the wait was interrupted by a signal  handler (this handler was for a signal other than one of those in set).

IMO we should also retry sigwaitinfo() if it fails with EINTR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Thu Mar 19 15:41:39 2015
From: report at bugs.python.org (=?utf-8?q?Tomi_Pievil=C3=A4inen?=)
Date: Thu, 19 Mar 2015 14:41:39 +0000
Subject: [issue23710] C API doc for PyObject_HEAD is outdated
Message-ID: <1426776099.01.0.644113037586.issue23710@psf.upfronthosting.co.za>


New submission from Tomi Pievil?inen:

https://docs.python.org/3/c-api/structures.html#c.PyObject_HEAD says that the macro should be used for creating new types and that it has ob_type. Unfortunately at some point (@61466 perhaps) that definition in object.h was changed. This affects other pages too (at least https://docs.python.org/3/extending/newtypes.html).

I encountered this while checking if a C extension (imposm.parser) could be trivially ported for Python 3. Unfortunately not. I suppose

  self->ob_type

should be replaced with

  Py_TYPE(self)

but that isn't really clear from the docs.

----------
assignee: docs at python
components: Documentation
messages: 238530
nosy: docs at python, tpievila
priority: normal
severity: normal
status: open
title: C API doc for PyObject_HEAD is outdated

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23710>
_______________________________________

From report at bugs.python.org  Thu Mar 19 16:05:18 2015
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 19 Mar 2015 15:05:18 +0000
Subject: [issue23703] urljoin() with no directory segments duplicates filename
In-Reply-To: <1426748956.21.0.814756519005.issue23703@psf.upfronthosting.co.za>
Message-ID: <1426777518.87.0.707837858145.issue23703@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Nice work tracking down the commit, thanks for that. I've attached a fix.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file38563/issue23703.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23703>
_______________________________________

From report at bugs.python.org  Thu Mar 19 16:30:29 2015
From: report at bugs.python.org (Siming Yuan)
Date: Thu, 19 Mar 2015 15:30:29 +0000
Subject: [issue22634] importing _ctypes failed: undefined symbol:
 ffi_call_win32
In-Reply-To: <1413316785.82.0.044196497806.issue22634@psf.upfronthosting.co.za>
Message-ID: <1426779029.31.0.137310860348.issue22634@psf.upfronthosting.co.za>


Siming Yuan added the comment:

@davin @lemburg
just tested with the provided patch in http://bugs.python.org/issue23042, the partch works.

dupe the bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22634>
_______________________________________

From report at bugs.python.org  Thu Mar 19 16:32:35 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 19 Mar 2015 15:32:35 +0000
Subject: [issue22634] importing _ctypes failed: undefined symbol:
 ffi_call_win32
In-Reply-To: <1413316785.82.0.044196497806.issue22634@psf.upfronthosting.co.za>
Message-ID: <1426779155.18.0.677931653188.issue22634@psf.upfronthosting.co.za>


Davin Potts added the comment:

@siyuan:  Duping it -- thanks for trying that patch out so quickly!

----------
superseder:  -> ctypes module doesn't build on FreeBSD x86

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22634>
_______________________________________

From report at bugs.python.org  Thu Mar 19 16:36:23 2015
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 19 Mar 2015 15:36:23 +0000
Subject: [issue18828] urljoin behaves differently with custom and standard
 schemas
In-Reply-To: <1426749917.66.0.97983354883.issue18828@psf.upfronthosting.co.za>
Message-ID: <A3D8E167-9A2C-4C46-90C9-AACA508B48FF@gmail.com>


Demian Brecht added the comment:

>>>> urljoin('mailto:foo@', 'bar.com')
> 'mailto:bar.com'
> 
> which seems fairly sensible to me.

This is where joining arbitrary protocols gets tricky. Does it make sense to merge non-hierarchical protocols such as mailto? My initial reaction is "no" and what should actually happen here is one of two things:

1. The result is a simple concatenation: "mailto:foo at bar.com".
2. An exception is raised indicating that urljoin cannot determine how to handle merging base and url.

The above could happen in cases where either scheme is None for both base and url or the scheme to be used is any of urllib.parse.non_hierarchical.

> A more awkward question is if this behaviour of my patch is reasonable:
> 
>>>> urljoin('mailto:person-foo/bar at example.net', 'bar.com')
> 'mailto:person-foo/bar.com'

A couple thoughts on this: If urllib.parse.non_hierarchical is used to determine merge vs. simple concat (or exception), this specific case won't be an issue. Also, according to 6068, "mailto:person-foo/bar at example.net' is invalid (the "/" should be percent-encoded), but I don't think it should be the job of urljoin to understand the URI structures of each protocol, outside of logically join base and url.

> Yet another option, similar to my ?any_scheme=True? flag, might be to change from the ?uses_relative? white-list to a ?not_relative? black-list of URL schemes, so that urljoin() works for arbitrary schemes except for ones like ?mailto:? that are in the hard-coded list.

This list may already be present in urllib.parse.non_hierarchical. I also think it's worthwhile to do some further research against http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml to ensure the list is up to date.

If this path is chosen, I would suggest getting sign off from a couple core devs prior to investing time in this as all changes discussed so far are backwards incompatible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18828>
_______________________________________

From report at bugs.python.org  Thu Mar 19 16:38:35 2015
From: report at bugs.python.org (Joshua J Cogliati)
Date: Thu, 19 Mar 2015 15:38:35 +0000
Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler
 if using ccache
In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za>
Message-ID: <1426779515.57.0.41754411956.issue8027@psf.upfronthosting.co.za>


Joshua J Cogliati added the comment:

Looking at the patch (3078fdb7cf3d for Issue1488098) it has:
                 if target_lang == "c++" and self.compiler_cxx:
-                    linker[0] = self.compiler_cxx[0]

One possibility is that that the problem was:
 linker[0] = self.compiler_cxx[0]
which would also cause a compiler_cxx like:
export CXX="env BAR=FOO g++"
to fail.  Possibly the code:
 linker[i] = self.compiler_cxx[i]
managed to hit on an index value that worked better for the CXX that Ronald had on his system.

I think the root cause is the special casing of

if target_lang == "c++" and self.compiler_cxx:

and I think that few enough people use a c++ for extensions and of those, most use CXX="g++" or something similar where the complicated but incorrect version that is in Python works.

Basically, if you have something like CXX="g++" then both the version before 3078fdb7cf3d and after 3078fdb7cf3d work.
If you have something like CXX="env BAR=FOO g++"
then the version before 3078fdb7cf3d would not have worked.

I think it is likely that if 3078fdb7cf3d had completely eliminated:
-                if target_lang == "c++" and self.compiler_cxx:
-                    linker[0] = self.compiler_cxx[0]
instead of adding new code to try and work around the problem it also would have fixed the problem that Issue1488098 encountered.

I am guessing this problem really started with changeset 771b6f521b95 in 2002.  This codes purpose is:
 (UnixCCompiler.link): Included target_lang parameter, and made linker command use compiler_cxx, if target_lang is 'c++'. 
and that change is the one that added:
 linker[0] = self.compiler_cxx[0]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8027>
_______________________________________

From report at bugs.python.org  Thu Mar 19 16:40:13 2015
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 19 Mar 2015 15:40:13 +0000
Subject: [issue18828] urljoin behaves differently with custom and standard
 schemas
In-Reply-To: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za>
Message-ID: <1426779613.28.0.389741397946.issue18828@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Also, I would suggest still including the doc changes proposed by Madison in all versions prior to 3.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18828>
_______________________________________

From report at bugs.python.org  Thu Mar 19 16:40:37 2015
From: report at bugs.python.org (Maxim Kot)
Date: Thu, 19 Mar 2015 15:40:37 +0000
Subject: [issue23711] ConfigParser module blames on section less ini file
Message-ID: <1426779637.66.0.616231455892.issue23711@psf.upfronthosting.co.za>


New submission from Maxim Kot:

Wikipedia (http://en.wikipedia.org/wiki/INI_file#Sections) says:
>Keys may (but need not) be grouped into arbitrarily named sections

But when it's trying to parse file without section header - "MissingSectionHeaderError: File contains no section headers" raised.

Can such check be made optional and switched on for default for example?

----------
components: Library (Lib)
messages: 238537
nosy: Maxim Kot, lukasz.langa
priority: normal
severity: normal
status: open
title: ConfigParser module blames on section less ini file
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23711>
_______________________________________

From report at bugs.python.org  Thu Mar 19 16:51:50 2015
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 19 Mar 2015 15:51:50 +0000
Subject: [issue23325] Turn SIG_DFL and SIG_IGN into functions
In-Reply-To: <1422304710.21.0.213579052731.issue23325@psf.upfronthosting.co.za>
Message-ID: <1426780310.88.0.00570649926063.issue23325@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Thanks for the explanation, point taken.

However, it seems to me that changing the type of the constants from 'int' to 'function' is backwards incompatible, will break code, and is probably not worth it (and would require a deprecation period if it was worth it).

I still think the better answer is to delve into Modules/signalmodule.c and fix the comparisons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23325>
_______________________________________

From report at bugs.python.org  Thu Mar 19 17:26:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Mar 2015 16:26:47 +0000
Subject: [issue16314] Support xz compression in distutils
In-Reply-To: <1351114378.64.0.718374634123.issue16314@psf.upfronthosting.co.za>
Message-ID: <1426782407.64.0.531846643393.issue16314@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added tests for gztar, bztar and xztar. Added more asserts in other tests.

----------
Added file: http://bugs.python.org/file38564/distutils-lzma_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16314>
_______________________________________

From report at bugs.python.org  Thu Mar 19 17:38:55 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 19 Mar 2015 16:38:55 +0000
Subject: [issue23136] BUG in how _strptime() handles week 0
In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za>
Message-ID: <1426783135.58.0.393048866805.issue23136@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Serhiy,

Your latest patch LGTM.

----------
stage: patch review -> commit review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23136>
_______________________________________

From report at bugs.python.org  Thu Mar 19 17:49:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 16:49:51 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>
Message-ID: <1426783791.67.0.706652824481.issue23648@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I searched for "EINTR" in all manual pages of my Fedora 21. I found a long list of functions (filename of manual pages). But I didn't check each manual page.

There are false positive. For example, "stat" is listed, but in fact EINTR is only mentionned in commented text (not visible using the "man" command): "SVr4 documents additional stat() error conditions EINTR, ...".

Another example of false positive with system:
"""
Early  drafts  required, or allowed, system() to return with errno set to
[EINTR] if it was interrupted with a signal. This error return was removed, and
a requirement that system() not return until the child has terminated was
added. This  means  that  if  a waitpid()  call  in  system() exits with errno
set to [EINTR], system() must reissue the waitpid().
"""

Shell command to search for all EINTR:
find /usr/share/man -name "*.gz"|xargs zgrep -H EINTR > EINTR.txt

Shell command to extract file names from the output:

sed 's!.*/!!g' EINTR.txt|sed 's!\.[0-9][a-z]\?m\?\.gz:.*!!g'|sort -u > EINTR_files.txt

Filename of manual pages:

accept
aio_suspend
catclose
catgets
chmod
chown
chroot
clock_nanosleep
close
closedir
connect
curs_getch
dup
endgrent
epoll_wait
exec
execve
fallocate
fchdir
fchmod
fchown
fclose
fcntl
fflush
fgetc
fgetwc
flock
fopen
fork
fprintf
fputc
fputwc
freopen
fseek
fsetpos
fstatvfs
fsync
ftruncate
futex
getch
getgrent
getgrgid
getgrnam
getmsg
getpwent
getpwnam
getpwuid
has_key
inotify
ioctl
io_getevents
lchown
lio_listio
lockf
mknod
mq_open
mq_receive
mq_send
msgop
msgrcv
msgsnd
mvgetch
mvwgetch
nanosleep
open
pause
pclose
poll
posix_fallocate
posix_mem_offset
posix_trace_close
posix_trace_create
posix_trace_get_filter
posix_trace_getnext_event
posix_trace_start
posix_typed_mem_get_info
posix_typed_mem_open
pselect
pthread_atfork
pthread_attr_destroy
pthread_attr_getdetachstate
pthread_attr_getguardsize
pthread_attr_getinheritsched
pthread_attr_getschedparam
pthread_attr_getschedpolicy
pthread_attr_getscope
pthread_attr_getstack
pthread_attr_getstacksize
pthread_barrierattr_destroy
pthread_barrierattr_getpshared
pthread_barrier_destroy
pthread_barrier_wait
pthread_cancel
pthread_cleanup_pop
pthread_condattr_destroy
pthread_condattr_getclock
pthread_condattr_getpshared
pthread_cond_broadcast
pthread_cond_destroy
pthread_cond_init
pthread_cond_timedwait
pthread_create
pthread_detach
pthread_equal
pthread_getconcurrency
pthread_getschedparam
pthread_getspecific
pthread_join
pthread_key_create
pthread_key_delete
pthread_kill
pthread_mutexattr_destroy
pthread_mutexattr_getprioceiling
pthread_mutexattr_getprotocol
pthread_mutexattr_getpshared
pthread_mutexattr_getrobust
pthread_mutexattr_gettype
pthread_mutex_consistent
pthread_mutex_destroy
pthread_mutex_getprioceiling
pthread_mutex_lock
pthread_mutex_timedlock
pthread_once
pthread_rwlockattr_destroy
pthread_rwlockattr_getpshared
pthread_rwlock_destroy
pthread_rwlock_rdlock
pthread_rwlock_timedrdlock
pthread_rwlock_timedwrlock
pthread_rwlock_trywrlock
pthread_rwlock_unlock
pthreads
pthread_setcancelstate
pthread_setschedprio
pthread_sigmask
pthread_spin_destroy
pthread_spin_lock
pthread_spin_unlock
pthread_tryjoin_np
ptrace
putmsg
read
recv
recvfrom
recvmsg
request_key
restart_syscall
scanf
select
select_tut
semop
sem_open
sem_timedwait
sem_trywait
sem_wait
send
sendmsg
sendto
shm_open
sigaction
sighold
siginterrupt
signal
sigpause
sigsuspend
sigtimedwait
sigvec
sigwaitinfo
spu_run
stat
statfs
statvfs
strace
system
tcdrain
tcsetattr
tmpfile
truncate
ualarm
ungetch
unlink
usleep
ustat
wait
wait4
waitid
wgetch
write

Not interesting for Python:

Expect
HTTP::Tiny
Net::HTTP
POSIX
Tcl_AppendAllObjTypes
Tcl_ConvertToType
Tcl_GetObjType
Tcl_RegisterObjType
nfs
perlapio
perlfunc
perlipc
zmq_ctx_destroy
zmq_getsockopt
zmq_msg_recv
zmq_msg_send
zmq_poll
zmq_recv
zmq_recvmsg
zmq_send
zmq_sendmsg
zmq_setsockopt
zmq_term
zshmodules

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Thu Mar 19 18:15:06 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Mar 2015 17:15:06 +0000
Subject: [issue23136] BUG in how _strptime() handles week 0
In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za>
Message-ID: <20150319171503.30722.65413@psf.io>


Roundup Robot added the comment:

New changeset 350ea309953e by Serhiy Storchaka in branch '2.7':
Issue #23136: _strptime now uniformly handles all days in week 0, including
https://hg.python.org/cpython/rev/350ea309953e

New changeset 93e1da502338 by Serhiy Storchaka in branch '3.4':
Issue #23136: _strptime now uniformly handles all days in week 0, including
https://hg.python.org/cpython/rev/93e1da502338

New changeset 750c6d53890a by Serhiy Storchaka in branch 'default':
Issue #23136: _strptime now uniformly handles all days in week 0, including
https://hg.python.org/cpython/rev/750c6d53890a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23136>
_______________________________________

From report at bugs.python.org  Thu Mar 19 18:16:33 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Mar 2015 17:16:33 +0000
Subject: [issue23136] BUG in how _strptime() handles week 0
In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za>
Message-ID: <1426785393.53.0.161405672561.issue23136@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for the review Alexander. Thank you for your contribution Jim.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23136>
_______________________________________

From report at bugs.python.org  Thu Mar 19 18:18:13 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 19 Mar 2015 17:18:13 +0000
Subject: [issue23136] BUG in how _strptime() handles week 0
In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za>
Message-ID: <1426785493.05.0.570007493284.issue23136@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

"including Jan 30" - did you mean Dec 31?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23136>
_______________________________________

From report at bugs.python.org  Thu Mar 19 18:51:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Mar 2015 17:51:14 +0000
Subject: [issue23136] BUG in how _strptime() handles week 0
In-Reply-To: <1426785493.05.0.570007493284.issue23136@psf.upfronthosting.co.za>
Message-ID: <1529219.zB76gzmrY3@raxxla>


Serhiy Storchaka added the comment:

Oh, I meant Dec 30.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23136>
_______________________________________

From report at bugs.python.org  Thu Mar 19 18:52:56 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 19 Mar 2015 17:52:56 +0000
Subject: [issue23136] BUG in how _strptime() handles week 0
In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za>
Message-ID: <1426787576.25.0.38534914072.issue23136@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I don't think it is worth the effort to try to fix the commit message, but it would be nice to have the NEWS text corrected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23136>
_______________________________________

From report at bugs.python.org  Thu Mar 19 18:55:39 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Mar 2015 17:55:39 +0000
Subject: [issue23136] BUG in how _strptime() handles week 0
In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za>
Message-ID: <20150319175535.63586.23216@psf.io>


Roundup Robot added the comment:

New changeset d9f3dd1d6b48 by Serhiy Storchaka in branch '2.7':
Fixed Misc/NEWS entry for issue #23136.
https://hg.python.org/cpython/rev/d9f3dd1d6b48

New changeset afca9867e1bb by Serhiy Storchaka in branch '3.4':
Fixed Misc/NEWS entry for issue #23136.
https://hg.python.org/cpython/rev/afca9867e1bb

New changeset 18bc81ce6090 by Serhiy Storchaka in branch 'default':
Fixed Misc/NEWS entry for issue #23136.
https://hg.python.org/cpython/rev/18bc81ce6090

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23136>
_______________________________________

From report at bugs.python.org  Thu Mar 19 18:59:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Mar 2015 17:59:01 +0000
Subject: [issue23136] BUG in how _strptime() handles week 0
In-Reply-To: <1426787576.25.0.38534914072.issue23136@psf.upfronthosting.co.za>
Message-ID: <3474747.xSGxgq9vu2@raxxla>


Serhiy Storchaka added the comment:

Is it possible to fix the commit message without breaking any of cloned 
repositories that already have pulled it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23136>
_______________________________________

From report at bugs.python.org  Thu Mar 19 19:01:45 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 19 Mar 2015 18:01:45 +0000
Subject: [issue12006] strptime should implement %G, %V and %u directives
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1426788105.85.0.379411369125.issue12006@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

It would be nice to get this in for 3.5.  Does anyone have time/interest to address the last two comments?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Thu Mar 19 19:04:25 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 19 Mar 2015 18:04:25 +0000
Subject: [issue23136] BUG in how _strptime() handles week 0
In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za>
Message-ID: <1426788265.55.0.212144280545.issue23136@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Probably not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23136>
_______________________________________

From report at bugs.python.org  Thu Mar 19 20:25:55 2015
From: report at bugs.python.org (Jim Carroll)
Date: Thu, 19 Mar 2015 19:25:55 +0000
Subject: [issue23136] BUG in how _strptime() handles week 0
In-Reply-To: <1419973477.15.0.355513795882.issue23136@psf.upfronthosting.co.za>
Message-ID: <1426793155.6.0.768816728529.issue23136@psf.upfronthosting.co.za>


Jim Carroll added the comment:

Thanks for all your work !

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23136>
_______________________________________

From report at bugs.python.org  Thu Mar 19 20:57:42 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Mar 2015 19:57:42 +0000
Subject: [issue23712] Experiment: Assume that exact unicode hashes are perfect
 discriminators
Message-ID: <1426795062.72.0.102774381262.issue23712@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

This tracker item is for a thought experiment I'm running where I can collect the thoughts and discussions in one place.  It is not an active proposal for inclusion in Python.

The idea is to greatly speed-up the language for set/dict lookups of unicode value by skipping the exact comparison when the unicode type is exact and the 64-bit hash values are known to match.

Given the siphash and hash randomization, we get a 1 in 2**64 chance of a false positive (which is better than the error rate for non-ECC DRAM itself).  

However, since the siphash isn't cryptographically secure, presumably a malicious chooser of keys could generate a false positive on-purpose.

This technique is currently used by git and mercurial which use hash values for file and version graphs without checking for an exact match (because the chance of a false positive is vanishingly rare).

The Python test suite passes as does the test suites for a number of packages I have installed.

----------
assignee: rhettinger
components: Interpreter Core
files: assume_perf_uni_hash.diff
keywords: patch
messages: 238552
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Experiment:  Assume that exact unicode hashes are perfect discriminators
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file38565/assume_perf_uni_hash.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23712>
_______________________________________

From report at bugs.python.org  Thu Mar 19 21:04:59 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Mar 2015 20:04:59 +0000
Subject: [issue23712] Experiment: Assume that exact unicode hashes are perfect
 discriminators
In-Reply-To: <1426795062.72.0.102774381262.issue23712@psf.upfronthosting.co.za>
Message-ID: <1426795499.49.0.562163259792.issue23712@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file38566/assume_perf_uni_hash1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23712>
_______________________________________

From report at bugs.python.org  Thu Mar 19 21:05:03 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 19 Mar 2015 20:05:03 +0000
Subject: [issue23713] intermittent failure of multiprocessing unit test
 test_imap_unordered_handle_iterable_exception
Message-ID: <1426795503.26.0.283860442544.issue23713@psf.upfronthosting.co.za>


New submission from Davin Potts:

test_imap_unordered_handle_iterable_exception fails intermittently on some platforms due to the test being too rigid (fragile) about the order of the items being iterated over which, as the name would imply, is not guaranteed.

Of the multiprocessing module's test modules, test_multiprocessing_fork, test_multiprocessing_forkserver, and test_multiprocessing_spawn all leverage the unit test test_imap_unordered_handle_iterable_exception in multiple different contexts.  There are thus multiple opportunities for test_imap_unordered_handle_iterable_exception to fail due to this fragility -- it's maybe a little bit surprising the test doesn't fail more often than it does.

A patch is forthcoming.

----------
assignee: davin
components: Tests
messages: 238553
nosy: davin, jnoller, sbt
priority: normal
severity: normal
status: open
title: intermittent failure of multiprocessing unit test test_imap_unordered_handle_iterable_exception
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23713>
_______________________________________

From report at bugs.python.org  Thu Mar 19 21:05:19 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Mar 2015 20:05:19 +0000
Subject: [issue23712] Experiment: Assume that exact unicode hashes are perfect
 discriminators
In-Reply-To: <1426795062.72.0.102774381262.issue23712@psf.upfronthosting.co.za>
Message-ID: <1426795519.71.0.487982648526.issue23712@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Removed file: http://bugs.python.org/file38565/assume_perf_uni_hash.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23712>
_______________________________________

From report at bugs.python.org  Thu Mar 19 21:08:47 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 19 Mar 2015 20:08:47 +0000
Subject: [issue23713] intermittent failure of multiprocessing unit test
 test_imap_unordered_handle_iterable_exception
In-Reply-To: <1426795503.26.0.283860442544.issue23713@psf.upfronthosting.co.za>
Message-ID: <1426795727.18.0.0526762532238.issue23713@psf.upfronthosting.co.za>


Davin Potts added the comment:

Attaching patch for this fragile test for default/3.5 and 3.4 branches.

Blame for implementing the fragile test falls to @davin.  In my own defense, @davin also discovered it in testing on FreeBSD 10.1 i386-RELEASE.

----------
keywords: +patch
Added file: http://bugs.python.org/file38567/issue_23713_fix_fragile_imap_unordered_test_py35_and_py34.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23713>
_______________________________________

From report at bugs.python.org  Thu Mar 19 21:18:59 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 Mar 2015 20:18:59 +0000
Subject: [issue23706] pathlib.Path.write_text should include a newline argument
In-Reply-To: <1426757561.17.0.481870343329.issue23706@psf.upfronthosting.co.za>
Message-ID: <1426796339.99.0.192202090514.issue23706@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23706>
_______________________________________

From report at bugs.python.org  Thu Mar 19 21:20:53 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 Mar 2015 20:20:53 +0000
Subject: [issue23707] PEP 475: os.urandom() doesn't handle EINTR correctly
In-Reply-To: <1426767595.67.0.731351330983.issue23707@psf.upfronthosting.co.za>
Message-ID: <1426796453.19.0.490232513771.issue23707@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23707>
_______________________________________

From report at bugs.python.org  Thu Mar 19 21:41:23 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 19 Mar 2015 20:41:23 +0000
Subject: [issue23713] intermittent failure of multiprocessing unit test
 test_imap_unordered_handle_iterable_exception
In-Reply-To: <1426795503.26.0.283860442544.issue23713@psf.upfronthosting.co.za>
Message-ID: <1426797683.52.0.895215318826.issue23713@psf.upfronthosting.co.za>


Davin Potts added the comment:

Attaching patch for this fragile test for 2.7 branch.

Patches have been put through test.regrtest on OS X 10.10 (64-bit), FreeBSD 10.1 i386 (32-bit), and Raspbian Debian (ARMv6) thus far.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file38568/issue_23713_fix_fragile_imap_unordered_test_py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23713>
_______________________________________

From report at bugs.python.org  Thu Mar 19 21:51:49 2015
From: report at bugs.python.org (Hammerite)
Date: Thu, 19 Mar 2015 20:51:49 +0000
Subject: [issue23550] Add to unicodedata a function to query the "Quick_Check"
 property for a character
In-Reply-To: <1425147670.05.0.762030398058.issue23550@psf.upfronthosting.co.za>
Message-ID: <1426798309.59.0.316615847049.issue23550@psf.upfronthosting.co.za>


Hammerite added the comment:

Berker, I had not seen your or Ezio's review comments. The user interface here is new to me and I did not know to seek them out separately from the issue page. Thank you for pointing them out to me. I shall go through and look at the suggestions that were made.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23550>
_______________________________________

From report at bugs.python.org  Thu Mar 19 22:00:00 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Mar 2015 21:00:00 +0000
Subject: [issue23646] PEP 475: handle EINTR in the time module, retry sleep()
In-Reply-To: <1426174662.68.0.293958221956.issue23646@psf.upfronthosting.co.za>
Message-ID: <20150319205957.30714.11679@psf.io>


Roundup Robot added the comment:

New changeset b1abd06465fc by Victor Stinner in branch 'default':
Issue #23646: If time.sleep() is interrupted by a signal, the sleep is now
https://hg.python.org/cpython/rev/b1abd06465fc

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23646>
_______________________________________

From report at bugs.python.org  Thu Mar 19 22:21:08 2015
From: report at bugs.python.org (Mark Mikofski)
Date: Thu, 19 Mar 2015 21:21:08 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426800068.12.0.834481756647.issue22516@psf.upfronthosting.co.za>


Mark Mikofski added the comment:

I know this issue is closed, but as there is no voting or plus 1, I'll add my support for allowing local installation of not just Python-3, but also Python-2.7. I'm not sure what is gained by adding this restriction, or how difficult it would be to allow users without admin rights to install official python.org locally? Where is the source that needs to be patched?

IMO forcing Windows users with restricted rights to go to Anaconda, Enthought, or WinPython causes a fracture in the Python community, that decreases credibility for Windows users. Quoting Tim Peters from import this, "There should be one-- and preferably only one --obvious way to do it." not 3 or more ways. Having most new users installing Anaconda has many disadvantages:

1. Developement of an open source optimized version of NumPy (eg: using OpenBLAS) has a lower value proposition because users can just install Anaconda, which uses an unoptimized version of Intel MKL. Of course users can continue to get Christoph Gohlke's optimized MKL NumPy until he decides he doesn't want to anymore.

2. There will be two (or more) Python package indexes: PyPI, conda:binstar, binstar and pythonwheels. Do we really want Python packagers to have to upload to all of these repos? Which is the most current? etc. = less credibility for Python

3. There are/will be more than one python package installer and virtualenv tool: conda vs. pip/virtualev

Are there any repeats of this issue/feature request?

----------
nosy: +bwanamarko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Thu Mar 19 22:23:01 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Mar 2015 21:23:01 +0000
Subject: [issue22181] os.urandom() should use Linux 3.17 getrandom() syscall
In-Reply-To: <1407713563.4.0.264701036097.issue22181@psf.upfronthosting.co.za>
Message-ID: <20150319212258.16928.95719@psf.io>


Roundup Robot added the comment:

New changeset 4491bdb6527b by Victor Stinner in branch 'default':
Issue #22181: The availability of the getrandom() is now checked in configure,
https://hg.python.org/cpython/rev/4491bdb6527b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22181>
_______________________________________

From report at bugs.python.org  Thu Mar 19 22:28:10 2015
From: report at bugs.python.org (Mark Mikofski)
Date: Thu, 19 Mar 2015 21:28:10 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426800490.24.0.468898586876.issue22516@psf.upfronthosting.co.za>


Mark Mikofski added the comment:

one more note, NaCl (J. Morton), you can install from the msi to any directory you want by using the following from a command line opened to the folder where you have the installer:

C:\path\to\msi\download> msiexec /a python-2.7.9.amd64.msi TARGETDIR=C:\Python27

or

C:\path\to\msi\download> msiexec /a python-3.4.3.amd64.msi TARGETDIR=C:\Python34

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Thu Mar 19 22:31:47 2015
From: report at bugs.python.org (Ariel Bruner)
Date: Thu, 19 Mar 2015 21:31:47 +0000
Subject: [issue23714] Comprehension + eval doesn't work inside function
 definition
Message-ID: <1426800707.67.0.859108792069.issue23714@psf.upfronthosting.co.za>


New submission from Ariel Bruner:

The following code gives a NameError:

>>> def foo(bar):
	print {eval(x) for x in ['bar']}


>>> foo(2)

Traceback (most recent call last):
  File "<pyshell#52>", line 1, in <module>
    foo(2)
  File "<pyshell#51>", line 2, in foo
    print {eval(x) for x in ['bar']}
  File "<pyshell#51>", line 2, in <setcomp>
    print {eval(x) for x in ['bar']}
  File "<string>", line 1, in <module>
NameError: name 'bar' is not defined

I've seen this kind of bug reported for Python 3.X (e.g. Issue5242), and the behavior seems to be identical (e.g. can be fixed with {eval(x) for x in ['bar'] if True or bar}), but the previously reported bug reports mention comprehension is implemented differently on 2.X and that it should not happen there, so I thought that might be of interest.

----------
components: Windows
messages: 238561
nosy: Ariel Bruner, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Comprehension + eval doesn't work inside function definition
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23714>
_______________________________________

From report at bugs.python.org  Thu Mar 19 22:49:25 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 Mar 2015 21:49:25 +0000
Subject: [issue23714] Set comprehension + eval doesn't work inside function
 definition
In-Reply-To: <1426800707.67.0.859108792069.issue23714@psf.upfronthosting.co.za>
Message-ID: <1426801765.28.0.362556788539.issue23714@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report.  Your example is of a set comprehension.  Set and dictionary comprehensions were Python 3.2 features backported to Python 2.7 for compatibility and thus had no existing Python 2 compatibility concerns.  If you try a similar example using list comprehensions, which have been around in Python 2 for a long time, you'll see there is a difference in behavior between Python 2 and 3, which is what under discussion in Issue5242.

----------
components:  -Windows
nosy: +ned.deily -steve.dower, tim.golden, zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: Comprehension + eval doesn't work inside function definition -> Set comprehension + eval doesn't work inside function definition

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23714>
_______________________________________

From report at bugs.python.org  Thu Mar 19 22:52:00 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 Mar 2015 21:52:00 +0000
Subject: [issue23714] Set comprehension + eval doesn't work inside function
 definition
In-Reply-To: <1426800707.67.0.859108792069.issue23714@psf.upfronthosting.co.za>
Message-ID: <1426801920.98.0.974247953386.issue23714@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report.  Your example is of a set comprehension.  Set and dictionary comprehensions were Python 3.1 features backported to Python 2.7 for compatibility and thus had no existing Python 2 compatibility concerns.  If you try a similar example using list comprehensions, which have been around in Python 2 for a long time, you'll see there is a difference in behavior between Python 2 and 3, which is what under discussion in Issue5242.

https://docs.python.org/2/whatsnew/2.7.html#python-3-1-features

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23714>
_______________________________________

From report at bugs.python.org  Thu Mar 19 22:52:08 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 Mar 2015 21:52:08 +0000
Subject: [issue23714] Set comprehension + eval doesn't work inside function
 definition
In-Reply-To: <1426800707.67.0.859108792069.issue23714@psf.upfronthosting.co.za>
Message-ID: <1426801928.35.0.324456186098.issue23714@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
Removed message: http://bugs.python.org/msg238562

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23714>
_______________________________________

From report at bugs.python.org  Thu Mar 19 22:55:52 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 19 Mar 2015 21:55:52 +0000
Subject: [issue11344] Add os.path.splitpath(path) function
In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>
Message-ID: <1426802152.23.0.810137535994.issue11344@psf.upfronthosting.co.za>


?ric Araujo added the comment:

pathlib is in the stdlib now (see previous comments), maybe this should be closed as obsolete.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11344>
_______________________________________

From report at bugs.python.org  Thu Mar 19 22:56:43 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Mar 2015 21:56:43 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426802203.42.0.443720953861.issue2211@psf.upfronthosting.co.za>


R. David Murray added the comment:

The change to the signature of set is backward incompatible and should have a deprecation warning instead (yes, I know it isn't documented).  I'd even be OK with the value being ignored, but the signature shouldn't change.

There are a number of API/behavior changes noted in the NEWS which IMO need a versionchanged in the docs and an entry in whatsnew.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Thu Mar 19 22:57:04 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 19 Mar 2015 21:57:04 +0000
Subject: [issue23703] urljoin() with no directory segments duplicates filename
In-Reply-To: <1426748956.21.0.814756519005.issue23703@psf.upfronthosting.co.za>
Message-ID: <1426802224.97.0.615108273536.issue23703@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch looks good enough.

BTW I was thinking of something like this, which is a bit simpler, but I never tested it:

segments[1:-1] = filter(None, segments[1:-1])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23703>
_______________________________________

From report at bugs.python.org  Thu Mar 19 22:57:50 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 19 Mar 2015 21:57:50 +0000
Subject: [issue23171] csv.writer.writerow() does not accept generator (must be
 coerced to list)
In-Reply-To: <1420479102.66.0.846752030326.issue23171@psf.upfronthosting.co.za>
Message-ID: <1426802270.14.0.817804395224.issue23171@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23171>
_______________________________________

From report at bugs.python.org  Thu Mar 19 23:17:02 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 19 Mar 2015 22:17:02 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426803422.45.0.247080245704.issue22516@psf.upfronthosting.co.za>


Steve Dower added the comment:

Supporting proper per-user installs of Python 2.7 or 3.4 would require a second MSI that is configured to not ask for administrative privileges. The code is in Tools/msi/msi.py if you want to look at it (it's not my code and I have no intention of touching it), but the bigger concern is you're asking python.org to host twice as many files.

I'm planning to discuss installers at PyCon in a few weeks with the other core developers, so there may be a change of approach after that. Currently, we view Continuum and Enthought as the equivalent of any of the Linux distributors - either you live within their walled gardens, or you brave the outside world yourself. Linux distributions have shown that it's not a fatal split in the community, though it can lead to some obscure issues when people don't understand how they got/get Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Thu Mar 19 23:23:30 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 19 Mar 2015 22:23:30 +0000
Subject: [issue22634] importing _ctypes failed: undefined symbol:
 ffi_call_win32
In-Reply-To: <1413316785.82.0.044196497806.issue22634@psf.upfronthosting.co.za>
Message-ID: <1426803810.42.0.461391786962.issue22634@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22634>
_______________________________________

From report at bugs.python.org  Thu Mar 19 23:30:20 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Mar 2015 22:30:20 +0000
Subject: [issue23708] PEP 475: Add _Py_read() and _Py_write() functions
In-Reply-To: <1426772010.62.0.268490898603.issue23708@psf.upfronthosting.co.za>
Message-ID: <20150319223017.24242.82140@psf.io>


Roundup Robot added the comment:

New changeset c3c47ea32f72 by Victor Stinner in branch 'default':
Issue #23708: Add _Py_read() and _Py_write() functions to factorize code handle
https://hg.python.org/cpython/rev/c3c47ea32f72

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23708>
_______________________________________

From report at bugs.python.org  Thu Mar 19 23:30:20 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Mar 2015 22:30:20 +0000
Subject: [issue22181] os.urandom() should use Linux 3.17 getrandom() syscall
In-Reply-To: <1407713563.4.0.264701036097.issue22181@psf.upfronthosting.co.za>
Message-ID: <20150319223017.24242.42322@psf.io>


Roundup Robot added the comment:

New changeset 8c73af0b3cd9 by Victor Stinner in branch 'default':
Issue #22181: Fix dev_urandom_noraise(), try calling py_getrandom() before
https://hg.python.org/cpython/rev/8c73af0b3cd9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22181>
_______________________________________

From report at bugs.python.org  Thu Mar 19 23:32:13 2015
From: report at bugs.python.org (James Rutherford)
Date: Thu, 19 Mar 2015 22:32:13 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <1426804333.46.0.618891194865.issue23539@psf.upfronthosting.co.za>


James Rutherford added the comment:

Python 3 patch attached. The documentation has changed structure a little so I've adapted (simplified) this from the original. Otherwise, it's pretty much the same, except with python3 fixes, and incorporated feedback. I'll upload an updated 2.7 patch as well in a few minutes.

----------
Added file: http://bugs.python.org/file38569/issue23539-py3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23539>
_______________________________________

From report at bugs.python.org  Thu Mar 19 23:33:27 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 19 Mar 2015 22:33:27 +0000
Subject: [issue12006] strptime should implement %G, %V and %u directives
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1426804407.65.0.351854997915.issue12006@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Thu Mar 19 23:33:57 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Mar 2015 22:33:57 +0000
Subject: [issue23708] PEP 475: Add _Py_read() and _Py_write() functions
In-Reply-To: <1426772010.62.0.268490898603.issue23708@psf.upfronthosting.co.za>
Message-ID: <20150319223355.24234.27431@psf.io>


Roundup Robot added the comment:

New changeset e232b57ee784 by Victor Stinner in branch 'default':
Issue #23708: select.devpoll now retries its internal write() when interrupted
https://hg.python.org/cpython/rev/e232b57ee784

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23708>
_______________________________________

From report at bugs.python.org  Thu Mar 19 23:34:50 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 22:34:50 +0000
Subject: [issue23708] PEP 475: Add _Py_read() and _Py_write() functions
In-Reply-To: <1426772010.62.0.268490898603.issue23708@psf.upfronthosting.co.za>
Message-ID: <1426804490.01.0.648521726349.issue23708@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I commited both patches. Thanks Antoine for the review of py_read_write-2.patch, I removed the commented assertion.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23708>
_______________________________________

From report at bugs.python.org  Thu Mar 19 23:40:13 2015
From: report at bugs.python.org (James Rutherford)
Date: Thu, 19 Mar 2015 22:40:13 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <1426804813.98.0.110238937292.issue23539@psf.upfronthosting.co.za>


James Rutherford added the comment:

Updated 2.7 patch attached.

----------
Added file: http://bugs.python.org/file38570/issue23539-py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23539>
_______________________________________

From report at bugs.python.org  Thu Mar 19 23:43:59 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Mar 2015 22:43:59 +0000
Subject: [issue23707] PEP 475: os.urandom() doesn't handle EINTR correctly
In-Reply-To: <1426767595.67.0.731351330983.issue23707@psf.upfronthosting.co.za>
Message-ID: <20150319224356.4207.16185@psf.io>


Roundup Robot added the comment:

New changeset e57b4d464d1c by Victor Stinner in branch 'default':
Issue #23707: On UNIX, os.urandom() now calls the Python signal handler when
https://hg.python.org/cpython/rev/e57b4d464d1c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23707>
_______________________________________

From report at bugs.python.org  Thu Mar 19 23:44:11 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 22:44:11 +0000
Subject: [issue23707] PEP 475: os.urandom() doesn't handle EINTR correctly
In-Reply-To: <1426767595.67.0.731351330983.issue23707@psf.upfronthosting.co.za>
Message-ID: <1426805051.68.0.490825817271.issue23707@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23707>
_______________________________________

From report at bugs.python.org  Thu Mar 19 23:44:53 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 22:44:53 +0000
Subject: [issue23709] Refactor ossaudiodev: use _Py_read and _Py_write with
 the Py_buffer
In-Reply-To: <1426772209.38.0.996436244503.issue23709@psf.upfronthosting.co.za>
Message-ID: <1426805093.05.0.435270212542.issue23709@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +neologix, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23709>
_______________________________________

From report at bugs.python.org  Thu Mar 19 23:47:19 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 22:47:19 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426805239.69.0.427132689502.issue23700@psf.upfronthosting.co.za>


STINNER Victor added the comment:

test_csv now fails on Windows:

http://buildbot.python.org/all/builders/x86 Windows7 3.x/builds/9421/

======================================================================
ERROR: test_read_dict_fieldnames_from_file (test.test_csv.TestDictFields)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_csv.py", line 629, in test_read_dict_fieldnames_from_file
    self.assertEqual(next(reader), {"f1": '1', "f2": '2', "f3": 'abc'})
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\csv.py", line 110, in __next__
    row = next(self.reader)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\tempfile.py", line 431, in __iter__
    yield from iter(self.file)
ValueError: I/O operation on closed file.

----------
nosy: +haypo
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Thu Mar 19 23:53:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Mar 2015 22:53:38 +0000
Subject: [issue23708] PEP 475: Add _Py_read() and _Py_write() functions
In-Reply-To: <1426772010.62.0.268490898603.issue23708@psf.upfronthosting.co.za>
Message-ID: <20150319225335.16934.41525@psf.io>


Roundup Robot added the comment:

New changeset 116e4c40115f by Victor Stinner in branch 'default':
Issue #23708: Fix _Py_read() compilation error on Windows
https://hg.python.org/cpython/rev/116e4c40115f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23708>
_______________________________________

From report at bugs.python.org  Thu Mar 19 23:57:28 2015
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 19 Mar 2015 22:57:28 +0000
Subject: [issue23712] Experiment: Assume that exact unicode hashes are perfect
 discriminators
In-Reply-To: <1426795062.72.0.102774381262.issue23712@psf.upfronthosting.co.za>
Message-ID: <1426805848.11.0.534869590204.issue23712@psf.upfronthosting.co.za>


Donald Stufft added the comment:

I'm not sure what you mean by "Siphash isn't cryptographically secure". One of the key points of Siphash is that it *is* cryptographically secure. It has a smaller space than your typical hash function (MD5, SHA1, SHA2, etc) which means that collisions themselves are more likely, but the hash itself is cryptographically secure against pre-image attacks and it has collision resistance (collision resistance is different than just getting a collision).

----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23712>
_______________________________________

From report at bugs.python.org  Fri Mar 20 00:00:18 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 23:00:18 +0000
Subject: [issue23646] PEP 475: handle EINTR in the time module, retry sleep()
In-Reply-To: <1426174662.68.0.293958221956.issue23646@psf.upfronthosting.co.za>
Message-ID: <1426806018.42.0.709211343315.issue23646@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23646>
_______________________________________

From report at bugs.python.org  Fri Mar 20 00:01:40 2015
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 19 Mar 2015 23:01:40 +0000
Subject: [issue23712] Experiment: Assume that exact unicode hashes are perfect
 discriminators
In-Reply-To: <1426795062.72.0.102774381262.issue23712@psf.upfronthosting.co.za>
Message-ID: <1426806100.55.0.69770374717.issue23712@psf.upfronthosting.co.za>


Donald Stufft added the comment:

To be clear, I have no opinion on your specific proposal and I don't know if the difference between "cryptographically secure" and "not cryptographically secure" matters for it. I just wanted to be clear that with SipHash an attacker should *not* be able to choose keys that will collide on purpose, but given the small output space (64bits IIRC) that collisions are more likely to occur than with MD5, SHA1, SHA2, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23712>
_______________________________________

From report at bugs.python.org  Fri Mar 20 00:10:31 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 19 Mar 2015 23:10:31 +0000
Subject: [issue16834] ioctl mutate_flag behavior in regard to the buffer size
 limit
In-Reply-To: <1357052189.92.0.352175087043.issue16834@psf.upfronthosting.co.za>
Message-ID: <1426806631.88.0.688747278907.issue16834@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looking at the C code, if a writable buffer is passed, mutate_arg is false, and the buffer is longer than 1024 bytes, then a ValueError is raised:

>>> ioctl(0, 0, bytearray(2048), False)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: ioctl string arg too long

So it seems the implementation does not match the documentation?s claim that ?the 1024 byte limit . . . is avoided?. IMO this is an implementation bug.

But instead of (or in addition to) fixing it, maybe we could consider removing ?mutate_flag? parameter altogether. It was originally added as a backwards compatibility helper for Issue 555817 in Python 2.3, and changed to True by default in Python 2.5.

----------
components: +Extension Modules
nosy: +vadmium
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16834>
_______________________________________

From report at bugs.python.org  Fri Mar 20 00:10:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Mar 2015 23:10:32 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <20150319231029.24234.50730@psf.io>


Roundup Robot added the comment:

New changeset 7d4eb5902f82 by Antoine Pitrou in branch 'default':
Issue #23632: Memoryviews now allow tuple indexing (including for multi-dimensional memoryviews).
https://hg.python.org/cpython/rev/7d4eb5902f82

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Fri Mar 20 00:11:26 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 19 Mar 2015 23:11:26 +0000
Subject: [issue23632] memoryview doesn't allow tuple-indexing
In-Reply-To: <1426024001.13.0.843495227824.issue23632@psf.upfronthosting.co.za>
Message-ID: <1426806686.91.0.332080580306.issue23632@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I didn't add the 2d example as the double cast is quite ugly.  Probably we should allow casting when the format stays the same.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23632>
_______________________________________

From report at bugs.python.org  Fri Mar 20 00:22:49 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Mar 2015 23:22:49 +0000
Subject: [issue23686] Update Windows and OS X installer OpenSSL to 1.0.2a
In-Reply-To: <1426591782.15.0.995555672449.issue23686@psf.upfronthosting.co.za>
Message-ID: <20150319232246.16920.67604@psf.io>


Roundup Robot added the comment:

New changeset 447794596266 by Ned Deily in branch '2.7':
Issue #23686: Update OS X 10.5 installer build to use OpenSSL 1.0.2a.
https://hg.python.org/cpython/rev/447794596266

New changeset 59b8a83ea50b by Ned Deily in branch '3.4':
Issue #23686: Update OS X 10.5 installer build to use OpenSSL 1.0.2a.
https://hg.python.org/cpython/rev/59b8a83ea50b

New changeset e43e5cc887fe by Ned Deily in branch 'default':
Issue #23686: Update OS X 10.5 installer build to use OpenSSL 1.0.2a.
https://hg.python.org/cpython/rev/e43e5cc887fe

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23686>
_______________________________________

From report at bugs.python.org  Fri Mar 20 00:25:28 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 Mar 2015 23:25:28 +0000
Subject: [issue23686] Update Windows and OS X installer OpenSSL to 1.0.2a
In-Reply-To: <1426591782.15.0.995555672449.issue23686@psf.upfronthosting.co.za>
Message-ID: <1426807528.75.0.393519128612.issue23686@psf.upfronthosting.co.za>


Ned Deily added the comment:

1.0.2a is now available.
https://www.openssl.org/source/openssl-1.0.2a.tar.gz

The OS X 10.5 installer builds are now updated.  Leaving the issue open for updates to the Windows installers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23686>
_______________________________________

From report at bugs.python.org  Fri Mar 20 00:30:17 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Mar 2015 23:30:17 +0000
Subject: [issue23709] Refactor ossaudiodev: use _Py_read and _Py_write with
 the Py_buffer
In-Reply-To: <1426772209.38.0.996436244503.issue23709@psf.upfronthosting.co.za>
Message-ID: <20150319233014.114146.80320@psf.io>


Roundup Robot added the comment:

New changeset d564695b67bb by Victor Stinner in branch 'default':
Issue #23709: The ossaudiodev module now retries read/write when interrupted by
https://hg.python.org/cpython/rev/d564695b67bb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23709>
_______________________________________

From report at bugs.python.org  Fri Mar 20 00:31:22 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 23:31:22 +0000
Subject: [issue23709] Refactor ossaudiodev: use _Py_read and _Py_write with
 the Py_buffer
In-Reply-To: <1426772209.38.0.996436244503.issue23709@psf.upfronthosting.co.za>
Message-ID: <1426807882.09.0.0897681401101.issue23709@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I commited changes to use _Py_read() and _Py_write().

I attach an updated patch to use Py_ssize_t instead of int, and to use Py_buffer instead of char*.

----------
Added file: http://bugs.python.org/file38571/ossaudiodev-py_buffer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23709>
_______________________________________

From report at bugs.python.org  Fri Mar 20 00:33:43 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Mar 2015 23:33:43 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>
Message-ID: <1426808023.67.0.171678176839.issue23648@psf.upfronthosting.co.za>


STINNER Victor added the comment:

unittest_setitimer.patch: hack unittest.TestCase.run() to inject signals every 1 ms, send the first signal in 100 ms. It should help to detect functions which doesn't retry on EINTR.

----------
keywords: +patch
Added file: http://bugs.python.org/file38572/unittest_setitimer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Fri Mar 20 00:57:20 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 19 Mar 2015 23:57:20 +0000
Subject: [issue23711] ConfigParser module blames on section less ini file
In-Reply-To: <1426779637.66.0.616231455892.issue23711@psf.upfronthosting.co.za>
Message-ID: <1426809440.64.0.0631703306604.issue23711@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think this is already discussed in Issue 22253.

----------
nosy: +vadmium
resolution:  -> duplicate
status: open -> closed
superseder:  -> ConfigParser does not handle files without sections

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23711>
_______________________________________

From report at bugs.python.org  Fri Mar 20 01:06:45 2015
From: report at bugs.python.org (Davin Potts)
Date: Fri, 20 Mar 2015 00:06:45 +0000
Subject: [issue23042] ctypes module doesn't build on FreeBSD x86
In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za>
Message-ID: <1426810005.76.0.0805236870218.issue23042@psf.upfronthosting.co.za>


Davin Potts added the comment:

Inheriting the priority from issue22634 which has been marked closed->duplicate (duplicate of this issue).

Previously issue22634 was given a priority of "release blocker" by @pitrou.  Issue22634 described how this issue also afflicts 32-bit builds on multiple RHEL release versions.

----------
nosy: +benjamin.peterson, berker.peksag, larry, pitrou
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23042>
_______________________________________

From report at bugs.python.org  Fri Mar 20 01:11:05 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Mar 2015 00:11:05 +0000
Subject: [issue23342] run() - unified high-level interface for subprocess
In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za>
Message-ID: <1426810265.29.0.0754606818018.issue23342@psf.upfronthosting.co.za>


Martin Panter added the comment:

One thing that just popped into my mind that I don?t think has been discussed: The patch adds the new run() function to subprocess.__all__, but the CompletedProcess class is still missing. Was that an oversight or a conscious decision?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23342>
_______________________________________

From report at bugs.python.org  Fri Mar 20 01:13:42 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 20 Mar 2015 00:13:42 +0000
Subject: [issue23703] urljoin() with no directory segments duplicates filename
In-Reply-To: <1426748956.21.0.814756519005.issue23703@psf.upfronthosting.co.za>
Message-ID: <1426810422.33.0.0348906285786.issue23703@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Yep, that's a lot cleaner and tests pass. I've updated the patch with that line. Thanks.

----------
Added file: http://bugs.python.org/file38573/issue23703_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23703>
_______________________________________

From report at bugs.python.org  Fri Mar 20 01:31:58 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Fri, 20 Mar 2015 00:31:58 +0000
Subject: [issue23342] run() - unified high-level interface for subprocess
In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za>
Message-ID: <1426811518.93.0.707286956777.issue23342@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Thanks, that was an oversight. Patch 5 adds CompletedProcess to __all__.

----------
Added file: http://bugs.python.org/file38574/subprocess_run5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23342>
_______________________________________

From report at bugs.python.org  Fri Mar 20 01:43:04 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Fri, 20 Mar 2015 00:43:04 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1426812184.21.0.243135924795.issue23496@psf.upfronthosting.co.za>


Ryan Gonzalez added the comment:

I am slowly attaching the patches I created.

Titles:

- issue_16353.patch - Issue 16353 for tip
- issue_20305_tweaked.patch - Issue 2305 for tip
- rjmatthews62_fixes_tweaked.patch - rjmatthews62 at gmail.com's Android fixes (a bit more modularized)
- unused_var.patch - An extension of 2305. Can't figure out how to merge them.
- issue_21668.patch - Issue 21668 for tip
- issue_20306.patch - Guess...
- android_segfault_fix.patch - The actual segfault fix
- kbox_fix.patch - Cyd's KBox fixes

Someone, please test them!

----------
Added file: http://bugs.python.org/file38575/android_segfault_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Fri Mar 20 01:43:15 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Fri, 20 Mar 2015 00:43:15 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1426812195.26.0.947864144413.issue23496@psf.upfronthosting.co.za>


Changes by Ryan Gonzalez <rymg19 at gmail.com>:


Added file: http://bugs.python.org/file38576/kbox_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Fri Mar 20 01:43:26 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Fri, 20 Mar 2015 00:43:26 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1426812206.47.0.55787947625.issue23496@psf.upfronthosting.co.za>


Changes by Ryan Gonzalez <rymg19 at gmail.com>:


Added file: http://bugs.python.org/file38577/issue_16353.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Fri Mar 20 01:43:34 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Fri, 20 Mar 2015 00:43:34 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1426812214.85.0.234720211756.issue23496@psf.upfronthosting.co.za>


Changes by Ryan Gonzalez <rymg19 at gmail.com>:


Added file: http://bugs.python.org/file38578/issue_20305_tweaked.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Fri Mar 20 01:43:45 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Fri, 20 Mar 2015 00:43:45 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1426812225.54.0.423913146053.issue23496@psf.upfronthosting.co.za>


Changes by Ryan Gonzalez <rymg19 at gmail.com>:


Added file: http://bugs.python.org/file38579/issue_20306.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Fri Mar 20 01:44:10 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Fri, 20 Mar 2015 00:44:10 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1426812250.23.0.154615824897.issue23496@psf.upfronthosting.co.za>


Changes by Ryan Gonzalez <rymg19 at gmail.com>:


Added file: http://bugs.python.org/file38580/issue_21668.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Fri Mar 20 01:44:18 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Fri, 20 Mar 2015 00:44:18 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1426812258.01.0.52827694808.issue23496@psf.upfronthosting.co.za>


Changes by Ryan Gonzalez <rymg19 at gmail.com>:


Added file: http://bugs.python.org/file38581/unused_var.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Fri Mar 20 01:44:25 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Fri, 20 Mar 2015 00:44:25 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1426812265.95.0.360034272369.issue23496@psf.upfronthosting.co.za>


Changes by Ryan Gonzalez <rymg19 at gmail.com>:


Added file: http://bugs.python.org/file38582/rjmatthews62_fixes_tweaked.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Fri Mar 20 01:47:47 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 20 Mar 2015 00:47:47 +0000
Subject: [issue23712] Experiment: Assume that exact unicode hashes are perfect
 discriminators
In-Reply-To: <1426795062.72.0.102774381262.issue23712@psf.upfronthosting.co.za>
Message-ID: <1426812467.32.0.315256734462.issue23712@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Assuming Siphash is in fact cryptographically secure (in the sense you can't choose a desired result hash with better odds that brute force), and it appears to be so, with a keyspace of 64 bits, if it's evenly distributed (which a cryptographically secure hash should be), that implies to even have a 1% chance of any two keys in a set colliding, you'd need over 2**29 keys ( you can plug in your own numbers for the conditional calculation here https://lazycackle.com/Probability_of_repeated_event_online_calculator__birthday_problem_.html ). Even at the one ten thousandth of a percent collision threshold, you're talking about a set of 6 million strings to find even one pair that match.

I'd still be leery of using such an approach for general purpose sets and dicts, where they could conceivably contain enough entries to pose a risk (vanishingly small, but not "heat death of the universe" small). But for Python implementation dictionaries (module, nested scope, class, and instance dictionaries), where we're talking about maybe a thousand attributes in extreme cases, which are almost never under the control of an "attacker" in any event, I could definitely see a low risk win. If you're assuming a dictionary with less than 10,000 keys, that's a hit would be literally one in a trillion; under a hundred and you're below one in a quadrillion chance, which I think is safe enough. If you wanted to make it "safe" you could conceivably use an approach that changed algorithms up front, depending on the size of the dictionary; less than a hundred entries, use hash only lookup, above 100, use "safe" lookup.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23712>
_______________________________________

From report at bugs.python.org  Fri Mar 20 01:58:48 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 20 Mar 2015 00:58:48 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <1426813128.93.0.649136245262.issue23539@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23539>
_______________________________________

From report at bugs.python.org  Fri Mar 20 02:01:59 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 01:01:59 +0000
Subject: [issue23646] PEP 475: handle EINTR in the time module, retry sleep()
In-Reply-To: <1426174662.68.0.293958221956.issue23646@psf.upfronthosting.co.za>
Message-ID: <20150320010156.24238.63353@psf.io>


Roundup Robot added the comment:

New changeset 9882cc2efd36 by Victor Stinner in branch 'default':
Issue #23646: Enhance precision of time.sleep() and socket timeout when
https://hg.python.org/cpython/rev/9882cc2efd36

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23646>
_______________________________________

From report at bugs.python.org  Fri Mar 20 02:13:29 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 01:13:29 +0000
Subject: [issue23715] PEP 475: signal.sigtimedwait() must retry if
 sigtimedwait() failed with EINTR
Message-ID: <1426814009.06.0.724045685729.issue23715@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch changes signal.sigtimedwait() to retry if sigtimedwait() failed with EINTR and the signal handler didn't raise an exception.

----------
files: sigtimedwait_eintr.patch
keywords: patch
messages: 238595
nosy: haypo
priority: normal
severity: normal
status: open
title: PEP 475: signal.sigtimedwait() must retry if sigtimedwait() failed with EINTR
versions: Python 3.5
Added file: http://bugs.python.org/file38583/sigtimedwait_eintr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23715>
_______________________________________

From report at bugs.python.org  Fri Mar 20 02:18:36 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 01:18:36 +0000
Subject: [issue23715] PEP 475: handle EINTR in the signal module
In-Reply-To: <1426814009.06.0.724045685729.issue23715@psf.upfronthosting.co.za>
Message-ID: <1426814316.57.0.146431929195.issue23715@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It looks like signal.sigwaitinfo() can also fail with InterruptedError. It should also be modified.

----------
title: PEP 475: signal.sigtimedwait() must retry if sigtimedwait() failed with EINTR -> PEP 475: handle EINTR in the signal module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23715>
_______________________________________

From report at bugs.python.org  Fri Mar 20 02:19:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 01:19:05 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>
Message-ID: <1426814345.42.0.489527291852.issue23648@psf.upfronthosting.co.za>


STINNER Victor added the comment:

New issue #23715: handle EINTR in the signal module.

----------
dependencies: +PEP 475: handle EINTR in the signal module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Fri Mar 20 02:41:30 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Mar 2015 01:41:30 +0000
Subject: [issue23001] Accept mutable bytes-like objects
In-Reply-To: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za>
Message-ID: <1426815690.36.0.995952672198.issue23001@psf.upfronthosting.co.za>


Martin Panter added the comment:

I had a closer look at the changes, and most of them seem good. However I think I found one leak in fcntl(); see Reitveld.

I noticed there is no test for ?ossaudiodev?. Would that be too hard, or is it just an oversight?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23001>
_______________________________________

From report at bugs.python.org  Fri Mar 20 03:06:25 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 02:06:25 +0000
Subject: [issue23646] PEP 475: handle EINTR in the time module, retry sleep()
In-Reply-To: <1426174662.68.0.293958221956.issue23646@psf.upfronthosting.co.za>
Message-ID: <20150320020621.114140.81024@psf.io>


Roundup Robot added the comment:

New changeset 1291649f38df by Victor Stinner in branch 'default':
Issue #23646: Fix test_threading on Windows
https://hg.python.org/cpython/rev/1291649f38df

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23646>
_______________________________________

From report at bugs.python.org  Fri Mar 20 03:14:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 02:14:57 +0000
Subject: [issue23716] test_multiprocessing_spawn hangs on x86 Ubuntu Shared 3.x
Message-ID: <1426817697.21.0.499031040791.issue23716@psf.upfronthosting.co.za>


New submission from STINNER Victor:

It looks like the changeset 0b99d7043a99 (issue #23694) introduced a regression:

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/11358/

[340/393] test_multiprocessing_spawn
Timeout (1:00:00)!
Thread 0x55aacdc0 (most recent call first):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 379 in _recv
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 407 in _recv_bytes
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 250 in recv
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 717 in _callmethod
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 943 in acquire
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/_test_multiprocessing.py", line 911 in test_notify_all
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 577 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 625 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/runner.py", line 176 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1772 in _run_suite
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1806 in run_unittest
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1283 in test_runner
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1284 in runtest_inner
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 967 in runtest
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 763 in main
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1568 in main_in_temp_cwd
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/__main__.py", line 3 in <module>
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/runpy.py", line 85 in _run_code
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/runpy.py", line 170 in _run_module_as_main
make: *** [buildbottest] Error 1

----------
messages: 238600
nosy: haypo, sbt
priority: normal
severity: normal
status: open
title: test_multiprocessing_spawn hangs on x86 Ubuntu Shared 3.x
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23716>
_______________________________________

From report at bugs.python.org  Fri Mar 20 03:18:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 02:18:45 +0000
Subject: [issue23716] test_multiprocessing_spawn hangs on x86 Ubuntu Shared 3.x
In-Reply-To: <1426817697.21.0.499031040791.issue23716@psf.upfronthosting.co.za>
Message-ID: <1426817925.69.0.446157772946.issue23716@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oops, I posted the output of http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/11359/steps/test/logs/stdio

--

Other output:

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/11358/steps/test/logs/stdio

[131/393] test_multiprocessing_spawn
Timeout (1:00:00)!
Thread 0x58300b40 (most recent call first):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 293 in wait
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/queues.py", line 224 in _feed
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 871 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 923 in _bootstrap_inner
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 891 in _bootstrap

Thread 0x55aacdc0 (most recent call first):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/popen_fork.py", line 29 in poll
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/popen_fork.py", line 51 in wait
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/process.py", line 121 in join
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/_test_multiprocessing.py", line 714 in test_task_done
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 577 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 625 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/runner.py", line 176 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1772 in _run_suite
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1806 in run_unittest
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1283 in test_runner
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1284 in runtest_inner
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 967 in runtest
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 763 in main
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1568 in main_in_temp_cwd
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/__main__.py", line 3 in <module>
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/runpy.py", line 85 in _run_code
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/runpy.py", line 170 in _run_module_as_main
make: *** [buildbottest] Error 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23716>
_______________________________________

From report at bugs.python.org  Fri Mar 20 03:25:05 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Mar 2015 02:25:05 +0000
Subject: [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1426818305.7.0.751334055247.issue22832@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22832>
_______________________________________

From report at bugs.python.org  Fri Mar 20 03:47:33 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Mar 2015 02:47:33 +0000
Subject: [issue23171] csv.writer.writerow() does not accept generator (must be
 coerced to list)
In-Reply-To: <1420479102.66.0.846752030326.issue23171@psf.upfronthosting.co.za>
Message-ID: <1426819653.09.0.606717237989.issue23171@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23171>
_______________________________________

From report at bugs.python.org  Fri Mar 20 03:47:50 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Mar 2015 02:47:50 +0000
Subject: [issue21802] Reader of BufferedRWPair is not closed if writer's
 close() fails
In-Reply-To: <1403113942.14.0.852744973704.issue21802@psf.upfronthosting.co.za>
Message-ID: <1426819670.48.0.167355345308.issue21802@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21802>
_______________________________________

From report at bugs.python.org  Fri Mar 20 03:58:54 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Mar 2015 02:58:54 +0000
Subject: [issue23681] Have -b warn when directly comparing ints and bytes
In-Reply-To: <1426525530.11.0.0814957947674.issue23681@psf.upfronthosting.co.za>
Message-ID: <1426820334.62.0.530620851091.issue23681@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23681>
_______________________________________

From report at bugs.python.org  Fri Mar 20 03:59:30 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Mar 2015 02:59:30 +0000
Subject: [issue23676] Add support of UnicodeTranslateError in standard error
 handlers
In-Reply-To: <1426456748.16.0.28109004659.issue23676@psf.upfronthosting.co.za>
Message-ID: <1426820370.95.0.55379226516.issue23676@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23676>
_______________________________________

From report at bugs.python.org  Fri Mar 20 04:00:09 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Mar 2015 03:00:09 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za>
Message-ID: <1426820409.6.0.131699775355.issue22831@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22831>
_______________________________________

From report at bugs.python.org  Fri Mar 20 04:00:40 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Mar 2015 03:00:40 +0000
Subject: [issue15133] tkinter.BooleanVar.get() behavior and docstring disagree
In-Reply-To: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za>
Message-ID: <1426820440.95.0.33857477916.issue15133@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15133>
_______________________________________

From report at bugs.python.org  Fri Mar 20 04:30:02 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 20 Mar 2015 03:30:02 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za>
Message-ID: <1426822202.36.0.887116341318.issue22831@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Looks good. A couple of comments:

* Doc/includes/email-* changes have already been committed.

* There is a commented-out line in Tools/scripts/nm2def.py:

  -    f.close()
  +    # f.close()

* The patch is huge, I'd commit Tools/ and Lib/test/ parts separately.

* Most of the open(..., 'r') usages can be changed to open(...)

* It would be good to add context management protocol support to http.client.HTTPConnection.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22831>
_______________________________________

From report at bugs.python.org  Fri Mar 20 05:43:36 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 20 Mar 2015 04:43:36 +0000
Subject: [issue22826] Support context management protocol in bkfile
In-Reply-To: <1415549255.85.0.105011780634.issue22826@psf.upfronthosting.co.za>
Message-ID: <1426826616.57.0.15682801314.issue22826@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
assignee:  -> serhiy.storchaka
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22826>
_______________________________________

From report at bugs.python.org  Fri Mar 20 06:14:40 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 20 Mar 2015 05:14:40 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426828480.23.0.786628873227.issue2211@psf.upfronthosting.co.za>


Demian Brecht added the comment:

The attached patch reverts back to the old set() API, ignoring the parameter and adding a deprecation warning. I've also added a few versionchanged and deprecated tags in the Morsel docs. Other than the deprecation note in whatsnew/3.5.rst that was added, I'm not entirely sure what you're suggesting should be added (I'm also not overly familiar with what qualifies for "what's new" additions in the various categories without causing unnecessary noise).

----------
Added file: http://bugs.python.org/file38584/http_cookies_morsel_deprecate_set.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Fri Mar 20 06:33:44 2015
From: report at bugs.python.org (irdb)
Date: Fri, 20 Mar 2015 05:33:44 +0000
Subject: [issue17535] IDLE: Add an option to show line numbers along the left
 side of the editor window, and have it enabled by default.
In-Reply-To: <1364102013.73.0.373085073641.issue17535@psf.upfronthosting.co.za>
Message-ID: <1426829624.27.0.348635102756.issue17535@psf.upfronthosting.co.za>


Changes by irdb <dalba.wiki at gmail.com>:


----------
nosy: +irdb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17535>
_______________________________________

From report at bugs.python.org  Fri Mar 20 06:52:01 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 20 Mar 2015 05:52:01 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <1426830721.61.0.669515124328.issue23539@psf.upfronthosting.co.za>


Demian Brecht added the comment:

One super minor comment left in Rietveld (py3 patch). Otherwise LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23539>
_______________________________________

From report at bugs.python.org  Fri Mar 20 06:52:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 05:52:23 +0000
Subject: [issue12006] strptime should implement %G, %V and %u directives
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1426830743.61.0.305555201022.issue12006@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch is synchronized with the tip, added the versionadded directives and whatsnews entry, addressed sasha's comment on Rietveld. Fixed a bug: %a and %A now are interchangeable with %u as well as with %w.

I don't understand what more test are needed. Existing tests cover %Y %V ambiguity:

>>> date(1906, 12, 31).strftime('%G %V %u')
'1907 01 1'
>>> date(1917, 12, 31).strftime('%G %V %u')
'1918 01 1'

----------
Added file: http://bugs.python.org/file38585/issue12006_5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Fri Mar 20 07:18:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 06:18:30 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426832310.9.0.20428345958.issue23700@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Following patch fixes the issue, but I don't understand why.

----------
Added file: http://bugs.python.org/file38586/tempfile_iter_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 07:53:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 06:53:28 +0000
Subject: [issue23001] Accept mutable bytes-like objects
In-Reply-To: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za>
Message-ID: <1426834408.96.0.210092837937.issue23001@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Martin. Yes, the problem with fcntl() is not so easy and I'll left it for the separate issue.

> I noticed there is no test for ?ossaudiodev?. Would that be too hard, or is it just an oversight?

It is hard because test_ossaudiodev is not designed to just apply the test with different type of data, and this test doesn't work on my computer at all (no /dev/dsp).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23001>
_______________________________________

From report at bugs.python.org  Fri Mar 20 08:04:51 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 07:04:51 +0000
Subject: [issue23001] Accept mutable bytes-like objects
In-Reply-To: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za>
Message-ID: <20150320070447.70036.23007@psf.io>


Roundup Robot added the comment:

New changeset 17c77938c4e2 by Serhiy Storchaka in branch 'default':
Issue #23001: Few functions in modules mmap, ossaudiodev, socket, ssl, and
https://hg.python.org/cpython/rev/17c77938c4e2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23001>
_______________________________________

From report at bugs.python.org  Fri Mar 20 08:06:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 07:06:26 +0000
Subject: [issue23001] Accept mutable bytes-like objects
In-Reply-To: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za>
Message-ID: <1426835186.1.0.588783142218.issue23001@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23001>
_______________________________________

From report at bugs.python.org  Fri Mar 20 08:15:14 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 20 Mar 2015 07:15:14 +0000
Subject: [issue23712] Experiment: Assume that exact unicode hashes are perfect
 discriminators
In-Reply-To: <1426795062.72.0.102774381262.issue23712@psf.upfronthosting.co.za>
Message-ID: <1426835714.06.0.607939708311.issue23712@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

The problem is, even if the chance is excessively small, it's not zero. Meaning, someone's data set somewhere will break somehow. And with hash randomisation, it'll mean that the problem spotted in some life system will be entirely unreproducible without knowing the exact hash seed value that triggered it (i.e. not at all in a debug setup, definitely not in a test suite).

Unequal keys accidentally comparing equal in a dict is something that wouldn't necessarily crash loudly. It may just lead to very subtly incorrect results, e.g. one lost item in an intermediate step of a process, and half a cent up or down in the final result.

Don't get me wrong, I think this is a very interesting idea and worth exploring. But I'd be very reluctant to introduce it into the core language general purpose data types.

As for Python implementation dicts, the keys in there will normally be interned, so the lookup will not compare the strings but only their pointers. Nothing to win on that front, really.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23712>
_______________________________________

From report at bugs.python.org  Fri Mar 20 08:22:12 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 20 Mar 2015 07:22:12 +0000
Subject: [issue23342] run() - unified high-level interface for subprocess
In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za>
Message-ID: <1426836132.36.0.726677201048.issue23342@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23342>
_______________________________________

From report at bugs.python.org  Fri Mar 20 08:22:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 07:22:42 +0000
Subject: [issue22826] Support context management protocol in bkfile
In-Reply-To: <1415549255.85.0.105011780634.issue22826@psf.upfronthosting.co.za>
Message-ID: <20150320072239.30724.77034@psf.io>


Roundup Robot added the comment:

New changeset ea8c3166d1c2 by Serhiy Storchaka in branch 'default':
Issue #22826: The result of open() in Tools/freeze/bkfile.py is now better
https://hg.python.org/cpython/rev/ea8c3166d1c2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22826>
_______________________________________

From report at bugs.python.org  Fri Mar 20 08:24:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 07:24:05 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426832310.9.0.20428345958.issue23700@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZR7TzCanA1MtwmccuuBAr-kU-jDDXghLovaFwPW+WKaw@mail.gmail.com>


STINNER Victor added the comment:

Maybe we need to keep explicitly a reference to self.file in the method
(file = self.file) to keep it alive in the frame?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 08:48:12 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 07:48:12 +0000
Subject: [issue12006] strptime should implement %G, %V and %u directives
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1426837692.3.0.175382942558.issue12006@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Addressed Berker's comments.

----------
Added file: http://bugs.python.org/file38587/issue12006_6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Fri Mar 20 08:49:10 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 07:49:10 +0000
Subject: [issue22826] Support context management protocol in bkfile
In-Reply-To: <1415549255.85.0.105011780634.issue22826@psf.upfronthosting.co.za>
Message-ID: <1426837750.24.0.81610758379.issue22826@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22826>
_______________________________________

From report at bugs.python.org  Fri Mar 20 08:53:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 07:53:36 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426838016.93.0.709465500448.issue23700@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

No, it doesn't help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 08:53:52 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Fri, 20 Mar 2015 07:53:52 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426838032.77.0.234656200851.issue23700@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

I think this is a consequence of PEP380 and its decision to finalize the subgenerator when the delegating generator is closed.
Consider this simple example without tempfile:

def yielder (fileobj):
    yield from fileobj

with open('some_test_file', 'w') as f:
    f.write('line one\nline two\nline three')

with open('some_test_file', 'r') as f:
    line = next(yielder(f))
    nline = next(f)

==>

Traceback (most recent call last):
  File "<pyshell#11>", line 3, in <module>
    nline = next(f)
ValueError: I/O operation on closed file.

I think test_csv does the file-closing operation on lines 626/627 when it creates the temporary csv.reader(fileobj).

    def test_read_dict_fieldnames_from_file(self):
        with TemporaryFile("w+") as fileobj:
            fileobj.write("f1,f2,f3\r\n1,2,abc\r\n")
            fileobj.seek(0)
            reader = csv.DictReader(fileobj,
                                    fieldnames=next(csv.reader(fileobj)))
            self.assertEqual(reader.fieldnames, ["f1", "f2", "f3"])
            self.assertEqual(next(reader), {"f1": '1', "f2": '2', "f3": 'abc'})

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 09:02:17 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Fri, 20 Mar 2015 08:02:17 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426838537.23.0.480182549148.issue23700@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

Actually, its scary that use of yield from can have such a subtle side-effect. Maybe PEP380 should have taken this more seriously?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 09:29:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 08:29:35 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426840175.05.0.313174214025.issue2211@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In 2.7 Morsel.set is declared as:

    def set(self, key, val, coded_val,
            LegalChars=_LegalChars,
            idmap=_idmap, translate=string.translate):

Undocumented parameters idmap and translate were removed without deprecation. idmap was removed in 14b65de9b798, translate was removed in 99027c2b3fd2 when their became unnecessary. Now LegalChars is unnecessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Fri Mar 20 09:40:33 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 08:40:33 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426840833.59.0.790525472586.issue23700@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ah yes, correct: when a generator using "yield from obj" is destroyed while yield from is not done, obj.close() is called if the method exists.

So "yield from file" *is* different than "for line in file: yield file" when we don't consume the whole generator.

A workaround is to create a wrapper class and returns it in the _TemporaryFileWrapper.__iter__() method:
---
class Iterator:
    def __init__(self, obj):
        self.obj = obj

    def __next__(self):
        if self.obj is None:
            raise StopIteration
        return next(self.obj)

    def __iter__(self):
        return self

    def close(self):
        self.obj = None

---

Or simply:
---
class Iterator:
    def __init__(self, obj):
        self.obj = obj

    def __next__(self):
        return next(self.obj)

    def __iter__(self):
        return self
---

This solution looks more complex than tempfile_iter_fix.patch.

@Serhiy: Maybe add a short comment to explain why yield from is not used and must be used. (By the way, the current comment contains "yields from" which is confusing :-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 09:42:54 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 08:42:54 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426840974.79.0.713972785691.issue2211@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Fri Mar 20 09:43:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 08:43:51 +0000
Subject: [issue23716] test_multiprocessing_spawn hangs on x86 Ubuntu Shared 3.x
In-Reply-To: <1426817697.21.0.499031040791.issue23716@psf.upfronthosting.co.za>
Message-ID: <1426841031.09.0.349127919946.issue23716@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh cool, it looks like the changeset 9882cc2efd36 already fixed this issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23716>
_______________________________________

From report at bugs.python.org  Fri Mar 20 09:56:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 08:56:27 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426840833.59.0.790525472586.issue23700@psf.upfronthosting.co.za>
Message-ID: <11327385.EzgNiOrTY1@raxxla>


Serhiy Storchaka added the comment:

> Ah yes, correct: when a generator using "yield from obj" is destroyed while
> yield from is not done, obj.close() is called if the method exists.

But why obj.close() is called? The reference to fileobj is live, it shouldn't 
be closed.

> This solution looks more complex than tempfile_iter_fix.patch.

Why you prefer more complex solution to simple solution?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 10:03:25 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 09:03:25 +0000
Subject: [issue23715] PEP 475: handle EINTR in the signal module
In-Reply-To: <1426814009.06.0.724045685729.issue23715@psf.upfronthosting.co.za>
Message-ID: <1426842205.89.0.170142960937.issue23715@psf.upfronthosting.co.za>


STINNER Victor added the comment:

signal_eintr.py: More complete patch, modify also signal.sigwaitinfo().

--

I don't think that other signal functions need to be modified to handle EINTR.

POSIX manual pages:
- "The pthread_sigmask() function shall not return an error code of [EINTR]."
- "The pthread_kill() function shall not return an error code of [EINTR]."

pause() fails with EINTR when it receives a signal, but signal.pause() doesn't raise InterruptedError in this case, it only returns None, because we expect a signal.

I tested: signal.sigwait([]) doesn't fail with EINTR with a signal is received. No need to modify this function.

On Linux, signal.set_wakeup_fd() doesn't fail with InterruptedError.

----------
Added file: http://bugs.python.org/file38588/signal_eintr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23715>
_______________________________________

From report at bugs.python.org  Fri Mar 20 10:04:13 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Fri, 20 Mar 2015 09:04:13 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426842253.68.0.250287373675.issue23700@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

@Serhiy

in this line of code:

reader = csv.DictReader(fileobj, fieldnames=next(csv.reader(fileobj)))

csv.reader(fileobj) returns the generator created by fileobj.__iter__, but no reference to it is kept so the object gets destroyed right afterwards. This closes the generator and because it uses yield from also the contained subgenerator, which is the file itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 10:06:22 2015
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Fri, 20 Mar 2015 09:06:22 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426842382.25.0.880001526293.issue23700@psf.upfronthosting.co.za>


Bohuslav "Slavek" Kabrda added the comment:

@wolma any idea why this only happens on Windows? I can't reproduce the CSV failing test on Linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 10:08:49 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Fri, 20 Mar 2015 09:08:49 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426842529.14.0.0787119628799.issue23700@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

@bkabrda
not sure, but it may have to do with when exactly the object gets garbage collected

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 10:09:25 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 09:09:25 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <1426842565.43.0.90937176009.issue23618@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I tested polling+getsockopt(SO_ERROR) with connect_test.c on Linux, it works:

haypo at smithers$ gcc -D TEST_TWO=1 connect_test.c -o connect_test
haypo at smithers$ ./connect_test 
Will try to connect to 127.0.0.1 on port 80
(connect has been interrupted and now completed successfully)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Fri Mar 20 10:12:06 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 09:12:06 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za>
Message-ID: <1426842726.56.0.765202516386.issue22831@psf.upfronthosting.co.za>


STINNER Victor added the comment:

fd_leaks.diff is impossible to review, even Rietveld gave up, it's too big :-p

Could you please your patch into smaller patches? Split by directory for example.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22831>
_______________________________________

From report at bugs.python.org  Fri Mar 20 10:14:25 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 09:14:25 +0000
Subject: [issue23681] Have -b warn when directly comparing ints and bytes
In-Reply-To: <1426525530.11.0.0814957947674.issue23681@psf.upfronthosting.co.za>
Message-ID: <1426842865.62.0.396015367793.issue23681@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I didn't understand the issue.

$ python2
>>> b'A'[0] == 65
False

$ python3
Python 3.4.1 (default, Nov  3 2014, 14:38:10) 
>>> b'A'[0] == 65
True

Oh ok, now I get it: Python 2 and Python 3 behaves differently when comparing a string of a single byte and an integer.

Ok to raise a warning when -b command line option is used.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23681>
_______________________________________

From report at bugs.python.org  Fri Mar 20 10:20:28 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Mar 2015 09:20:28 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za>
Message-ID: <1426843228.18.0.633332329498.issue22831@psf.upfronthosting.co.za>


Martin Panter added the comment:

Posting a version of Serhiy?s patch made with ?hg diff -p --ignore-all-space?. It is a bit shorter, and should not include all the re-indented lines, which may help reviewing.

----------
Added file: http://bugs.python.org/file38589/fd_leaks.ignore-all-space.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22831>
_______________________________________

From report at bugs.python.org  Fri Mar 20 10:24:35 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 09:24:35 +0000
Subject: [issue23001] Accept mutable bytes-like objects
In-Reply-To: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za>
Message-ID: <20150320092432.30042.63650@psf.io>


Roundup Robot added the comment:

New changeset 11548e1ac920 by Victor Stinner in branch 'default':
Issue #23001: Fix typo
https://hg.python.org/cpython/rev/11548e1ac920

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23001>
_______________________________________

From report at bugs.python.org  Fri Mar 20 10:39:49 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 09:39:49 +0000
Subject: [issue23001] Accept mutable bytes-like objects
In-Reply-To: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za>
Message-ID: <20150320093940.11914.61774@psf.io>


Roundup Robot added the comment:

New changeset d478a2a5738a by Victor Stinner in branch 'default':
Issue #23709, #23001: ossaudiodev now uses Py_ssize_t for sizes instead of int
https://hg.python.org/cpython/rev/d478a2a5738a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23001>
_______________________________________

From report at bugs.python.org  Fri Mar 20 10:39:49 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 09:39:49 +0000
Subject: [issue23709] Refactor ossaudiodev: use _Py_read and _Py_write with
 the Py_buffer
In-Reply-To: <1426772209.38.0.996436244503.issue23709@psf.upfronthosting.co.za>
Message-ID: <20150320093940.11914.37284@psf.io>


Roundup Robot added the comment:

New changeset d478a2a5738a by Victor Stinner in branch 'default':
Issue #23709, #23001: ossaudiodev now uses Py_ssize_t for sizes instead of int
https://hg.python.org/cpython/rev/d478a2a5738a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23709>
_______________________________________

From report at bugs.python.org  Fri Mar 20 10:40:21 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 09:40:21 +0000
Subject: [issue23709] Refactor ossaudiodev: use _Py_read and _Py_write with
 the Py_buffer
In-Reply-To: <1426772209.38.0.996436244503.issue23709@psf.upfronthosting.co.za>
Message-ID: <1426844421.11.0.202439582774.issue23709@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23709>
_______________________________________

From report at bugs.python.org  Fri Mar 20 10:41:57 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 09:41:57 +0000
Subject: [issue23671] string.Template doesn't work with the self keyword
 argument
In-Reply-To: <1426407694.34.0.298286807857.issue23671@psf.upfronthosting.co.za>
Message-ID: <1426844517.3.0.44897494847.issue23671@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses Paul's and Demian's comments.

Converting the format_string parameter to positional parameter can break third-party code, so this needs a deprecation period.

----------
Added file: http://bugs.python.org/file38590/string_formatting_self_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23671>
_______________________________________

From report at bugs.python.org  Fri Mar 20 10:52:34 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 09:52:34 +0000
Subject: [issue23696] zipimport: chain ImportError to OSError
In-Reply-To: <1426640296.98.0.079062899559.issue23696@psf.upfronthosting.co.za>
Message-ID: <20150320095231.114142.74174@psf.io>


Roundup Robot added the comment:

New changeset 597a87099713 by Victor Stinner in branch 'default':
Issue #23696: Chain ZipImportError to the OSError
https://hg.python.org/cpython/rev/597a87099713

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23696>
_______________________________________

From report at bugs.python.org  Fri Mar 20 10:55:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 09:55:54 +0000
Subject: [issue23001] Accept mutable bytes-like objects
In-Reply-To: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za>
Message-ID: <1426845354.82.0.676134618747.issue23001@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Victor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23001>
_______________________________________

From report at bugs.python.org  Fri Mar 20 10:58:49 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 09:58:49 +0000
Subject: [issue23696] zipimport: chain ImportError to OSError
In-Reply-To: <1426640296.98.0.079062899559.issue23696@psf.upfronthosting.co.za>
Message-ID: <1426845529.9.0.891445908577.issue23696@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23696>
_______________________________________

From report at bugs.python.org  Fri Mar 20 10:59:35 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 09:59:35 +0000
Subject: [issue23685] Fix usage of PyMODINIT_FUNC
In-Reply-To: <1426587233.23.0.965954561717.issue23685@psf.upfronthosting.co.za>
Message-ID: <1426845575.98.0.501109126228.issue23685@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> builtin_modules.patch looks complex. It can be simplified by using the Py_BUILD_CORE define.

In this case, it can be done in the issue #11410. I consider that the initial issue is fixed, so I close the issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23685>
_______________________________________

From report at bugs.python.org  Fri Mar 20 11:01:21 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 10:01:21 +0000
Subject: [issue23001] Accept mutable bytes-like objects
In-Reply-To: <1417875906.64.0.311564166909.issue23001@psf.upfronthosting.co.za>
Message-ID: <1426845681.91.0.626071770411.issue23001@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Thanks Victor.

You're welcome, I just worked recently on ossaudiodev for _Py_read/write functions functions. But I'm not able to run ossaudiodev neither :-( I hope that the test runs on some buildbots (FreeBSD?).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23001>
_______________________________________

From report at bugs.python.org  Fri Mar 20 11:09:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 10:09:08 +0000
Subject: [issue23681] Have -b warn when directly comparing ints and bytes
In-Reply-To: <1426525530.11.0.0814957947674.issue23681@psf.upfronthosting.co.za>
Message-ID: <1426846148.69.0.311840367914.issue23681@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

@Brett: Yes, the patch handles `42 == b'*'` as well.

@Victor: The problem in such code:

x = b'Array'
x[0] == b'A'


Added explicit tests for bytes on the right side of the comparison and replaced b'.'[0] to ord(b'.').

----------
Added file: http://bugs.python.org/file38591/bytes_to_int_compare_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23681>
_______________________________________

From report at bugs.python.org  Fri Mar 20 11:16:24 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 10:16:24 +0000
Subject: [issue23681] Have -b warn when directly comparing ints and bytes
In-Reply-To: <1426525530.11.0.0814957947674.issue23681@psf.upfronthosting.co.za>
Message-ID: <1426846584.17.0.944374682295.issue23681@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> This will help when someone writes something like `b'abcd'[2] == b'c'`

What if someone writes line[-1] == 0 and line is a Unicode string? Should we emit a warning?

I patched locally PyUnicode_RichCompare() to emit a warning. Hum, there are *many* warnings in argparse, http.client, and many other modules. I don't think that it's a good idea. It looks common to use a string for a sentinel (ex: state = "UNKNOWN") and then store an int (ex: state = 0). So comparison need to check the type (ex: isinstance(state, str) and state == "UNKNOWN") which is verbose and annoying.

So no, we should not emit a warning :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23681>
_______________________________________

From report at bugs.python.org  Fri Mar 20 11:19:27 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 10:19:27 +0000
Subject: [issue23708] PEP 475: Add _Py_read() and _Py_write() functions
In-Reply-To: <1426772010.62.0.268490898603.issue23708@psf.upfronthosting.co.za>
Message-ID: <1426846767.51.0.307031755035.issue23708@psf.upfronthosting.co.za>


STINNER Victor added the comment:

An assertion failed in _Py_read() while running test_signal on AMD64 Snow Leop 3.x:

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/2779/steps/test/logs/stdio


[321/393/1] test_signal
Assertion failed: (errno == EINTR && PyErr_Occurred()), function _Py_read, file Python/fileutils.c, line 1181.
Fatal Python error: Aborted

Current thread 0x00007fff71296cc0 (most recent call first):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/subprocess.py", line 1407 in _execute_child
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/subprocess.py", line 855 in __init__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_signal.py", line 126 in run_test
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_signal.py", line 180 in test_main
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/case.py", line 577 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/case.py", line 625 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 122 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 122 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/runner.py", line 176 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/support/__init__.py", line 1772 in _run_suite
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/support/__init__.py", line 1806 in run_unittest
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_signal.py", line 1123 in test_main
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 1284 in runtest_inner
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 967 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 1568 in main_in_temp_cwd
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 1593 in <module>
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/runpy.py", line 85 in _run_code
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/runpy.py", line 170 in _run_module_as_main

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23708>
_______________________________________

From report at bugs.python.org  Fri Mar 20 11:37:39 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 10:37:39 +0000
Subject: [issue23708] PEP 475: Add _Py_read() and _Py_write() functions
In-Reply-To: <1426772010.62.0.268490898603.issue23708@psf.upfronthosting.co.za>
Message-ID: <20150320103736.16940.45768@psf.io>


Roundup Robot added the comment:

New changeset 6dd201b6bb4f by Victor Stinner in branch 'default':
Issue #23708: Split assertion expression in two assertions in _Py_read() and
https://hg.python.org/cpython/rev/6dd201b6bb4f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23708>
_______________________________________

From report at bugs.python.org  Fri Mar 20 11:40:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 10:40:51 +0000
Subject: [issue23708] PEP 475: Add _Py_read() and _Py_write() functions
In-Reply-To: <1426772010.62.0.268490898603.issue23708@psf.upfronthosting.co.za>
Message-ID: <1426848051.29.0.511064827157.issue23708@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Same error on "x86 Tiger 3.x" buildbot:

http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/9381/steps/test/logs/stdio

[345/393] test_signal
Python/fileutils.c:1181: failed assertion `errno == EINTR && PyErr_Occurred()'
Fatal Python error: Aborted

Current thread 0xa000d000 (most recent call first):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/subprocess.py", line 1407 in _execute_child
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/subprocess.py", line 855 in __init__
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", line 126 in run_test
  ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23708>
_______________________________________

From report at bugs.python.org  Fri Mar 20 11:46:35 2015
From: report at bugs.python.org (Yann Sionneau)
Date: Fri, 20 Mar 2015 10:46:35 +0000
Subject: [issue23630] support multiple hosts in create_server/start_server
In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za>
Message-ID: <1426848395.23.0.382431761741.issue23630@psf.upfronthosting.co.za>


Yann Sionneau added the comment:

Please let me know if you need anything for this patch to be integrated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23630>
_______________________________________

From report at bugs.python.org  Fri Mar 20 12:02:40 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 11:02:40 +0000
Subject: [issue23708] PEP 475: Add _Py_read() and _Py_write() functions
In-Reply-To: <1426772010.62.0.268490898603.issue23708@psf.upfronthosting.co.za>
Message-ID: <20150320110235.4205.38655@psf.io>


Roundup Robot added the comment:

New changeset 07fd54208434 by Victor Stinner in branch 'default':
Issue #23708: Save/restore errno in _Py_read() and _Py_write()
https://hg.python.org/cpython/rev/07fd54208434

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23708>
_______________________________________

From report at bugs.python.org  Fri Mar 20 12:12:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 11:12:08 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>
Message-ID: <1426849928.91.0.59804791672.issue23648@psf.upfronthosting.co.za>


STINNER Victor added the comment:

pthread_* are false positive, they cannot fail with EINTR:

"""
Pthreads function return values
       Most pthreads functions return 0 on success, and an error number of failure.  Note that the pthreads functions do not set errno.  For each of the pthreads functions that can return an error, POSIX.1-2001 specifies that the function can never fail with the error EINTR.
"""

Example of pthread_create:
"""
The pthread_create() function shall not return an error code of [EINTR].
"""

pthread_atfork
pthread_attr_destroy
pthread_attr_getdetachstate
pthread_attr_getguardsize
pthread_attr_getinheritsched
pthread_attr_getschedparam
pthread_attr_getschedpolicy
pthread_attr_getscope
pthread_attr_getstack
pthread_attr_getstacksize
pthread_barrierattr_destroy
pthread_barrierattr_getpshared
pthread_barrier_destroy
pthread_barrier_wait
pthread_cancel
pthread_cleanup_pop
pthread_condattr_destroy
pthread_condattr_getclock
pthread_condattr_getpshared
pthread_cond_broadcast
pthread_cond_destroy
pthread_cond_init
pthread_cond_timedwait
pthread_create
pthread_detach
pthread_equal
pthread_getconcurrency
pthread_getschedparam
pthread_getspecific
pthread_join
pthread_key_create
pthread_key_delete
pthread_kill
pthread_mutexattr_destroy
pthread_mutexattr_getprioceiling
pthread_mutexattr_getprotocol
pthread_mutexattr_getpshared
pthread_mutexattr_getrobust
pthread_mutexattr_gettype
pthread_mutex_consistent
pthread_mutex_destroy
pthread_mutex_getprioceiling
pthread_mutex_lock
pthread_mutex_timedlock
pthread_once
pthread_rwlockattr_destroy
pthread_rwlockattr_getpshared
pthread_rwlock_destroy
pthread_rwlock_rdlock
pthread_rwlock_timedrdlock
pthread_rwlock_timedwrlock
pthread_rwlock_trywrlock
pthread_rwlock_unlock
pthreads
pthread_setcancelstate
pthread_setschedprio
pthread_sigmask
pthread_spin_destroy
pthread_spin_lock
pthread_spin_unlock
pthread_tryjoin_np

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Fri Mar 20 12:19:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 11:19:31 +0000
Subject: [issue23717] strptime() with year-weekday pair can produce invalid
 data
Message-ID: <1426850371.96.0.168304833853.issue23717@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

strptime() with year-weekday pair can produce invalid data.

>>> time.strptime('2015 0', '%Y %w')
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=1, tm_isdst=-1)
>>> time.strptime('2015 1', '%Y %w')
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=0, tm_yday=1, tm_isdst=-1)
>>> time.strptime('2015 2', '%Y %w')
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=1, tm_yday=1, tm_isdst=-1)
>>> time.strptime('2015 3', '%Y %w')
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=2, tm_yday=1, tm_isdst=-1)
>>> time.strptime('2015 4', '%Y %w')
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=-1)
>>> time.strptime('2015 5', '%Y %w')
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=4, tm_yday=1, tm_isdst=-1)
>>> time.strptime('2015 6', '%Y %w')
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=5, tm_yday=1, tm_isdst=-1)

You get Jan 1 with any weekday.

----------
components: Library (Lib)
messages: 238645
nosy: belopolsky, lemburg, serhiy.storchaka
priority: normal
severity: normal
status: open
title: strptime() with year-weekday pair can produce invalid data
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23717>
_______________________________________

From report at bugs.python.org  Fri Mar 20 12:20:09 2015
From: report at bugs.python.org (Alex Shkop)
Date: Fri, 20 Mar 2015 11:20:09 +0000
Subject: [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1426850409.62.0.331338938394.issue22832@psf.upfronthosting.co.za>


Alex Shkop added the comment:

Fixed default values for fcntl(), ioctl() and lockf()

----------
Added file: http://bugs.python.org/file38598/issue22832_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22832>
_______________________________________

From report at bugs.python.org  Fri Mar 20 12:24:27 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 11:24:27 +0000
Subject: [issue23708] PEP 475: Add _Py_read() and _Py_write() functions
In-Reply-To: <1426772010.62.0.268490898603.issue23708@psf.upfronthosting.co.za>
Message-ID: <1426850667.3.0.162673105135.issue23708@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> New changeset 07fd54208434 by Victor Stinner in branch 'default':
> Issue #23708: Save/restore errno in _Py_read() and _Py_write()

When I wrote _Py_read()/_Py_write(), I added assertions on errno to ensure that errno is not modified. I chose to use assertions instead of save/restore errno because on Linux errno is not modified. Since they *are* platforms where errno is modified, it's safer to always save/restore errno.

_Py_read()/_Py_write() *must* set set errno because some callers uses it. It's more convinient to use errno than having to get the errno attribute of the raised OSError exception.

test_signal pass again on "AMD64 Snow Leop 3.x" buildbot, I close the issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23708>
_______________________________________

From report at bugs.python.org  Fri Mar 20 12:30:32 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 11:30:32 +0000
Subject: [issue23718] strptime() can produce invalid date with negative year
 day
Message-ID: <1426851032.32.0.560407728917.issue23718@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

strptime() can produce invalid time with negative year day when parse year-week-weekday set. Such time is rejected by strftime(), so strptime/strftime roundtrip doesn't work.

>>> t = time.strptime('2015 0 0', '%Y %U %w')
>>> t
time.struct_time(tm_year=2014, tm_mon=12, tm_mday=28, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=-3, tm_isdst=-1)
>>> time.strftime('%Y %U %w', t)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: day of year out of range

----------
components: Library (Lib)
messages: 238648
nosy: belopolsky, lemburg, serhiy.storchaka
priority: normal
severity: normal
status: open
title: strptime() can produce invalid date with negative year day
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23718>
_______________________________________

From report at bugs.python.org  Fri Mar 20 12:32:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 11:32:00 +0000
Subject: [issue12006] strptime should implement %G, %V and %u directives
In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za>
Message-ID: <1426851120.76.0.207352137346.issue12006@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are other issues.

strptime with single %Y returns a date of the first day of the year. What should return single %G?

>>> time.strptime('2015', '%Y')
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=-1)
>>> time.strptime('2015', '%G')
time.struct_time(tm_year=1900, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=0, tm_yday=1, tm_isdst=-1)

See also issue23717 and issue23718.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12006>
_______________________________________

From report at bugs.python.org  Fri Mar 20 12:44:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 11:44:17 +0000
Subject: [issue23285] PEP 475 - EINTR handling
In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za>
Message-ID: <1426851857.68.0.425264702712.issue23285@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> For the record, it seems test_eintr sometimes left zombie processes in my machine where I run reference leak tests every night. I didn't investigate and just disabled the tests.
>
> (I'll add that that machine is hosted on an OpenVZ-based VPS, so perhaps there are issues with the old patched kernel and whatnot?)

On my Fedora 21 (on a physical PC, not virtualized), I ran "./python -m test -R 3:3: test_eintr" 3 times. After that, I didn't see any zombi Python process. If I cannot reproduce the issue, I cannot fix it. I bet that it's related to OpenVZ.

IMO this issue can be closed. It already has a long history. I prefer to open new issues. See the issue #23648 "PEP 475 meta issue" which lists all issues related to the PEP 475. I opened new issues for each module which didn't handle completly the PEP 475 yet.

By the way: great job Charles-Fran?ois! I like your changeset, it works well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23285>
_______________________________________

From report at bugs.python.org  Fri Mar 20 12:44:35 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 11:44:35 +0000
Subject: [issue23285] PEP 475 - EINTR handling
In-Reply-To: <1421795073.82.0.355583642769.issue23285@psf.upfronthosting.co.za>
Message-ID: <1426851875.83.0.334800092815.issue23285@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23285>
_______________________________________

From report at bugs.python.org  Fri Mar 20 13:02:41 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 12:02:41 +0000
Subject: [issue23715] PEP 475: handle EINTR in the signal module
In-Reply-To: <1426814009.06.0.724045685729.issue23715@psf.upfronthosting.co.za>
Message-ID: <20150320120156.63588.84011@psf.io>


Roundup Robot added the comment:

New changeset 33a6e2587aad by Victor Stinner in branch 'default':
Issue #23715: signal.sigwaitinfo() and signal.sigtimedwait() are now retried
https://hg.python.org/cpython/rev/33a6e2587aad

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23715>
_______________________________________

From report at bugs.python.org  Fri Mar 20 12:03:56 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 11:03:56 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1426822202.36.0.887116341318.issue22831@psf.upfronthosting.co.za>
Message-ID: <7715943.DexoWhrbnJ@raxxla>


Serhiy Storchaka added the comment:

The patch is synchronized with the tip and divided on smaller parts.

> There is a commented-out line in Tools/scripts/nm2def.py:

It is in a pair to commented out open() two lines above.

> Most of the open(..., 'r') usages can be changed to open(...)

Done.

> * It would be good to add context management protocol support to
> http.client.HTTPConnection.

In separate issue.

----------
Added file: http://bugs.python.org/file38592/fd_leaks_distutils.patch
Added file: http://bugs.python.org/file38593/fd_leaks_lib.patch
Added file: http://bugs.python.org/file38594/fd_leaks_tests1.patch
Added file: http://bugs.python.org/file38595/fd_leaks_tools2.patch
Added file: http://bugs.python.org/file38596/fd_leaks_tests2.patch
Added file: http://bugs.python.org/file38597/fd_leaks_tools1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22831>
_______________________________________
-------------- next part --------------
diff -r d478a2a5738a Lib/distutils/archive_util.py
--- a/Lib/distutils/archive_util.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/distutils/archive_util.py	Fri Mar 20 12:41:02 2015 +0200
@@ -164,13 +164,13 @@ def make_zipfile(base_name, base_dir, ve
                 zip = zipfile.ZipFile(zip_filename, "w",
                                       compression=zipfile.ZIP_STORED)
 
-            for dirpath, dirnames, filenames in os.walk(base_dir):
-                for name in filenames:
-                    path = os.path.normpath(os.path.join(dirpath, name))
-                    if os.path.isfile(path):
-                        zip.write(path, path)
-                        log.info("adding '%s'" % path)
-            zip.close()
+            with zip:
+                for dirpath, dirnames, filenames in os.walk(base_dir):
+                    for name in filenames:
+                        path = os.path.normpath(os.path.join(dirpath, name))
+                        if os.path.isfile(path):
+                            zip.write(path, path)
+                            log.info("adding '%s'" % path)
 
     return zip_filename
 
diff -r d478a2a5738a Lib/distutils/command/bdist_msi.py
--- a/Lib/distutils/command/bdist_msi.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/distutils/command/bdist_msi.py	Fri Mar 20 12:41:02 2015 +0200
@@ -390,18 +390,18 @@ class bdist_msi(Command):
         #     entries for each version as the above code does
         if self.pre_install_script:
             scriptfn = os.path.join(self.bdist_dir, "preinstall.bat")
-            f = open(scriptfn, "w")
-            # The batch file will be executed with [PYTHON], so that %1
-            # is the path to the Python interpreter; %0 will be the path
-            # of the batch file.
-            # rem ="""
-            # %1 %0
-            # exit
-            # """
-            # <actual script>
-            f.write('rem ="""\n%1 %0\nexit\n"""\n')
-            f.write(open(self.pre_install_script).read())
-            f.close()
+            with open(scriptfn, "w") as f:
+                # The batch file will be executed with [PYTHON], so that %1
+                # is the path to the Python interpreter; %0 will be the path
+                # of the batch file.
+                # rem ="""
+                # %1 %0
+                # exit
+                # """
+                # <actual script>
+                f.write('rem ="""\n%1 %0\nexit\n"""\n')
+                with open(self.pre_install_script) as fin:
+                    f.write(fin.read())
             add_data(self.db, "Binary",
                 [("PreInstall", msilib.Binary(scriptfn))
                 ])
diff -r d478a2a5738a Lib/distutils/command/config.py
--- a/Lib/distutils/command/config.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/distutils/command/config.py	Fri Mar 20 12:41:02 2015 +0200
@@ -106,15 +106,14 @@ class config(Command):
 
     def _gen_temp_sourcefile(self, body, headers, lang):
         filename = "_configtest" + LANG_EXT[lang]
-        file = open(filename, "w")
-        if headers:
-            for header in headers:
-                file.write("#include <%s>\n" % header)
-            file.write("\n")
-        file.write(body)
-        if body[-1] != "\n":
-            file.write("\n")
-        file.close()
+        with open(filename, "w") as file:
+            if headers:
+                for header in headers:
+                    file.write("#include <%s>\n" % header)
+                file.write("\n")
+            file.write(body)
+            if body[-1] != "\n":
+                file.write("\n")
         return filename
 
     def _preprocess(self, body, headers, include_dirs, lang):
@@ -203,17 +202,16 @@ class config(Command):
         if isinstance(pattern, str):
             pattern = re.compile(pattern)
 
-        file = open(out)
-        match = False
-        while True:
-            line = file.readline()
-            if line == '':
-                break
-            if pattern.search(line):
-                match = True
-                break
+        with open(out) as file:
+            match = False
+            while True:
+                line = file.readline()
+                if line == '':
+                    break
+                if pattern.search(line):
+                    match = True
+                    break
 
-        file.close()
         self._clean()
         return match
 
diff -r d478a2a5738a Lib/distutils/command/sdist.py
--- a/Lib/distutils/command/sdist.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/distutils/command/sdist.py	Fri Mar 20 12:41:02 2015 +0200
@@ -379,14 +379,13 @@ class sdist(Command):
         distribution.
         """
         log.info("reading manifest file '%s'", self.manifest)
-        manifest = open(self.manifest)
-        for line in manifest:
-            # ignore comments and blank lines
-            line = line.strip()
-            if line.startswith('#') or not line:
-                continue
-            self.filelist.append(line)
-        manifest.close()
+        with open(self.manifest) as manifest:
+            for line in manifest:
+                # ignore comments and blank lines
+                line = line.strip()
+                if line.startswith('#') or not line:
+                    continue
+                self.filelist.append(line)
 
     def make_release_tree(self, base_dir, files):
         """Create the directory tree that will become the source
diff -r d478a2a5738a Lib/distutils/util.py
--- a/Lib/distutils/util.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/distutils/util.py	Fri Mar 20 12:41:02 2015 +0200
@@ -383,35 +383,34 @@ def byte_compile (py_files,
             else:
                 script = open(script_name, "w")
 
-            script.write("""\
+            with script:
+                script.write("""\
 from distutils.util import byte_compile
 files = [
 """)
 
-            # XXX would be nice to write absolute filenames, just for
-            # safety's sake (script should be more robust in the face of
-            # chdir'ing before running it).  But this requires abspath'ing
-            # 'prefix' as well, and that breaks the hack in build_lib's
-            # 'byte_compile()' method that carefully tacks on a trailing
-            # slash (os.sep really) to make sure the prefix here is "just
-            # right".  This whole prefix business is rather delicate -- the
-            # problem is that it's really a directory, but I'm treating it
-            # as a dumb string, so trailing slashes and so forth matter.
+                # XXX would be nice to write absolute filenames, just for
+                # safety's sake (script should be more robust in the face of
+                # chdir'ing before running it).  But this requires abspath'ing
+                # 'prefix' as well, and that breaks the hack in build_lib's
+                # 'byte_compile()' method that carefully tacks on a trailing
+                # slash (os.sep really) to make sure the prefix here is "just
+                # right".  This whole prefix business is rather delicate -- the
+                # problem is that it's really a directory, but I'm treating it
+                # as a dumb string, so trailing slashes and so forth matter.
 
-            #py_files = map(os.path.abspath, py_files)
-            #if prefix:
-            #    prefix = os.path.abspath(prefix)
+                #py_files = map(os.path.abspath, py_files)
+                #if prefix:
+                #    prefix = os.path.abspath(prefix)
 
-            script.write(",\n".join(map(repr, py_files)) + "]\n")
-            script.write("""
+                script.write(",\n".join(map(repr, py_files)) + "]\n")
+                script.write("""
 byte_compile(files, optimize=%r, force=%r,
              prefix=%r, base_dir=%r,
              verbose=%r, dry_run=0,
              direct=1)
 """ % (optimize, force, prefix, base_dir, verbose))
 
-            script.close()
-
         cmd = [sys.executable, script_name]
         if optimize == 1:
             cmd.insert(1, "-O")
-------------- next part --------------
diff -r d478a2a5738a Lib/binhex.py
--- a/Lib/binhex.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/binhex.py	Fri Mar 20 12:41:40 2015 +0200
@@ -229,14 +229,13 @@ def binhex(inp, out):
     finfo = getfileinfo(inp)
     ofp = BinHex(finfo, out)
 
-    ifp = io.open(inp, 'rb')
-    # XXXX Do textfile translation on non-mac systems
-    while True:
-        d = ifp.read(128000)
-        if not d: break
-        ofp.write(d)
-    ofp.close_data()
-    ifp.close()
+    with io.open(inp, 'rb') as ifp:
+        # XXXX Do textfile translation on non-mac systems
+        while True:
+            d = ifp.read(128000)
+            if not d: break
+            ofp.write(d)
+        ofp.close_data()
 
     ifp = openrsrc(inp, 'rb')
     while True:
@@ -449,13 +448,12 @@ def hexbin(inp, out):
     if not out:
         out = ifp.FName
 
-    ofp = io.open(out, 'wb')
-    # XXXX Do translation on non-mac systems
-    while True:
-        d = ifp.read(128000)
-        if not d: break
-        ofp.write(d)
-    ofp.close()
+    with io.open(out, 'wb') as ofp:
+        # XXXX Do translation on non-mac systems
+        while True:
+            d = ifp.read(128000)
+            if not d: break
+            ofp.write(d)
     ifp.close_data()
 
     d = ifp.read_rsrc(128000)
diff -r d478a2a5738a Lib/cgitb.py
--- a/Lib/cgitb.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/cgitb.py	Fri Mar 20 12:41:40 2015 +0200
@@ -294,9 +294,8 @@ class Hook:
             (fd, path) = tempfile.mkstemp(suffix=suffix, dir=self.logdir)
 
             try:
-                file = os.fdopen(fd, 'w')
-                file.write(doc)
-                file.close()
+                with os.fdopen(fd, 'w') as file:
+                    file.write(doc)
                 msg = '%s contains the description of this error.' % path
             except:
                 msg = 'Tried to save traceback to %s, but failed.' % path
diff -r d478a2a5738a Lib/dbm/__init__.py
--- a/Lib/dbm/__init__.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/dbm/__init__.py	Fri Mar 20 12:41:40 2015 +0200
@@ -153,9 +153,9 @@ def whichdb(filename):
     except OSError:
         return None
 
-    # Read the start of the file -- the magic number
-    s16 = f.read(16)
-    f.close()
+    with f:
+        # Read the start of the file -- the magic number
+        s16 = f.read(16)
     s = s16[0:4]
 
     # Return "" if not at least 4 bytes
diff -r d478a2a5738a Lib/http/cookiejar.py
--- a/Lib/http/cookiejar.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/http/cookiejar.py	Fri Mar 20 12:41:40 2015 +0200
@@ -1999,7 +1999,6 @@ class MozillaCookieJar(FileCookieJar):
 
         magic = f.readline()
         if not self.magic_re.search(magic):
-            f.close()
             raise LoadError(
                 "%r does not look like a Netscape format cookies file" %
                 filename)
diff -r d478a2a5738a Lib/platform.py
--- a/Lib/platform.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/platform.py	Fri Mar 20 12:41:40 2015 +0200
@@ -163,40 +163,39 @@ def libc_ver(executable=sys.executable, 
         # here to work around problems with Cygwin not being
         # able to open symlinks for reading
         executable = os.path.realpath(executable)
-    f = open(executable, 'rb')
-    binary = f.read(chunksize)
-    pos = 0
-    while 1:
-        if b'libc' in binary or b'GLIBC' in binary:
-            m = _libc_search.search(binary, pos)
-        else:
-            m = None
-        if not m:
-            binary = f.read(chunksize)
-            if not binary:
-                break
-            pos = 0
-            continue
-        libcinit, glibc, glibcversion, so, threads, soversion = [
-            s.decode('latin1') if s is not None else s
-            for s in m.groups()]
-        if libcinit and not lib:
-            lib = 'libc'
-        elif glibc:
-            if lib != 'glibc':
-                lib = 'glibc'
-                version = glibcversion
-            elif glibcversion > version:
-                version = glibcversion
-        elif so:
-            if lib != 'glibc':
+    with open(executable, 'rb') as f:
+        binary = f.read(chunksize)
+        pos = 0
+        while 1:
+            if b'libc' in binary or b'GLIBC' in binary:
+                m = _libc_search.search(binary, pos)
+            else:
+                m = None
+            if not m:
+                binary = f.read(chunksize)
+                if not binary:
+                    break
+                pos = 0
+                continue
+            libcinit, glibc, glibcversion, so, threads, soversion = [
+                s.decode('latin1') if s is not None else s
+                for s in m.groups()]
+            if libcinit and not lib:
                 lib = 'libc'
-                if soversion and soversion > version:
-                    version = soversion
-                if threads and version[-len(threads):] != threads:
-                    version = version + threads
-        pos = m.end()
-    f.close()
+            elif glibc:
+                if lib != 'glibc':
+                    lib = 'glibc'
+                    version = glibcversion
+                elif glibcversion > version:
+                    version = glibcversion
+            elif so:
+                if lib != 'glibc':
+                    lib = 'libc'
+                    if soversion and soversion > version:
+                        version = soversion
+                    if threads and version[-len(threads):] != threads:
+                        version = version + threads
+            pos = m.end()
     return lib, version
 
 def _dist_try_harder(distname, version, id):
diff -r d478a2a5738a Lib/pydoc.py
--- a/Lib/pydoc.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/pydoc.py	Fri Mar 20 12:41:40 2015 +0200
@@ -1627,9 +1627,8 @@ def writedoc(thing, forceload=0):
     try:
         object, name = resolve(thing, forceload)
         page = html.page(describe(object), html.document(object, name))
-        file = open(name + '.html', 'w', encoding='utf-8')
-        file.write(page)
-        file.close()
+        with open(name + '.html', 'w', encoding='utf-8') as file:
+            file.write(page)
         print('wrote', name + '.html')
     except (ImportError, ErrorDuringImport) as value:
         print(value)
diff -r d478a2a5738a Lib/sre_constants.py
--- a/Lib/sre_constants.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/sre_constants.py	Fri Mar 20 12:41:40 2015 +0200
@@ -182,8 +182,8 @@ if __name__ == "__main__":
         items = sorted(d)
         for item in items:
             f.write("#define %s_%s %d\n" % (prefix, item, item))
-    f = open("sre_constants.h", "w")
-    f.write("""\
+    with open("sre_constants.h", "w") as f:
+        f.write("""\
 /*
  * Secret Labs' Regular Expression Engine
  *
@@ -199,25 +199,24 @@ if __name__ == "__main__":
 
 """)
 
-    f.write("#define SRE_MAGIC %d\n" % MAGIC)
+        f.write("#define SRE_MAGIC %d\n" % MAGIC)
 
-    dump(f, OPCODES, "SRE_OP")
-    dump(f, ATCODES, "SRE")
-    dump(f, CHCODES, "SRE")
+        dump(f, OPCODES, "SRE_OP")
+        dump(f, ATCODES, "SRE")
+        dump(f, CHCODES, "SRE")
 
-    f.write("#define SRE_FLAG_TEMPLATE %d\n" % SRE_FLAG_TEMPLATE)
-    f.write("#define SRE_FLAG_IGNORECASE %d\n" % SRE_FLAG_IGNORECASE)
-    f.write("#define SRE_FLAG_LOCALE %d\n" % SRE_FLAG_LOCALE)
-    f.write("#define SRE_FLAG_MULTILINE %d\n" % SRE_FLAG_MULTILINE)
-    f.write("#define SRE_FLAG_DOTALL %d\n" % SRE_FLAG_DOTALL)
-    f.write("#define SRE_FLAG_UNICODE %d\n" % SRE_FLAG_UNICODE)
-    f.write("#define SRE_FLAG_VERBOSE %d\n" % SRE_FLAG_VERBOSE)
-    f.write("#define SRE_FLAG_DEBUG %d\n" % SRE_FLAG_DEBUG)
-    f.write("#define SRE_FLAG_ASCII %d\n" % SRE_FLAG_ASCII)
+        f.write("#define SRE_FLAG_TEMPLATE %d\n" % SRE_FLAG_TEMPLATE)
+        f.write("#define SRE_FLAG_IGNORECASE %d\n" % SRE_FLAG_IGNORECASE)
+        f.write("#define SRE_FLAG_LOCALE %d\n" % SRE_FLAG_LOCALE)
+        f.write("#define SRE_FLAG_MULTILINE %d\n" % SRE_FLAG_MULTILINE)
+        f.write("#define SRE_FLAG_DOTALL %d\n" % SRE_FLAG_DOTALL)
+        f.write("#define SRE_FLAG_UNICODE %d\n" % SRE_FLAG_UNICODE)
+        f.write("#define SRE_FLAG_VERBOSE %d\n" % SRE_FLAG_VERBOSE)
+        f.write("#define SRE_FLAG_DEBUG %d\n" % SRE_FLAG_DEBUG)
+        f.write("#define SRE_FLAG_ASCII %d\n" % SRE_FLAG_ASCII)
 
-    f.write("#define SRE_INFO_PREFIX %d\n" % SRE_INFO_PREFIX)
-    f.write("#define SRE_INFO_LITERAL %d\n" % SRE_INFO_LITERAL)
-    f.write("#define SRE_INFO_CHARSET %d\n" % SRE_INFO_CHARSET)
+        f.write("#define SRE_INFO_PREFIX %d\n" % SRE_INFO_PREFIX)
+        f.write("#define SRE_INFO_LITERAL %d\n" % SRE_INFO_LITERAL)
+        f.write("#define SRE_INFO_CHARSET %d\n" % SRE_INFO_CHARSET)
 
-    f.close()
     print("done")
diff -r d478a2a5738a Lib/token.py
--- a/Lib/token.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/token.py	Fri Mar 20 12:41:40 2015 +0200
@@ -97,8 +97,8 @@ def _main():
     except OSError as err:
         sys.stdout.write("I/O error: %s\n" % str(err))
         sys.exit(1)
-    lines = fp.read().split("\n")
-    fp.close()
+    with fp:
+        lines = fp.read().split("\n")
     prog = re.compile(
         "#define[ \t][ \t]*([A-Z0-9][A-Z0-9_]*)[ \t][ \t]*([0-9][0-9]*)",
         re.IGNORECASE)
@@ -116,8 +116,8 @@ def _main():
     except OSError as err:
         sys.stderr.write("I/O error: %s\n" % str(err))
         sys.exit(2)
-    format = fp.read().split("\n")
-    fp.close()
+    with fp:
+        format = fp.read().split("\n")
     try:
         start = format.index("#--start constants--") + 1
         end = format.index("#--end constants--")
@@ -133,8 +133,8 @@ def _main():
     except OSError as err:
         sys.stderr.write("I/O error: %s\n" % str(err))
         sys.exit(4)
-    fp.write("\n".join(format))
-    fp.close()
+    with fp:
+        fp.write("\n".join(format))
 
 
 if __name__ == "__main__":
diff -r d478a2a5738a Lib/trace.py
--- a/Lib/trace.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/trace.py	Fri Mar 20 12:41:40 2015 +0200
@@ -232,8 +232,8 @@ class CoverageResults:
         if self.infile:
             # Try to merge existing counts file.
             try:
-                counts, calledfuncs, callers = \
-                        pickle.load(open(self.infile, 'rb'))
+                with open(self.infile, 'rb') as f:
+                    counts, calledfuncs, callers = pickle.load(f)
                 self.update(self.__class__(counts, calledfuncs, callers))
             except (OSError, EOFError, ValueError) as err:
                 print(("Skipping counts file %r: %s"
@@ -361,26 +361,26 @@ class CoverageResults:
 
         n_lines = 0
         n_hits = 0
-        for lineno, line in enumerate(lines, 1):
-            # do the blank/comment match to try to mark more lines
-            # (help the reader find stuff that hasn't been covered)
-            if lineno in lines_hit:
-                outfile.write("%5d: " % lines_hit[lineno])
-                n_hits += 1
-                n_lines += 1
-            elif rx_blank.match(line):
-                outfile.write("       ")
-            else:
-                # lines preceded by no marks weren't hit
-                # Highlight them if so indicated, unless the line contains
-                # #pragma: NO COVER
-                if lineno in lnotab and not PRAGMA_NOCOVER in line:
-                    outfile.write(">>>>>> ")
+        with outfile:
+            for lineno, line in enumerate(lines, 1):
+                # do the blank/comment match to try to mark more lines
+                # (help the reader find stuff that hasn't been covered)
+                if lineno in lines_hit:
+                    outfile.write("%5d: " % lines_hit[lineno])
+                    n_hits += 1
                     n_lines += 1
+                elif rx_blank.match(line):
+                    outfile.write("       ")
                 else:
-                    outfile.write("       ")
-            outfile.write(line.expandtabs(8))
-        outfile.close()
+                    # lines preceded by no marks weren't hit
+                    # Highlight them if so indicated, unless the line contains
+                    # #pragma: NO COVER
+                    if lineno in lnotab and not PRAGMA_NOCOVER in line:
+                        outfile.write(">>>>>> ")
+                        n_lines += 1
+                    else:
+                        outfile.write("       ")
+                outfile.write(line.expandtabs(8))
 
         return n_hits, n_lines
 
diff -r d478a2a5738a Lib/xmlrpc/client.py
--- a/Lib/xmlrpc/client.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/xmlrpc/client.py	Fri Mar 20 12:41:40 2015 +0200
@@ -1010,12 +1010,9 @@ def gzip_encode(data):
     if not gzip:
         raise NotImplementedError
     f = BytesIO()
-    gzf = gzip.GzipFile(mode="wb", fileobj=f, compresslevel=1)
-    gzf.write(data)
-    gzf.close()
-    encoded = f.getvalue()
-    f.close()
-    return encoded
+    with gzip.GzipFile(mode="wb", fileobj=f, compresslevel=1) as gzf:
+        gzf.write(data)
+    return f.getvalue()
 
 ##
 # Decode a string using the gzip content encoding such as specified by the
@@ -1036,17 +1033,14 @@ def gzip_decode(data, max_decode=2097152
     """
     if not gzip:
         raise NotImplementedError
-    f = BytesIO(data)
-    gzf = gzip.GzipFile(mode="rb", fileobj=f)
-    try:
-        if max_decode < 0: # no limit
-            decoded = gzf.read()
-        else:
-            decoded = gzf.read(max_decode + 1)
-    except OSError:
-        raise ValueError("invalid data")
-    f.close()
-    gzf.close()
+    with gzip.GzipFile(mode="rb", fileobj=BytesIO(data)) as gzf:
+        try:
+            if max_decode < 0: # no limit
+                decoded = gzf.read()
+            else:
+                decoded = gzf.read(max_decode + 1)
+        except OSError:
+            raise ValueError("invalid data")
     if max_decode >= 0 and len(decoded) > max_decode:
         raise ValueError("max gzipped payload length exceeded")
     return decoded
-------------- next part --------------
diff -r d478a2a5738a Lib/test/test_dbm_dumb.py
--- a/Lib/test/test_dbm_dumb.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_dbm_dumb.py	Fri Mar 20 12:50:42 2015 +0200
@@ -2,6 +2,7 @@
    Original by Roger E. Masse
 """
 
+import contextlib
 import io
 import operator
 import os
@@ -31,12 +32,11 @@ class DumbDBMTestCase(unittest.TestCase)
              }
 
     def test_dumbdbm_creation(self):
-        f = dumbdbm.open(_fname, 'c')
-        self.assertEqual(list(f.keys()), [])
-        for key in self._dict:
-            f[key] = self._dict[key]
-        self.read_helper(f)
-        f.close()
+        with contextlib.closing(dumbdbm.open(_fname, 'c')) as f:
+            self.assertEqual(list(f.keys()), [])
+            for key in self._dict:
+                f[key] = self._dict[key]
+            self.read_helper(f)
 
     @unittest.skipUnless(hasattr(os, 'umask'), 'test needs os.umask()')
     @unittest.skipUnless(hasattr(os, 'chmod'), 'test needs os.chmod()')
@@ -69,63 +69,55 @@ class DumbDBMTestCase(unittest.TestCase)
 
     def test_dumbdbm_modification(self):
         self.init_db()
-        f = dumbdbm.open(_fname, 'w')
-        self._dict[b'g'] = f[b'g'] = b"indented"
-        self.read_helper(f)
-        f.close()
+        with contextlib.closing(dumbdbm.open(_fname, 'w')) as f:
+            self._dict[b'g'] = f[b'g'] = b"indented"
+            self.read_helper(f)
 
     def test_dumbdbm_read(self):
         self.init_db()
-        f = dumbdbm.open(_fname, 'r')
-        self.read_helper(f)
-        f.close()
+        with contextlib.closing(dumbdbm.open(_fname, 'r')) as f:
+            self.read_helper(f)
 
     def test_dumbdbm_keys(self):
         self.init_db()
-        f = dumbdbm.open(_fname)
-        keys = self.keys_helper(f)
-        f.close()
+        with contextlib.closing(dumbdbm.open(_fname)) as f:
+            keys = self.keys_helper(f)
 
     def test_write_contains(self):
-        f = dumbdbm.open(_fname)
-        f[b'1'] = b'hello'
-        self.assertIn(b'1', f)
-        f.close()
+        with contextlib.closing(dumbdbm.open(_fname)) as f:
+            f[b'1'] = b'hello'
+            self.assertIn(b'1', f)
 
     def test_write_write_read(self):
         # test for bug #482460
-        f = dumbdbm.open(_fname)
-        f[b'1'] = b'hello'
-        f[b'1'] = b'hello2'
-        f.close()
-        f = dumbdbm.open(_fname)
-        self.assertEqual(f[b'1'], b'hello2')
-        f.close()
+        with contextlib.closing(dumbdbm.open(_fname)) as f:
+            f[b'1'] = b'hello'
+            f[b'1'] = b'hello2'
+        with contextlib.closing(dumbdbm.open(_fname)) as f:
+            self.assertEqual(f[b'1'], b'hello2')
 
     def test_str_read(self):
         self.init_db()
-        f = dumbdbm.open(_fname, 'r')
-        self.assertEqual(f['\u00fc'], self._dict['\u00fc'.encode('utf-8')])
+        with contextlib.closing(dumbdbm.open(_fname, 'r')) as f:
+            self.assertEqual(f['\u00fc'], self._dict['\u00fc'.encode('utf-8')])
 
     def test_str_write_contains(self):
         self.init_db()
-        f = dumbdbm.open(_fname)
-        f['\u00fc'] = b'!'
-        f['1'] = 'a'
-        f.close()
-        f = dumbdbm.open(_fname, 'r')
-        self.assertIn('\u00fc', f)
-        self.assertEqual(f['\u00fc'.encode('utf-8')],
-                         self._dict['\u00fc'.encode('utf-8')])
-        self.assertEqual(f[b'1'], b'a')
+        with contextlib.closing(dumbdbm.open(_fname)) as f:
+            f['\u00fc'] = b'!'
+            f['1'] = 'a'
+        with contextlib.closing(dumbdbm.open(_fname, 'r')) as f:
+            self.assertIn('\u00fc', f)
+            self.assertEqual(f['\u00fc'.encode('utf-8')],
+                             self._dict['\u00fc'.encode('utf-8')])
+            self.assertEqual(f[b'1'], b'a')
 
     def test_line_endings(self):
         # test for bug #1172763: dumbdbm would die if the line endings
         # weren't what was expected.
-        f = dumbdbm.open(_fname)
-        f[b'1'] = b'hello'
-        f[b'2'] = b'hello2'
-        f.close()
+        with contextlib.closing(dumbdbm.open(_fname)) as f:
+            f[b'1'] = b'hello'
+            f[b'2'] = b'hello2'
 
         # Mangle the file by changing the line separator to Windows or Unix
         with io.open(_fname + '.dir', 'rb') as file:
@@ -148,10 +140,9 @@ class DumbDBMTestCase(unittest.TestCase)
             self.assertEqual(self._dict[key], f[key])
 
     def init_db(self):
-        f = dumbdbm.open(_fname, 'w')
-        for k in self._dict:
-            f[k] = self._dict[k]
-        f.close()
+        with contextlib.closing(dumbdbm.open(_fname, 'w')) as f:
+            for k in self._dict:
+                f[k] = self._dict[k]
 
     def keys_helper(self, f):
         keys = sorted(f.keys())
@@ -165,25 +156,23 @@ class DumbDBMTestCase(unittest.TestCase)
         import random
         d = {}  # mirror the database
         for dummy in range(5):
-            f = dumbdbm.open(_fname)
-            for dummy in range(100):
-                k = random.choice('abcdefghijklm')
-                if random.random() < 0.2:
-                    if k in d:
-                        del d[k]
-                        del f[k]
-                else:
-                    v = random.choice((b'a', b'b', b'c')) * random.randrange(10000)
-                    d[k] = v
-                    f[k] = v
-                    self.assertEqual(f[k], v)
-            f.close()
+            with contextlib.closing(dumbdbm.open(_fname)) as f:
+                for dummy in range(100):
+                    k = random.choice('abcdefghijklm')
+                    if random.random() < 0.2:
+                        if k in d:
+                            del d[k]
+                            del f[k]
+                    else:
+                        v = random.choice((b'a', b'b', b'c')) * random.randrange(10000)
+                        d[k] = v
+                        f[k] = v
+                        self.assertEqual(f[k], v)
 
-            f = dumbdbm.open(_fname)
-            expected = sorted((k.encode("latin-1"), v) for k, v in d.items())
-            got = sorted(f.items())
-            self.assertEqual(expected, got)
-            f.close()
+            with contextlib.closing(dumbdbm.open(_fname)) as f:
+                expected = sorted((k.encode("latin-1"), v) for k, v in d.items())
+                got = sorted(f.items())
+                self.assertEqual(expected, got)
 
     def test_context_manager(self):
         with dumbdbm.open(_fname, 'c') as db:
diff -r d478a2a5738a Lib/test/test_mmap.py
--- a/Lib/test/test_mmap.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_mmap.py	Fri Mar 20 12:50:42 2015 +0200
@@ -268,13 +268,12 @@ class MmapTests(unittest.TestCase):
 
     def test_find_end(self):
         # test the new 'end' parameter works as expected
-        f = open(TESTFN, 'wb+')
-        data = b'one two ones'
-        n = len(data)
-        f.write(data)
-        f.flush()
-        m = mmap.mmap(f.fileno(), n)
-        f.close()
+        with open(TESTFN, 'wb+') as f:
+            data = b'one two ones'
+            n = len(data)
+            f.write(data)
+            f.flush()
+            m = mmap.mmap(f.fileno(), n)
 
         self.assertEqual(m.find(b'one'), 0)
         self.assertEqual(m.find(b'ones'), 8)
@@ -287,13 +286,12 @@ class MmapTests(unittest.TestCase):
 
     def test_rfind(self):
         # test the new 'end' parameter works as expected
-        f = open(TESTFN, 'wb+')
-        data = b'one two ones'
-        n = len(data)
-        f.write(data)
-        f.flush()
-        m = mmap.mmap(f.fileno(), n)
-        f.close()
+        with open(TESTFN, 'wb+') as f:
+            data = b'one two ones'
+            n = len(data)
+            f.write(data)
+            f.flush()
+            m = mmap.mmap(f.fileno(), n)
 
         self.assertEqual(m.rfind(b'one'), 8)
         self.assertEqual(m.rfind(b'one '), 0)
@@ -306,31 +304,24 @@ class MmapTests(unittest.TestCase):
 
     def test_double_close(self):
         # make sure a double close doesn't crash on Solaris (Bug# 665913)
-        f = open(TESTFN, 'wb+')
+        with open(TESTFN, 'wb+') as f:
+            f.write(2**16 * b'a') # Arbitrary character
 
-        f.write(2**16 * b'a') # Arbitrary character
-        f.close()
-
-        f = open(TESTFN, 'rb')
-        mf = mmap.mmap(f.fileno(), 2**16, access=mmap.ACCESS_READ)
-        mf.close()
-        mf.close()
-        f.close()
+        with open(TESTFN, 'rb') as f:
+            mf = mmap.mmap(f.fileno(), 2**16, access=mmap.ACCESS_READ)
+            mf.close()
+            mf.close()
 
     @unittest.skipUnless(hasattr(os, "stat"), "needs os.stat()")
     def test_entire_file(self):
         # test mapping of entire file by passing 0 for map length
-        f = open(TESTFN, "wb+")
+        with open(TESTFN, "wb+") as f:
+            f.write(2**16 * b'm') # Arbitrary character
 
-        f.write(2**16 * b'm') # Arbitrary character
-        f.close()
-
-        f = open(TESTFN, "rb+")
-        mf = mmap.mmap(f.fileno(), 0)
-        self.assertEqual(len(mf), 2**16, "Map size should equal file size.")
-        self.assertEqual(mf.read(2**16), 2**16 * b"m")
-        mf.close()
-        f.close()
+        with open(TESTFN, "rb+") as f, \
+             mmap.mmap(f.fileno(), 0) as mf:
+                self.assertEqual(len(mf), 2**16, "Map size should equal file size.")
+                self.assertEqual(mf.read(2**16), 2**16 * b"m")
 
     @unittest.skipUnless(hasattr(os, "stat"), "needs os.stat()")
     def test_length_0_offset(self):
@@ -358,16 +349,15 @@ class MmapTests(unittest.TestCase):
 
     def test_move(self):
         # make move works everywhere (64-bit format problem earlier)
-        f = open(TESTFN, 'wb+')
+        with open(TESTFN, 'wb+') as f:
 
-        f.write(b"ABCDEabcde") # Arbitrary character
-        f.flush()
+            f.write(b"ABCDEabcde") # Arbitrary character
+            f.flush()
 
-        mf = mmap.mmap(f.fileno(), 10)
-        mf.move(5, 0, 5)
-        self.assertEqual(mf[:], b"ABCDEABCDE", "Map move should have duplicated front 5")
-        mf.close()
-        f.close()
+            mf = mmap.mmap(f.fileno(), 10)
+            mf.move(5, 0, 5)
+            self.assertEqual(mf[:], b"ABCDEABCDE", "Map move should have duplicated front 5")
+            mf.close()
 
         # more excessive test
         data = b"0123456789"
@@ -565,10 +555,9 @@ class MmapTests(unittest.TestCase):
         mapsize = 10
         with open(TESTFN, "wb") as fp:
             fp.write(b"a"*mapsize)
-        f = open(TESTFN, "rb")
-        m = mmap.mmap(f.fileno(), mapsize, prot=mmap.PROT_READ)
-        self.assertRaises(TypeError, m.write, "foo")
-        f.close()
+        with open(TESTFN, "rb") as f:
+            m = mmap.mmap(f.fileno(), mapsize, prot=mmap.PROT_READ)
+            self.assertRaises(TypeError, m.write, "foo")
 
     def test_error(self):
         self.assertIs(mmap.error, OSError)
@@ -577,9 +566,8 @@ class MmapTests(unittest.TestCase):
         data = b"0123456789"
         with open(TESTFN, "wb") as fp:
             fp.write(b"x"*len(data))
-        f = open(TESTFN, "r+b")
-        m = mmap.mmap(f.fileno(), len(data))
-        f.close()
+        with open(TESTFN, "r+b") as f:
+            m = mmap.mmap(f.fileno(), len(data))
         # Test write_byte()
         for i in range(len(data)):
             self.assertEqual(m.tell(), i)
diff -r d478a2a5738a Lib/test/test_socket.py
--- a/Lib/test/test_socket.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_socket.py	Fri Mar 20 12:50:42 2015 +0200
@@ -686,10 +686,9 @@ class GeneralModuleTests(unittest.TestCa
         self.assertEqual(repr(s), expected)
 
     def test_weakref(self):
-        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-        p = proxy(s)
-        self.assertEqual(p.fileno(), s.fileno())
-        s.close()
+        with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
+            p = proxy(s)
+            self.assertEqual(p.fileno(), s.fileno())
         s = None
         try:
             p.fileno()
@@ -933,23 +932,20 @@ class GeneralModuleTests(unittest.TestCa
         # Testing default timeout
         # The default timeout should initially be None
         self.assertEqual(socket.getdefaulttimeout(), None)
-        s = socket.socket()
-        self.assertEqual(s.gettimeout(), None)
-        s.close()
+        with socket.socket() as s:
+            self.assertEqual(s.gettimeout(), None)
 
         # Set the default timeout to 10, and see if it propagates
         socket.setdefaulttimeout(10)
         self.assertEqual(socket.getdefaulttimeout(), 10)
-        s = socket.socket()
-        self.assertEqual(s.gettimeout(), 10)
-        s.close()
+        with socket.socket() as s:
+            self.assertEqual(s.gettimeout(), 10)
 
         # Reset the default timeout to None, and see if it propagates
         socket.setdefaulttimeout(None)
         self.assertEqual(socket.getdefaulttimeout(), None)
-        s = socket.socket()
-        self.assertEqual(s.gettimeout(), None)
-        s.close()
+        with socket.socket() as s:
+            self.assertEqual(s.gettimeout(), None)
 
         # Check that setting it to an invalid value raises ValueError
         self.assertRaises(ValueError, socket.setdefaulttimeout, -1)
@@ -1156,24 +1152,22 @@ class GeneralModuleTests(unittest.TestCa
 
     def testSendAfterClose(self):
         # testing send() after close() with timeout
-        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-        sock.settimeout(1)
-        sock.close()
+        with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
+            sock.settimeout(1)
         self.assertRaises(OSError, sock.send, b"spam")
 
     def testNewAttributes(self):
         # testing .family, .type and .protocol
 
-        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-        self.assertEqual(sock.family, socket.AF_INET)
-        if hasattr(socket, 'SOCK_CLOEXEC'):
-            self.assertIn(sock.type,
-                          (socket.SOCK_STREAM | socket.SOCK_CLOEXEC,
-                           socket.SOCK_STREAM))
-        else:
-            self.assertEqual(sock.type, socket.SOCK_STREAM)
-        self.assertEqual(sock.proto, 0)
-        sock.close()
+        with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
+            self.assertEqual(sock.family, socket.AF_INET)
+            if hasattr(socket, 'SOCK_CLOEXEC'):
+                self.assertIn(sock.type,
+                              (socket.SOCK_STREAM | socket.SOCK_CLOEXEC,
+                               socket.SOCK_STREAM))
+            else:
+                self.assertEqual(sock.type, socket.SOCK_STREAM)
+            self.assertEqual(sock.proto, 0)
 
     def test_getsockaddrarg(self):
         sock = socket.socket()
@@ -1400,10 +1394,9 @@ class GeneralModuleTests(unittest.TestCa
     def test_listen_backlog_overflow(self):
         # Issue 15989
         import _testcapi
-        srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-        srv.bind((HOST, 0))
-        self.assertRaises(OverflowError, srv.listen, _testcapi.INT_MAX + 1)
-        srv.close()
+        with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as srv:
+            srv.bind((HOST, 0))
+            self.assertRaises(OverflowError, srv.listen, _testcapi.INT_MAX + 1)
 
     @unittest.skipUnless(support.IPV6_ENABLED, 'IPv6 required for this test.')
     def test_flowinfo(self):
diff -r d478a2a5738a Lib/test/test_tarfile.py
--- a/Lib/test/test_tarfile.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_tarfile.py	Fri Mar 20 12:50:42 2015 +0200
@@ -127,49 +127,47 @@ class UstarReadTest(ReadTest, unittest.T
             data = fobj.read()
 
         tarinfo = self.tar.getmember("ustar/regtype")
-        fobj = self.tar.extractfile(tarinfo)
-
-        text = fobj.read()
-        fobj.seek(0)
-        self.assertEqual(0, fobj.tell(),
-                     "seek() to file's start failed")
-        fobj.seek(2048, 0)
-        self.assertEqual(2048, fobj.tell(),
-                     "seek() to absolute position failed")
-        fobj.seek(-1024, 1)
-        self.assertEqual(1024, fobj.tell(),
-                     "seek() to negative relative position failed")
-        fobj.seek(1024, 1)
-        self.assertEqual(2048, fobj.tell(),
-                     "seek() to positive relative position failed")
-        s = fobj.read(10)
-        self.assertEqual(s, data[2048:2058],
-                     "read() after seek failed")
-        fobj.seek(0, 2)
-        self.assertEqual(tarinfo.size, fobj.tell(),
-                     "seek() to file's end failed")
-        self.assertEqual(fobj.read(), b"",
-                     "read() at file's end did not return empty string")
-        fobj.seek(-tarinfo.size, 2)
-        self.assertEqual(0, fobj.tell(),
-                     "relative seek() to file's end failed")
-        fobj.seek(512)
-        s1 = fobj.readlines()
-        fobj.seek(512)
-        s2 = fobj.readlines()
-        self.assertEqual(s1, s2,
-                     "readlines() after seek failed")
-        fobj.seek(0)
-        self.assertEqual(len(fobj.readline()), fobj.tell(),
-                     "tell() after readline() failed")
-        fobj.seek(512)
-        self.assertEqual(len(fobj.readline()) + 512, fobj.tell(),
-                     "tell() after seek() and readline() failed")
-        fobj.seek(0)
-        line = fobj.readline()
-        self.assertEqual(fobj.read(), data[len(line):],
-                     "read() after readline() failed")
-        fobj.close()
+        with self.tar.extractfile(tarinfo) as fobj:
+            text = fobj.read()
+            fobj.seek(0)
+            self.assertEqual(0, fobj.tell(),
+                         "seek() to file's start failed")
+            fobj.seek(2048, 0)
+            self.assertEqual(2048, fobj.tell(),
+                         "seek() to absolute position failed")
+            fobj.seek(-1024, 1)
+            self.assertEqual(1024, fobj.tell(),
+                         "seek() to negative relative position failed")
+            fobj.seek(1024, 1)
+            self.assertEqual(2048, fobj.tell(),
+                         "seek() to positive relative position failed")
+            s = fobj.read(10)
+            self.assertEqual(s, data[2048:2058],
+                         "read() after seek failed")
+            fobj.seek(0, 2)
+            self.assertEqual(tarinfo.size, fobj.tell(),
+                         "seek() to file's end failed")
+            self.assertEqual(fobj.read(), b"",
+                         "read() at file's end did not return empty string")
+            fobj.seek(-tarinfo.size, 2)
+            self.assertEqual(0, fobj.tell(),
+                         "relative seek() to file's end failed")
+            fobj.seek(512)
+            s1 = fobj.readlines()
+            fobj.seek(512)
+            s2 = fobj.readlines()
+            self.assertEqual(s1, s2,
+                         "readlines() after seek failed")
+            fobj.seek(0)
+            self.assertEqual(len(fobj.readline()), fobj.tell(),
+                         "tell() after readline() failed")
+            fobj.seek(512)
+            self.assertEqual(len(fobj.readline()) + 512, fobj.tell(),
+                         "tell() after seek() and readline() failed")
+            fobj.seek(0)
+            line = fobj.readline()
+            self.assertEqual(fobj.read(), data[len(line):],
+                         "read() after readline() failed")
 
     def test_fileobj_text(self):
         with self.tar.extractfile("ustar/regtype") as fobj:
@@ -437,15 +435,14 @@ class MiscReadTestBase(CommonReadTest):
             fobj.seek(offset)
 
             # Test if the tarfile starts with the second member.
-            tar = tar.open(self.tarname, mode="r:", fileobj=fobj)
-            t = tar.next()
-            self.assertEqual(t.name, name)
-            # Read to the end of fileobj and test if seeking back to the
-            # beginning works.
-            tar.getmembers()
-            self.assertEqual(tar.extractfile(t).read(), data,
-                    "seek back did not work")
-            tar.close()
+            with tar.open(self.tarname, mode="r:", fileobj=fobj) as tar:
+                t = tar.next()
+                self.assertEqual(t.name, name)
+                # Read to the end of fileobj and test if seeking back to the
+                # beginning works.
+                tar.getmembers()
+                self.assertEqual(tar.extractfile(t).read(), data,
+                        "seek back did not work")
 
     def test_fail_comp(self):
         # For Gzip and Bz2 Tests: fail with a ReadError on an uncompressed file.
@@ -968,9 +965,8 @@ class WriteTestBase(TarTest):
 
     def test_fileobj_no_close(self):
         fobj = io.BytesIO()
-        tar = tarfile.open(fileobj=fobj, mode=self.mode)
-        tar.addfile(tarfile.TarInfo("foo"))
-        tar.close()
+        with tarfile.open(fileobj=fobj, mode=self.mode) as tar:
+            tar.addfile(tarfile.TarInfo("foo"))
         self.assertFalse(fobj.closed, "external fileobjs must never closed")
         # Issue #20238: Incomplete gzip output with mode="w:gz"
         data = fobj.getvalue()
@@ -1210,10 +1206,9 @@ class WriteTest(WriteTestBase, unittest.
             with open(source_file,'w') as f:
                 f.write('something\n')
             os.symlink(source_file, target_file)
-            tar = tarfile.open(temparchive,'w')
-            tar.add(source_file)
-            tar.add(target_file)
-            tar.close()
+            with tarfile.open(temparchive, 'w') as tar:
+                tar.add(source_file)
+                tar.add(target_file)
             # Let's extract it to the location which contains the symlink
             tar = tarfile.open(temparchive,'r')
             # this should not raise OSError: [Errno 17] File exists
@@ -1223,6 +1218,12 @@ class WriteTest(WriteTestBase, unittest.
                 self.fail("extractall failed with symlinked files")
             finally:
                 tar.close()
+            with tarfile.open(temparchive) as tar:
+                # this should not raise OSError: [Errno 17] File exists
+                try:
+                    tar.extractall(path=tempdir)
+                except OSError:
+                    self.fail("extractall failed with symlinked files")
         finally:
             support.unlink(temparchive)
             support.rmtree(tempdir)
diff -r d478a2a5738a Lib/test/test_uu.py
--- a/Lib/test/test_uu.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_uu.py	Fri Mar 20 12:50:42 2015 +0200
@@ -172,26 +172,21 @@ class UUFileTest(unittest.TestCase):
         fin = fout = None
         try:
             support.unlink(self.tmpin)
-            fin = open(self.tmpin, 'wb')
-            fin.write(plaintext)
-            fin.close()
+            with open(self.tmpin, 'wb') as fin:
+                fin.write(plaintext)
 
-            fin = open(self.tmpin, 'rb')
-            fout = open(self.tmpout, 'wb')
-            uu.encode(fin, fout, self.tmpin, mode=0o644)
-            fin.close()
-            fout.close()
+            with open(self.tmpin, 'rb') as fin, \
+                 open(self.tmpout, 'wb') as fout:
+                uu.encode(fin, fout, self.tmpin, mode=0o644)
 
-            fout = open(self.tmpout, 'rb')
-            s = fout.read()
-            fout.close()
+            with open(self.tmpout, 'rb') as fout:
+                s = fout.read()
             self.assertEqual(s, encodedtextwrapped(0o644, self.tmpin))
 
             # in_file and out_file as filenames
             uu.encode(self.tmpin, self.tmpout, self.tmpin, mode=0o644)
-            fout = open(self.tmpout, 'rb')
-            s = fout.read()
-            fout.close()
+            with open(self.tmpout, 'rb') as fout:
+                s = fout.read()
             self.assertEqual(s, encodedtextwrapped(0o644, self.tmpin))
 
         finally:
@@ -202,17 +197,14 @@ class UUFileTest(unittest.TestCase):
         f = None
         try:
             support.unlink(self.tmpin)
-            f = open(self.tmpin, 'wb')
-            f.write(encodedtextwrapped(0o644, self.tmpout))
-            f.close()
+            with open(self.tmpin, 'wb') as f:
+                f.write(encodedtextwrapped(0o644, self.tmpout))
 
-            f = open(self.tmpin, 'rb')
-            uu.decode(f)
-            f.close()
+            with open(self.tmpin, 'rb') as f:
+                uu.decode(f)
 
-            f = open(self.tmpout, 'rb')
-            s = f.read()
-            f.close()
+            with open(self.tmpout, 'rb') as f:
+                s = f.read()
             self.assertEqual(s, plaintext)
             # XXX is there an xp way to verify the mode?
         finally:
@@ -222,15 +214,13 @@ class UUFileTest(unittest.TestCase):
         f = None
         try:
             support.unlink(self.tmpin)
-            f = open(self.tmpin, 'wb')
-            f.write(encodedtextwrapped(0o644, self.tmpout))
-            f.close()
+            with open(self.tmpin, 'wb') as f:
+                f.write(encodedtextwrapped(0o644, self.tmpout))
 
             uu.decode(self.tmpin)
 
-            f = open(self.tmpout, 'rb')
-            s = f.read()
-            f.close()
+            with open(self.tmpout, 'rb') as f:
+                s = f.read()
             self.assertEqual(s, plaintext)
         finally:
             self._kill(f)
@@ -241,13 +231,11 @@ class UUFileTest(unittest.TestCase):
         try:
             f = io.BytesIO(encodedtextwrapped(0o644, self.tmpout))
 
-            f = open(self.tmpin, 'rb')
-            uu.decode(f)
-            f.close()
+            with open(self.tmpin, 'rb') as f:
+                uu.decode(f)
 
-            f = open(self.tmpin, 'rb')
-            self.assertRaises(uu.Error, uu.decode, f)
-            f.close()
+            with open(self.tmpin, 'rb') as f:
+                self.assertRaises(uu.Error, uu.decode, f)
         finally:
             self._kill(f)
 
diff -r d478a2a5738a Lib/test/test_zipfile64.py
--- a/Lib/test/test_zipfile64.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_zipfile64.py	Fri Mar 20 12:50:42 2015 +0200
@@ -32,42 +32,34 @@ class TestsWithSourceFile(unittest.TestC
         self.data = '\n'.join(line_gen).encode('ascii')
 
         # And write it to a file.
-        fp = open(TESTFN, "wb")
-        fp.write(self.data)
-        fp.close()
+        with open(TESTFN, "wb") as fp:
+            fp.write(self.data)
 
     def zipTest(self, f, compression):
         # Create the ZIP archive.
-        zipfp = zipfile.ZipFile(f, "w", compression)
-
-        # It will contain enough copies of self.data to reach about 6GB of
-        # raw data to store.
-        filecount = 6*1024**3 // len(self.data)
-
-        next_time = time.time() + _PRINT_WORKING_MSG_INTERVAL
-        for num in range(filecount):
-            zipfp.writestr("testfn%d" % num, self.data)
-            # Print still working message since this test can be really slow
-            if next_time <= time.time():
-                next_time = time.time() + _PRINT_WORKING_MSG_INTERVAL
-                print((
-                   '  zipTest still writing %d of %d, be patient...' %
-                   (num, filecount)), file=sys.__stdout__)
-                sys.__stdout__.flush()
-        zipfp.close()
+        with zipfile.ZipFile(f, "w", compression) as zipfp:
+            next_time = time.time() + _PRINT_WORKING_MSG_INTERVAL
+            for num in range(filecount):
+                zipfp.writestr("testfn%d" % num, self.data)
+                # Print still working message since this test can be really slow
+                if next_time <= time.time():
+                    next_time = time.time() + _PRINT_WORKING_MSG_INTERVAL
+                    print((
+                       '  zipTest still writing %d of %d, be patient...' %
+                       (num, filecount)), file=sys.__stdout__)
+                    sys.__stdout__.flush()
 
         # Read the ZIP archive
-        zipfp = zipfile.ZipFile(f, "r", compression)
-        for num in range(filecount):
-            self.assertEqual(zipfp.read("testfn%d" % num), self.data)
-            # Print still working message since this test can be really slow
-            if next_time <= time.time():
-                next_time = time.time() + _PRINT_WORKING_MSG_INTERVAL
-                print((
-                   '  zipTest still reading %d of %d, be patient...' %
-                   (num, filecount)), file=sys.__stdout__)
-                sys.__stdout__.flush()
-        zipfp.close()
+        with zipfile.ZipFile(f, "r", compression) as zipfp:
+            for num in range(filecount):
+                self.assertEqual(zipfp.read("testfn%d" % num), self.data)
+                # Print still working message since this test can be really slow
+                if next_time <= time.time():
+                    next_time = time.time() + _PRINT_WORKING_MSG_INTERVAL
+                    print((
+                       '  zipTest still reading %d of %d, be patient...' %
+                       (num, filecount)), file=sys.__stdout__)
+                    sys.__stdout__.flush()
 
     def testStored(self):
         # Try the temp file first.  If we do TESTFN2 first, then it hogs
@@ -92,20 +84,19 @@ class OtherTests(unittest.TestCase):
     def testMoreThan64kFiles(self):
         # This test checks that more than 64k files can be added to an archive,
         # and that the resulting archive can be read properly by ZipFile
-        zipf = zipfile.ZipFile(TESTFN, mode="w", allowZip64=True)
-        zipf.debug = 100
-        numfiles = (1 << 16) * 3//2
-        for i in range(numfiles):
-            zipf.writestr("foo%08d" % i, "%d" % (i**3 % 57))
-        self.assertEqual(len(zipf.namelist()), numfiles)
+        with zipfile.ZipFile(TESTFN, mode="w", allowZip64=True) as zipf:
+            zipf.debug = 100
+            numfiles = (1 << 16) * 3//2
+            for i in range(numfiles):
+                zipf.writestr("foo%08d" % i, "%d" % (i**3 % 57))
+            self.assertEqual(len(zipf.namelist()), numfiles)
         zipf.close()
 
-        zipf2 = zipfile.ZipFile(TESTFN, mode="r")
-        self.assertEqual(len(zipf2.namelist()), numfiles)
-        for i in range(numfiles):
-            content = zipf2.read("foo%08d" % i).decode('ascii')
-            self.assertEqual(content, "%d" % (i**3 % 57))
-        zipf2.close()
+        with zipfile.ZipFile(TESTFN, mode="r") as zipf2:
+            self.assertEqual(len(zipf2.namelist()), numfiles)
+            for i in range(numfiles):
+                content = zipf2.read("foo%08d" % i).decode('ascii')
+                self.assertEqual(content, "%d" % (i**3 % 57))
 
     def testMoreThan64kFilesAppend(self):
         zipf = zipfile.ZipFile(TESTFN, mode="w", allowZip64=False)
-------------- next part --------------
diff -r d478a2a5738a Tools/demo/markov.py
--- a/Tools/demo/markov.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/demo/markov.py	Fri Mar 20 12:55:59 2015 +0200
@@ -79,8 +79,8 @@ def test():
             else:
                 f = open(filename, 'r')
             if debug: print('processing', filename, '...')
-            text = f.read()
-            f.close()
+            with f:
+                text = f.read()
             paralist = text.split('\n\n')
             for para in paralist:
                 if debug > 1: print('feeding ...')
diff -r d478a2a5738a Tools/demo/rpython.py
--- a/Tools/demo/rpython.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/demo/rpython.py	Fri Mar 20 12:55:59 2015 +0200
@@ -22,17 +22,16 @@ def main():
         port = int(port[i+1:])
         host = host[:i]
     command = ' '.join(sys.argv[2:])
-    s = socket(AF_INET, SOCK_STREAM)
-    s.connect((host, port))
-    s.send(command.encode())
-    s.shutdown(SHUT_WR)
-    reply = b''
-    while True:
-        data = s.recv(BUFSIZE)
-        if not data:
-            break
-        reply += data
-    print(reply.decode(), end=' ')
-    s.close()
+    with socket(AF_INET, SOCK_STREAM) as s:
+        s.connect((host, port))
+        s.send(command.encode())
+        s.shutdown(SHUT_WR)
+        reply = b''
+        while True:
+            data = s.recv(BUFSIZE)
+            if not data:
+                break
+            reply += data
+        print(reply.decode(), end=' ')
 
 main()
diff -r d478a2a5738a Tools/demo/rpythond.py
--- a/Tools/demo/rpythond.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/demo/rpythond.py	Fri Mar 20 12:55:59 2015 +0200
@@ -26,16 +26,16 @@ def main():
     s.listen(1)
     while True:
         conn, (remotehost, remoteport) = s.accept()
-        print('connection from', remotehost, remoteport)
-        request = b''
-        while 1:
-            data = conn.recv(BUFSIZE)
-            if not data:
-                break
-            request += data
-        reply = execute(request.decode())
-        conn.send(reply.encode())
-        conn.close()
+        with conn:
+            print('connection from', remotehost, remoteport)
+            request = b''
+            while 1:
+                data = conn.recv(BUFSIZE)
+                if not data:
+                    break
+                request += data
+            reply = execute(request.decode())
+            conn.send(reply.encode())
 
 def execute(request):
     stdout = sys.stdout
diff -r d478a2a5738a Tools/freeze/checkextensions_win32.py
--- a/Tools/freeze/checkextensions_win32.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/freeze/checkextensions_win32.py	Fri Mar 20 12:55:59 2015 +0200
@@ -130,7 +130,8 @@ def parse_dsp(dsp):
     ret = []
     dsp_path, dsp_name = os.path.split(dsp)
     try:
-        lines = open(dsp, "r").readlines()
+        with open(dsp, "r") as fp:
+            lines = fp.readlines()
     except IOError as msg:
         sys.stderr.write("%s: %s\n" % (dsp, msg))
         return None
diff -r d478a2a5738a Tools/freeze/freeze.py
--- a/Tools/freeze/freeze.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/freeze/freeze.py	Fri Mar 20 12:55:59 2015 +0200
@@ -144,7 +144,8 @@ def main():
         # last option can not be "-i", so this ensures "pos+1" is in range!
         if sys.argv[pos] == '-i':
             try:
-                options = open(sys.argv[pos+1]).read().split()
+                with open(sys.argv[pos+1]) as infp:
+                    options = infp.read().split()
             except IOError as why:
                 usage("File name '%s' specified with the -i option "
                       "can not be read - %s" % (sys.argv[pos+1], why) )
diff -r d478a2a5738a Tools/i18n/msgfmt.py
--- a/Tools/i18n/msgfmt.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/i18n/msgfmt.py	Fri Mar 20 12:55:59 2015 +0200
@@ -109,7 +109,8 @@ def make(filename, outfile):
         outfile = os.path.splitext(infile)[0] + '.mo'
 
     try:
-        lines = open(infile, 'rb').readlines()
+        with open(infile, 'rb') as f:
+            lines = f.readlines()
     except IOError as msg:
         print(msg, file=sys.stderr)
         sys.exit(1)
@@ -199,7 +200,8 @@ def make(filename, outfile):
     output = generate()
 
     try:
-        open(outfile,"wb").write(output)
+        with open(outfile,"wb") as f:
+            f.write(output)
     except IOError as msg:
         print(msg, file=sys.stderr)
 
diff -r d478a2a5738a Tools/i18n/pygettext.py
--- a/Tools/i18n/pygettext.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/i18n/pygettext.py	Fri Mar 20 12:55:59 2015 +0200
@@ -595,9 +595,8 @@ def main():
     # initialize list of strings to exclude
     if options.excludefilename:
         try:
-            fp = open(options.excludefilename)
-            options.toexclude = fp.readlines()
-            fp.close()
+            with open(options.excludefilename) as fp:
+                options.toexclude = fp.readlines()
         except IOError:
             print(_(
                 "Can't read --exclude-file: %s") % options.excludefilename, file=sys.stderr)
diff -r d478a2a5738a Tools/pybench/pybench.py
--- a/Tools/pybench/pybench.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/pybench/pybench.py	Fri Mar 20 12:55:59 2015 +0200
@@ -893,10 +893,9 @@ python pybench.py -s p25.pybench -c p21.
 
         if compare_to:
             try:
-                f = open(compare_to,'rb')
-                bench = pickle.load(f)
-                bench.name = compare_to
-                f.close()
+                with open(compare_to,'rb') as f:
+                    bench = pickle.load(f)
+                    bench.name = compare_to
                 compare_to = bench
             except IOError as reason:
                 print('* Error opening/reading file %s: %s' % (
@@ -906,10 +905,9 @@ python pybench.py -s p25.pybench -c p21.
 
         if show_bench:
             try:
-                f = open(show_bench,'rb')
-                bench = pickle.load(f)
-                bench.name = show_bench
-                f.close()
+                with open(show_bench,'rb') as f:
+                    bench = pickle.load(f)
+                    bench.name = show_bench
                 bench.print_header()
                 if compare_to:
                     bench.print_comparison(compare_to,
@@ -960,10 +958,9 @@ python pybench.py -s p25.pybench -c p21.
 
         if reportfile:
             try:
-                f = open(reportfile,'wb')
-                bench.name = reportfile
-                pickle.dump(bench,f)
-                f.close()
+                with open(reportfile,'wb') as:
+                    bench.name = reportfile
+                    pickle.dump(bench,f)
             except IOError as reason:
                 print('* Error opening/writing reportfile %s: %s' % (
                     reportfile,
diff -r d478a2a5738a Tools/scripts/cleanfuture.py
--- a/Tools/scripts/cleanfuture.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/cleanfuture.py	Fri Mar 20 12:55:59 2015 +0200
@@ -96,11 +96,11 @@ def check(file):
         errprint("%r: I/O Error: %s" % (file, str(msg)))
         return
 
-    ff = FutureFinder(f, file)
-    changed = ff.run()
-    if changed:
-        ff.gettherest()
-    f.close()
+    with f:
+        ff = FutureFinder(f, file)
+        changed = ff.run()
+        if changed:
+            ff.gettherest()
     if changed:
         if verbose:
             print("changed.")
@@ -122,9 +122,8 @@ def check(file):
             os.rename(file, bak)
             if verbose:
                 print("renamed", file, "to", bak)
-            g = open(file, "w")
-            ff.write(g)
-            g.close()
+            with open(file, "w") as g:
+                ff.write(g)
             if verbose:
                 print("wrote new", file)
     else:
diff -r d478a2a5738a Tools/scripts/combinerefs.py
--- a/Tools/scripts/combinerefs.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/combinerefs.py	Fri Mar 20 12:55:59 2015 +0200
@@ -85,9 +85,7 @@ def read(fileiter, pat, whilematch):
         else:
             break
 
-def combine(fname):
-    f = open(fname)
-
+def combinefile(f):
     fi = iter(f)
 
     for line in read(fi, re.compile(r'^Remaining objects:$'), False):
@@ -121,8 +119,11 @@ def combine(fname):
             print('[%s->%s]' % (addr2rc[addr], rc), end=' ')
         print(guts, addr2guts[addr])
 
-    f.close()
     print("%d objects before, %d after" % (before, after))
 
+def combine(fname):
+    with open(fname) as f:
+        combinefile(f)
+
 if __name__ == '__main__':
     combine(sys.argv[1])
diff -r d478a2a5738a Tools/scripts/dutree.py
--- a/Tools/scripts/dutree.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/dutree.py	Fri Mar 20 12:55:59 2015 +0200
@@ -4,18 +4,18 @@
 import os, sys, errno
 
 def main():
-    p = os.popen('du ' + ' '.join(sys.argv[1:]), 'r')
     total, d = None, {}
-    for line in p.readlines():
-        i = 0
-        while line[i] in '0123456789': i = i+1
-        size = eval(line[:i])
-        while line[i] in ' \t': i = i+1
-        filename = line[i:-1]
-        comps = filename.split('/')
-        if comps[0] == '': comps[0] = '/'
-        if comps[len(comps)-1] == '': del comps[len(comps)-1]
-        total, d = store(size, comps, total, d)
+    with os.popen('du ' + ' '.join(sys.argv[1:])) as p:
+        for line in p:
+            i = 0
+            while line[i] in '0123456789': i = i+1
+            size = eval(line[:i])
+            while line[i] in ' \t': i = i+1
+            filename = line[i:-1]
+            comps = filename.split('/')
+            if comps[0] == '': comps[0] = '/'
+            if comps[len(comps)-1] == '': del comps[len(comps)-1]
+            total, d = store(size, comps, total, d)
     try:
         display(total, d)
     except IOError as e:
diff -r d478a2a5738a Tools/scripts/eptags.py
--- a/Tools/scripts/eptags.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/eptags.py	Fri Mar 20 12:55:59 2015 +0200
@@ -28,29 +28,30 @@ def treat_file(filename, outfp):
     except:
         sys.stderr.write('Cannot open %s\n'%filename)
         return
-    charno = 0
-    lineno = 0
-    tags = []
-    size = 0
-    while 1:
-        line = fp.readline()
-        if not line:
-            break
-        lineno = lineno + 1
-        m = matcher.search(line)
-        if m:
-            tag = m.group(0) + '\177%d,%d\n' % (lineno, charno)
-            tags.append(tag)
-            size = size + len(tag)
-        charno = charno + len(line)
+    with fp:
+        charno = 0
+        lineno = 0
+        tags = []
+        size = 0
+        while 1:
+            line = fp.readline()
+            if not line:
+                break
+            lineno = lineno + 1
+            m = matcher.search(line)
+            if m:
+                tag = m.group(0) + '\177%d,%d\n' % (lineno, charno)
+                tags.append(tag)
+                size = size + len(tag)
+            charno = charno + len(line)
     outfp.write('\f\n%s,%d\n' % (filename,size))
     for tag in tags:
         outfp.write(tag)
 
 def main():
-    outfp = open('TAGS', 'w')
-    for filename in sys.argv[1:]:
-        treat_file(filename, outfp)
+    with open('TAGS', 'w') as outfp:
+        for filename in sys.argv[1:]:
+            treat_file(filename, outfp)
 
 if __name__=="__main__":
     main()
diff -r d478a2a5738a Tools/scripts/finddiv.py
--- a/Tools/scripts/finddiv.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/finddiv.py	Fri Mar 20 12:55:59 2015 +0200
@@ -55,17 +55,17 @@ def process(filename, listnames):
     except IOError as msg:
         sys.stderr.write("Can't open: %s\n" % msg)
         return 1
-    g = tokenize.generate_tokens(fp.readline)
-    lastrow = None
-    for type, token, (row, col), end, line in g:
-        if token in ("/", "/="):
-            if listnames:
-                print(filename)
-                break
-            if row != lastrow:
-                lastrow = row
-                print("%s:%d:%s" % (filename, row, line), end=' ')
-    fp.close()
+    with fp:
+        g = tokenize.generate_tokens(fp.readline)
+        lastrow = None
+        for type, token, (row, col), end, line in g:
+            if token in ("/", "/="):
+                if listnames:
+                    print(filename)
+                    break
+                if row != lastrow:
+                    lastrow = row
+                    print("%s:%d:%s" % (filename, row, line), end=' ')
 
 def processdir(dir, listnames):
     try:
diff -r d478a2a5738a Tools/scripts/fixnotice.py
--- a/Tools/scripts/fixnotice.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/fixnotice.py	Fri Mar 20 12:55:59 2015 +0200
@@ -73,22 +73,19 @@ def main():
         elif opt == '--dry-run':
             DRYRUN = 1
         elif opt == '--oldnotice':
-            fp = open(arg)
-            OLD_NOTICE = fp.read()
-            fp.close()
+            with open(arg) as fp:
+                OLD_NOTICE = fp.read()
         elif opt == '--newnotice':
-            fp = open(arg)
-            NEW_NOTICE = fp.read()
-            fp.close()
+            with open(arg) as fp:
+                NEW_NOTICE = fp.read()
 
     for arg in args:
         process(arg)
 
 
 def process(file):
-    f = open(file)
-    data = f.read()
-    f.close()
+    with open(file) as f:
+        data = f.read()
     i = data.find(OLD_NOTICE)
     if i < 0:
         if VERBOSE:
@@ -102,9 +99,8 @@ def process(file):
     data = data[:i] + NEW_NOTICE + data[i+len(OLD_NOTICE):]
     new = file + ".new"
     backup = file + ".bak"
-    f = open(new, "w")
-    f.write(data)
-    f.close()
+    with open(new, "w") as f:
+        f.write(data)
     os.rename(file, backup)
     os.rename(new, file)
 
diff -r d478a2a5738a Tools/scripts/fixps.py
--- a/Tools/scripts/fixps.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/fixps.py	Fri Mar 20 12:55:59 2015 +0200
@@ -14,20 +14,18 @@ def main():
         except IOError as msg:
             print(filename, ': can\'t open :', msg)
             continue
-        line = f.readline()
-        if not re.match('^#! */usr/local/bin/python', line):
-            print(filename, ': not a /usr/local/bin/python script')
-            f.close()
-            continue
-        rest = f.read()
-        f.close()
+        with f:
+            line = f.readline()
+            if not re.match('^#! */usr/local/bin/python', line):
+                print(filename, ': not a /usr/local/bin/python script')
+                continue
+            rest = f.read()
         line = re.sub('/usr/local/bin/python',
                       '/usr/bin/env python', line)
         print(filename, ':', repr(line))
-        f = open(filename, "w")
-        f.write(line)
-        f.write(rest)
-        f.close()
+        with open(filename, "w") as f:
+            f.write(line)
+            f.write(rest)
 
 if __name__ == '__main__':
     main()
diff -r d478a2a5738a Tools/scripts/get-remote-certificate.py
--- a/Tools/scripts/get-remote-certificate.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/get-remote-certificate.py	Fri Mar 20 12:55:59 2015 +0200
@@ -29,9 +29,8 @@ def fetch_server_certificate (host, port
             return None
         else:
             tn = tempfile.mktemp()
-            fp = open(tn, "wb")
-            fp.write(m.group(1) + b"\n")
-            fp.close()
+            with open(tn, "wb") as fp:
+                fp.write(m.group(1) + b"\n")
             try:
                 tn2 = (outfile or tempfile.mktemp())
                 status, output = subproc(r'openssl x509 -in "%s" -out "%s"' %
@@ -39,9 +38,8 @@ def fetch_server_certificate (host, port
                 if status != 0:
                     raise RuntimeError('OpenSSL x509 failed with status %s and '
                                        'output: %r' % (status, output))
-                fp = open(tn2, 'rb')
-                data = fp.read()
-                fp.close()
+                with open(tn2, 'rb') as fp:
+                    data = fp.read()
                 os.unlink(tn2)
                 return data
             finally:
@@ -49,9 +47,8 @@ def fetch_server_certificate (host, port
 
     if sys.platform.startswith("win"):
         tfile = tempfile.mktemp()
-        fp = open(tfile, "w")
-        fp.write("quit\n")
-        fp.close()
+        with open(tfile, "w") as fp:
+            fp.write("quit\n")
         try:
             status, output = subproc(
                 'openssl s_client -connect "%s:%s" -showcerts < "%s"' %
diff -r d478a2a5738a Tools/scripts/h2py.py
--- a/Tools/scripts/h2py.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/h2py.py	Fri Mar 20 12:55:59 2015 +0200
@@ -69,23 +69,21 @@ def main():
             sys.stdout.write('# Generated by h2py from stdin\n')
             process(sys.stdin, sys.stdout)
         else:
-            fp = open(filename, 'r')
-            outfile = os.path.basename(filename)
-            i = outfile.rfind('.')
-            if i > 0: outfile = outfile[:i]
-            modname = outfile.upper()
-            outfile = modname + '.py'
-            outfp = open(outfile, 'w')
-            outfp.write('# Generated by h2py from %s\n' % filename)
-            filedict = {}
-            for dir in searchdirs:
-                if filename[:len(dir)] == dir:
-                    filedict[filename[len(dir)+1:]] = None  # no '/' trailing
-                    importable[filename[len(dir)+1:]] = modname
-                    break
-            process(fp, outfp)
-            outfp.close()
-            fp.close()
+            with open(filename) as fp:
+                outfile = os.path.basename(filename)
+                i = outfile.rfind('.')
+                if i > 0: outfile = outfile[:i]
+                modname = outfile.upper()
+                outfile = modname + '.py'
+                with open(outfile, 'w') as outfp:
+                    outfp.write('# Generated by h2py from %s\n' % filename)
+                    filedict = {}
+                    for dir in searchdirs:
+                        if filename[:len(dir)] == dir:
+                            filedict[filename[len(dir)+1:]] = None  # no '/' trailing
+                            importable[filename[len(dir)+1:]] = modname
+                            break
+                    process(fp, outfp)
 
 def pytify(body):
     # replace ignored patterns by spaces
@@ -161,9 +159,10 @@ def process(fp, outfp, env = {}):
                     except IOError:
                         pass
                 if inclfp:
-                    outfp.write(
-                            '\n# Included from %s\n' % filename)
-                    process(inclfp, outfp, env)
+                    with inclfp:
+                        outfp.write(
+                                '\n# Included from %s\n' % filename)
+                        process(inclfp, outfp, env)
                 else:
                     sys.stderr.write('Warning - could not find file %s\n' %
                                      filename)
diff -r d478a2a5738a Tools/scripts/ifdef.py
--- a/Tools/scripts/ifdef.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/ifdef.py	Fri Mar 20 12:55:59 2015 +0200
@@ -45,9 +45,8 @@ def main():
         if filename == '-':
             process(sys.stdin, sys.stdout)
         else:
-            f = open(filename, 'r')
-            process(f, sys.stdout)
-            f.close()
+            with open(filename) as f:
+                process(f, sys.stdout)
 
 def process(fpi, fpo):
     keywords = ('if', 'ifdef', 'ifndef', 'else', 'endif')
diff -r d478a2a5738a Tools/scripts/md5sum.py
--- a/Tools/scripts/md5sum.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/md5sum.py	Fri Mar 20 12:55:59 2015 +0200
@@ -47,10 +47,10 @@ def printsum(filename, out=sys.stdout):
     except IOError as msg:
         sys.stderr.write('%s: Can\'t open: %s\n' % (filename, msg))
         return 1
-    if fnfilter:
-        filename = fnfilter(filename)
-    sts = printsumfp(fp, filename, out)
-    fp.close()
+    with fp:
+        if fnfilter:
+            filename = fnfilter(filename)
+        sts = printsumfp(fp, filename, out)
     return sts
 
 def printsumfp(fp, filename, out=sys.stdout):
diff -r d478a2a5738a Tools/scripts/mkreal.py
--- a/Tools/scripts/mkreal.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/mkreal.py	Fri Mar 20 12:55:59 2015 +0200
@@ -18,14 +18,13 @@ def mkrealfile(name):
     st = os.stat(name) # Get the mode
     mode = S_IMODE(st[ST_MODE])
     linkto = os.readlink(name) # Make sure again it's a symlink
-    f_in = open(name, 'r') # This ensures it's a file
-    os.unlink(name)
-    f_out = open(name, 'w')
-    while 1:
-        buf = f_in.read(BUFSIZE)
-        if not buf: break
-        f_out.write(buf)
-    del f_out # Flush data to disk before changing mode
+    with open(name, 'rb') as f_in: # This ensures it's a file
+        os.unlink(name)
+        with open(name, 'wb') as f_out:
+            while 1:
+                buf = f_in.read(BUFSIZE)
+                if not buf: break
+                f_out.write(buf)
     os.chmod(name, mode)
 
 def mkrealdir(name):
diff -r d478a2a5738a Tools/scripts/nm2def.py
--- a/Tools/scripts/nm2def.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/nm2def.py	Fri Mar 20 12:55:59 2015 +0200
@@ -42,7 +42,8 @@ NM = 'nm -p -g %s'                      
 
 def symbols(lib=PYTHONLIB,types=('T','C','D')):
 
-    lines = os.popen(NM % lib).readlines()
+    with os.popen(NM % lib) as pipe:
+        lines = pipe.readlines()
     lines = [s.strip() for s in lines]
     symbols = {}
     for line in lines:
@@ -97,7 +98,7 @@ def main():
     exports = export_list(s)
     f = sys.stdout # open('PC/python_nt.def','w')
     f.write(DEF_TEMPLATE % (exports))
-    f.close()
+    # f.close()
 
 if __name__ == '__main__':
     main()
diff -r d478a2a5738a Tools/scripts/objgraph.py
--- a/Tools/scripts/objgraph.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/objgraph.py	Fri Mar 20 12:55:59 2015 +0200
@@ -180,7 +180,8 @@ def main():
         if filename == '-':
             readinput(sys.stdin)
         else:
-            readinput(open(filename, 'r'))
+            with open(filename) as f:
+                readinput(f)
     #
     warndups()
     #
diff -r d478a2a5738a Tools/scripts/parseentities.py
--- a/Tools/scripts/parseentities.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/parseentities.py	Fri Mar 20 12:55:59 2015 +0200
@@ -50,13 +50,15 @@ def writefile(f,defs):
 
 if __name__ == '__main__':
     if len(sys.argv) > 1:
-        infile = open(sys.argv[1])
+        with open(sys.argv[1]) as infile:
+            text = infile.read()
     else:
-        infile = sys.stdin
+        text = sys.stdin.read()
+
+    defs = parse(text)
+
     if len(sys.argv) > 2:
-        outfile = open(sys.argv[2],'w')
+        with open(sys.argv[2],'w') as outfile:
+            writefile(outfile, defs)
     else:
-        outfile = sys.stdout
-    text = infile.read()
-    defs = parse(text)
-    writefile(outfile,defs)
+        writefile(sys.stdout, defs)
diff -r d478a2a5738a Tools/scripts/pathfix.py
--- a/Tools/scripts/pathfix.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/pathfix.py	Fri Mar 20 12:55:59 2015 +0200
@@ -97,29 +97,27 @@ def fix(filename):
     except IOError as msg:
         err('%s: cannot open: %r\n' % (filename, msg))
         return 1
-    line = f.readline()
-    fixed = fixline(line)
-    if line == fixed:
-        rep(filename+': no change\n')
-        f.close()
-        return
-    head, tail = os.path.split(filename)
-    tempname = os.path.join(head, '@' + tail)
-    try:
-        g = open(tempname, 'wb')
-    except IOError as msg:
-        f.close()
-        err('%s: cannot create: %r\n' % (tempname, msg))
-        return 1
-    rep(filename + ': updating\n')
-    g.write(fixed)
-    BUFSIZE = 8*1024
-    while 1:
-        buf = f.read(BUFSIZE)
-        if not buf: break
-        g.write(buf)
-    g.close()
-    f.close()
+    with f:
+        line = f.readline()
+        fixed = fixline(line)
+        if line == fixed:
+            rep(filename+': no change\n')
+            return
+        head, tail = os.path.split(filename)
+        tempname = os.path.join(head, '@' + tail)
+        try:
+            g = open(tempname, 'wb')
+        except IOError as msg:
+            err('%s: cannot create: %r\n' % (tempname, msg))
+            return 1
+        with g:
+            rep(filename + ': updating\n')
+            g.write(fixed)
+            BUFSIZE = 8*1024
+            while 1:
+                buf = f.read(BUFSIZE)
+                if not buf: break
+                g.write(buf)
 
     # Finishing touch -- move files
 
diff -r d478a2a5738a Tools/scripts/pdeps.py
--- a/Tools/scripts/pdeps.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/pdeps.py	Fri Mar 20 12:55:59 2015 +0200
@@ -64,29 +64,28 @@ m_from = re.compile('^[ \t]*import[ \t]+
 # Collect data from one file
 #
 def process(filename, table):
-    fp = open(filename, 'r')
-    mod = os.path.basename(filename)
-    if mod[-3:] == '.py':
-        mod = mod[:-3]
-    table[mod] = list = []
-    while 1:
-        line = fp.readline()
-        if not line: break
-        while line[-1:] == '\\':
-            nextline = fp.readline()
-            if not nextline: break
-            line = line[:-1] + nextline
-        m_found = m_import.match(line) or m_from.match(line)
-        if m_found:
-            (a, b), (a1, b1) = m_found.regs[:2]
-        else: continue
-        words = line[a1:b1].split(',')
-        # print '#', line, words
-        for word in words:
-            word = word.strip()
-            if word not in list:
-                list.append(word)
-    fp.close()
+    with open(filename) as fp:
+        mod = os.path.basename(filename)
+        if mod[-3:] == '.py':
+            mod = mod[:-3]
+        table[mod] = list = []
+        while 1:
+            line = fp.readline()
+            if not line: break
+            while line[-1:] == '\\':
+                nextline = fp.readline()
+                if not nextline: break
+                line = line[:-1] + nextline
+            m_found = m_import.match(line) or m_from.match(line)
+            if m_found:
+                (a, b), (a1, b1) = m_found.regs[:2]
+            else: continue
+            words = line[a1:b1].split(',')
+            # print '#', line, words
+            for word in words:
+                word = word.strip()
+                if word not in list:
+                    list.append(word)
 
 
 # Compute closure (this is in fact totally general)
diff -r d478a2a5738a Tools/scripts/ptags.py
--- a/Tools/scripts/ptags.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/ptags.py	Fri Mar 20 12:55:59 2015 +0200
@@ -19,9 +19,9 @@ def main():
     for filename in args:
         treat_file(filename)
     if tags:
-        fp = open('tags', 'w')
-        tags.sort()
-        for s in tags: fp.write(s)
+        with open('tags', 'w') as fp:
+            tags.sort()
+            for s in tags: fp.write(s)
 
 
 expr = '^[ \t]*(def|class)[ \t]+([a-zA-Z0-9_]+)[ \t]*[:\(]'
@@ -33,21 +33,22 @@ def treat_file(filename):
     except:
         sys.stderr.write('Cannot open %s\n' % filename)
         return
-    base = os.path.basename(filename)
-    if base[-3:] == '.py':
-        base = base[:-3]
-    s = base + '\t' + filename + '\t' + '1\n'
-    tags.append(s)
-    while 1:
-        line = fp.readline()
-        if not line:
-            break
-        m = matcher.match(line)
-        if m:
-            content = m.group(0)
-            name = m.group(2)
-            s = name + '\t' + filename + '\t/^' + content + '/\n'
-            tags.append(s)
+    with fp:
+        base = os.path.basename(filename)
+        if base[-3:] == '.py':
+            base = base[:-3]
+        s = base + '\t' + filename + '\t' + '1\n'
+        tags.append(s)
+        while 1:
+            line = fp.readline()
+            if not line:
+                break
+            m = matcher.match(line)
+            if m:
+                content = m.group(0)
+                name = m.group(2)
+                s = name + '\t' + filename + '\t/^' + content + '/\n'
+                tags.append(s)
 
 if __name__ == '__main__':
     main()
diff -r d478a2a5738a Tools/scripts/rgrep.py
--- a/Tools/scripts/rgrep.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/rgrep.py	Fri Mar 20 12:55:59 2015 +0200
@@ -30,29 +30,30 @@ def main():
         f = open(filename)
     except IOError as msg:
         usage("can't open %r: %s" % (filename, msg), 1)
-    f.seek(0, 2)
-    pos = f.tell()
-    leftover = None
-    while pos > 0:
-        size = min(pos, bufsize)
-        pos = pos - size
-        f.seek(pos)
-        buffer = f.read(size)
-        lines = buffer.split("\n")
-        del buffer
-        if leftover is None:
-            if not lines[-1]:
-                del lines[-1]
-        else:
-            lines[-1] = lines[-1] + leftover
-        if pos > 0:
-            leftover = lines[0]
-            del lines[0]
-        else:
-            leftover = None
-        for line in reversed(lines):
-            if prog.search(line):
-                print(line)
+    with f:
+        f.seek(0, 2)
+        pos = f.tell()
+        leftover = None
+        while pos > 0:
+            size = min(pos, bufsize)
+            pos = pos - size
+            f.seek(pos)
+            buffer = f.read(size)
+            lines = buffer.split("\n")
+            del buffer
+            if leftover is None:
+                if not lines[-1]:
+                    del lines[-1]
+            else:
+                lines[-1] = lines[-1] + leftover
+            if pos > 0:
+                leftover = lines[0]
+                del lines[0]
+            else:
+                leftover = None
+            for line in reversed(lines):
+                if prog.search(line):
+                    print(line)
 
 
 def usage(msg, code=2):
diff -r d478a2a5738a Tools/scripts/svneol.py
--- a/Tools/scripts/svneol.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/svneol.py	Fri Mar 20 12:55:59 2015 +0200
@@ -39,7 +39,8 @@ import subprocess
 def propfiles(root, fn):
     default = os.path.join(root, ".svn", "props", fn + ".svn-work")
     try:
-        format = int(open(os.path.join(root, ".svn", "format")).read().strip())
+        with open(os.path.join(root, ".svn", "format")) as f:
+            format = int(f.read().strip())
     except IOError:
         return []
     if format in (8, 9):
@@ -60,27 +61,27 @@ def proplist(root, fn):
             # no properties file: not under version control,
             # or no properties set
             continue
-        while True:
-            # key-value pairs, of the form
-            # K <length>
-            # <keyname>NL
-            # V length
-            # <value>NL
-            # END
-            line = f.readline()
-            if line.startswith("END"):
-                break
-            assert line.startswith("K ")
-            L = int(line.split()[1])
-            key = f.read(L)
-            result.append(key)
-            f.readline()
-            line = f.readline()
-            assert line.startswith("V ")
-            L = int(line.split()[1])
-            value = f.read(L)
-            f.readline()
-        f.close()
+        with f:
+            while True:
+                # key-value pairs, of the form
+                # K <length>
+                # <keyname>NL
+                # V length
+                # <value>NL
+                # END
+                line = f.readline()
+                if line.startswith("END"):
+                    break
+                assert line.startswith("K ")
+                L = int(line.split()[1])
+                key = f.read(L)
+                result.append(key)
+                f.readline()
+                line = f.readline()
+                assert line.startswith("V ")
+                L = int(line.split()[1])
+                value = f.read(L)
+                f.readline()
     return result
 
 
diff -r d478a2a5738a Tools/unicode/gencjkcodecs.py
--- a/Tools/unicode/gencjkcodecs.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/unicode/gencjkcodecs.py	Fri Mar 20 12:55:59 2015 +0200
@@ -61,7 +61,8 @@ def gencodecs(prefix):
                                        encoding=enc.lower(),
                                        owner=loc)
             codecpath = os.path.join(prefix, enc + '.py')
-            open(codecpath, 'w').write(code)
+            with open(codecpath, 'w') as f:
+                f.write(code)
 
 if __name__ == '__main__':
     import sys
diff -r d478a2a5738a Tools/unicode/gencodec.py
--- a/Tools/unicode/gencodec.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/unicode/gencodec.py	Fri Mar 20 12:55:59 2015 +0200
@@ -72,9 +72,8 @@ def parsecodes(codes, len=len, range=ran
 
 def readmap(filename):
 
-    f = open(filename,'r')
-    lines = f.readlines()
-    f.close()
+    with open(filename) as f:
+        lines = f.readlines()
     enc2uni = {}
     identity = []
     unmapped = list(range(256))
@@ -359,18 +358,16 @@ encoding_table = codecs.charmap_build(de
 def pymap(name,map,pyfile,encodingname,comments=1):
 
     code = codegen(name,map,encodingname,comments)
-    f = open(pyfile,'w')
-    f.write(code)
-    f.close()
+    with open(pyfile,'w') as f:
+        f.write(code)
 
 def marshalmap(name,map,marshalfile):
 
     d = {}
     for e,(u,c) in map.items():
         d[e] = (u,c)
-    f = open(marshalfile,'wb')
-    marshal.dump(d,f)
-    f.close()
+    with open(marshalfile,'wb') as f:
+        marshal.dump(d,f)
 
 def convertdir(dir, dirprefix='', nameprefix='', comments=1):
 
@@ -411,8 +408,8 @@ def rewritepythondir(dir, dirprefix='', 
         print('converting %s to %s' % (mapname,
                                        dirprefix + codefile))
         try:
-            map = marshal.load(open(os.path.join(dir,mapname),
-                               'rb'))
+            with open(os.path.join(dir, mapname), 'rb') as f:
+                map = marshal.load(f)
             if not map:
                 print('* map is empty; skipping')
             else:
-------------- next part --------------
diff -r d478a2a5738a Lib/test/script_helper.py
--- a/Lib/test/script_helper.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/script_helper.py	Fri Mar 20 12:51:24 2015 +0200
@@ -152,31 +152,28 @@ def make_script(script_dir, script_basen
         script_filename += os.extsep + 'py'
     script_name = os.path.join(script_dir, script_filename)
     # The script should be encoded to UTF-8, the default string encoding
-    script_file = open(script_name, 'w', encoding='utf-8')
-    script_file.write(source)
-    script_file.close()
+    with open(script_name, 'w', encoding='utf-8') as script_file:
+        script_file.write(source)
     importlib.invalidate_caches()
     return script_name
 
 def make_zip_script(zip_dir, zip_basename, script_name, name_in_zip=None):
     zip_filename = zip_basename+os.extsep+'zip'
     zip_name = os.path.join(zip_dir, zip_filename)
-    zip_file = zipfile.ZipFile(zip_name, 'w')
-    if name_in_zip is None:
-        parts = script_name.split(os.sep)
-        if len(parts) >= 2 and parts[-2] == '__pycache__':
-            legacy_pyc = make_legacy_pyc(source_from_cache(script_name))
-            name_in_zip = os.path.basename(legacy_pyc)
-            script_name = legacy_pyc
-        else:
-            name_in_zip = os.path.basename(script_name)
-    zip_file.write(script_name, name_in_zip)
-    zip_file.close()
+    with zipfile.ZipFile(zip_name, 'w') as zip_file:
+        if name_in_zip is None:
+            parts = script_name.split(os.sep)
+            if len(parts) >= 2 and parts[-2] == '__pycache__':
+                legacy_pyc = make_legacy_pyc(source_from_cache(script_name))
+                name_in_zip = os.path.basename(legacy_pyc)
+                script_name = legacy_pyc
+            else:
+                name_in_zip = os.path.basename(script_name)
+        zip_file.write(script_name, name_in_zip)
     #if test.support.verbose:
-    #    zip_file = zipfile.ZipFile(zip_name, 'r')
-    #    print 'Contents of %r:' % zip_name
-    #    zip_file.printdir()
-    #    zip_file.close()
+    #    with zipfile.ZipFile(zip_name, 'r') as zip_file:
+    #        print 'Contents of %r:' % zip_name
+    #        zip_file.printdir()
     return zip_name, os.path.join(zip_name, name_in_zip)
 
 def make_pkg(pkg_dir, init_source=''):
@@ -199,17 +196,15 @@ def make_zip_pkg(zip_dir, zip_basename, 
     script_name_in_zip = os.path.join(pkg_names[-1], os.path.basename(script_name))
     zip_filename = zip_basename+os.extsep+'zip'
     zip_name = os.path.join(zip_dir, zip_filename)
-    zip_file = zipfile.ZipFile(zip_name, 'w')
-    for name in pkg_names:
-        init_name_in_zip = os.path.join(name, init_basename)
-        zip_file.write(init_name, init_name_in_zip)
-    zip_file.write(script_name, script_name_in_zip)
-    zip_file.close()
+    with zipfile.ZipFile(zip_name, 'w') as zip_file:
+        for name in pkg_names:
+            init_name_in_zip = os.path.join(name, init_basename)
+            zip_file.write(init_name, init_name_in_zip)
+        zip_file.write(script_name, script_name_in_zip)
     for name in unlink:
         os.unlink(name)
     #if test.support.verbose:
-    #    zip_file = zipfile.ZipFile(zip_name, 'r')
-    #    print 'Contents of %r:' % zip_name
-    #    zip_file.printdir()
-    #    zip_file.close()
+    #    with zipfile.ZipFile(zip_name, 'r') as zip_file:
+    #        print 'Contents of %r:' % zip_name
+    #        zip_file.printdir()
     return zip_name, os.path.join(zip_name, script_name_in_zip)
diff -r d478a2a5738a Lib/test/support/__init__.py
--- a/Lib/test/support/__init__.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/support/__init__.py	Fri Mar 20 12:51:24 2015 +0200
@@ -631,9 +631,8 @@ def find_unused_port(family=socket.AF_IN
     issue if/when we come across it.
     """
 
-    tempsock = socket.socket(family, socktype)
-    port = bind_port(tempsock)
-    tempsock.close()
+    with socket.socket(family, socktype) as tempsock:
+        port = bind_port(tempsock)
     del tempsock
     return port
 
@@ -1590,10 +1589,11 @@ class _MemoryWatchdog:
             sys.stderr.flush()
             return
 
-        watchdog_script = findfile("memory_watchdog.py")
-        self.mem_watchdog = subprocess.Popen([sys.executable, watchdog_script],
-                                             stdin=f, stderr=subprocess.DEVNULL)
-        f.close()
+        with f:
+            watchdog_script = findfile("memory_watchdog.py")
+            self.mem_watchdog = subprocess.Popen([sys.executable, watchdog_script],
+                                                 stdin=f,
+                                                 stderr=subprocess.DEVNULL)
         self.started = True
 
     def stop(self):
diff -r d478a2a5738a Lib/test/test_argparse.py
--- a/Lib/test/test_argparse.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_argparse.py	Fri Mar 20 12:51:24 2015 +0200
@@ -1379,9 +1379,8 @@ class TestArgumentsFromFile(TempDirMixin
             ('invalid', '@no-such-path\n'),
         ]
         for path, text in file_texts:
-            file = open(path, 'w')
-            file.write(text)
-            file.close()
+            with open(path, 'w') as file:
+                file.write(text)
 
     parser_signature = Sig(fromfile_prefix_chars='@')
     argument_signatures = [
@@ -1410,9 +1409,8 @@ class TestArgumentsFromFileConverter(Tem
             ('hello', 'hello world!\n'),
         ]
         for path, text in file_texts:
-            file = open(path, 'w')
-            file.write(text)
-            file.close()
+            with open(path, 'w') as file:
+                file.write(text)
 
     class FromFileConverterArgumentParser(ErrorRaisingArgumentParser):
 
@@ -1483,9 +1481,8 @@ class TestFileTypeR(TempDirMixin, Parser
     def setUp(self):
         super(TestFileTypeR, self).setUp()
         for file_name in ['foo', 'bar']:
-            file = open(os.path.join(self.temp_dir, file_name), 'w')
-            file.write(file_name)
-            file.close()
+            with open(os.path.join(self.temp_dir, file_name), 'w') as file:
+                file.write(file_name)
         self.create_readonly_file('readonly')
 
     argument_signatures = [
@@ -1524,9 +1521,8 @@ class TestFileTypeRB(TempDirMixin, Parse
     def setUp(self):
         super(TestFileTypeRB, self).setUp()
         for file_name in ['foo', 'bar']:
-            file = open(os.path.join(self.temp_dir, file_name), 'w')
-            file.write(file_name)
-            file.close()
+            with open(os.path.join(self.temp_dir, file_name), 'w') as file:
+                file.write(file_name)
 
     argument_signatures = [
         Sig('-x', type=argparse.FileType('rb')),
diff -r d478a2a5738a Lib/test/test_binhex.py
--- a/Lib/test/test_binhex.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_binhex.py	Fri Mar 20 12:51:24 2015 +0200
@@ -24,17 +24,15 @@ class BinHexTestCase(unittest.TestCase):
     DATA = b'Jack is my hero'
 
     def test_binhex(self):
-        f = open(self.fname1, 'wb')
-        f.write(self.DATA)
-        f.close()
+        with open(self.fname1, 'wb') as f:
+            f.write(self.DATA)
 
         binhex.binhex(self.fname1, self.fname2)
 
         binhex.hexbin(self.fname2, self.fname1)
 
-        f = open(self.fname1, 'rb')
-        finish = f.readline()
-        f.close()
+        with open(self.fname1, 'rb') as f:
+            finish = f.readline()
 
         self.assertEqual(self.DATA, finish)
 
diff -r d478a2a5738a Lib/test/test_bool.py
--- a/Lib/test/test_bool.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_bool.py	Fri Mar 20 12:51:24 2015 +0200
@@ -20,13 +20,11 @@ class BoolTest(unittest.TestCase):
 
     def test_print(self):
         try:
-            fo = open(support.TESTFN, "w")
-            print(False, True, file=fo)
-            fo.close()
-            fo = open(support.TESTFN, "r")
-            self.assertEqual(fo.read(), 'False True\n')
+            with open(support.TESTFN, "w") as fo:
+                print(False, True, file=fo)
+            with open(support.TESTFN, "r") as fi:
+                self.assertEqual(fi.read(), 'False True\n')
         finally:
-            fo.close()
             os.remove(support.TESTFN)
 
     def test_repr(self):
@@ -234,9 +232,8 @@ class BoolTest(unittest.TestCase):
 
     def test_fileclosed(self):
         try:
-            f = open(support.TESTFN, "w")
-            self.assertIs(f.closed, False)
-            f.close()
+            with open(support.TESTFN, "w") as f:
+                self.assertIs(f.closed, False)
             self.assertIs(f.closed, True)
         finally:
             os.remove(support.TESTFN)
diff -r d478a2a5738a Lib/test/test_codecs.py
--- a/Lib/test/test_codecs.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_codecs.py	Fri Mar 20 12:51:24 2015 +0200
@@ -1139,9 +1139,8 @@ class EscapeDecodeTest(unittest.TestCase
 class RecodingTest(unittest.TestCase):
     def test_recoding(self):
         f = io.BytesIO()
-        f2 = codecs.EncodedFile(f, "unicode_internal", "utf-8")
-        f2.write("a")
-        f2.close()
+        with codecs.EncodedFile(f, "unicode_internal", "utf-8") as f2:
+            f2.write("a")
         # Python used to crash on this at exit because of a refcount
         # bug in _codecsmodule.c
 
diff -r d478a2a5738a Lib/test/test_curses.py
--- a/Lib/test/test_curses.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_curses.py	Fri Mar 20 12:51:24 2015 +0200
@@ -184,11 +184,10 @@ class TestCurses(unittest.TestCase):
         curses.delay_output(1)
         curses.echo() ; curses.echo(1)
 
-        f = tempfile.TemporaryFile()
-        stdscr.putwin(f)
-        f.seek(0)
-        curses.getwin(f)
-        f.close()
+        with tempfile.TemporaryFile() as f:
+            stdscr.putwin(f)
+            f.seek(0)
+            curses.getwin(f)
 
         curses.halfdelay(1)
         curses.intrflush(1)
diff -r d478a2a5738a Lib/test/test_epoll.py
--- a/Lib/test/test_epoll.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_epoll.py	Fri Mar 20 12:51:24 2015 +0200
@@ -135,18 +135,17 @@ class TestEPoll(unittest.TestCase):
     def test_fromfd(self):
         server, client = self._connected_pair()
 
-        ep = select.epoll(2)
-        ep2 = select.epoll.fromfd(ep.fileno())
+        with select.epoll(2) as ep:
+            ep2 = select.epoll.fromfd(ep.fileno())
 
-        ep2.register(server.fileno(), select.EPOLLIN | select.EPOLLOUT)
-        ep2.register(client.fileno(), select.EPOLLIN | select.EPOLLOUT)
+            ep2.register(server.fileno(), select.EPOLLIN | select.EPOLLOUT)
+            ep2.register(client.fileno(), select.EPOLLIN | select.EPOLLOUT)
 
-        events = ep.poll(1, 4)
-        events2 = ep2.poll(0.9, 4)
-        self.assertEqual(len(events), 2)
-        self.assertEqual(len(events2), 2)
+            events = ep.poll(1, 4)
+            events2 = ep2.poll(0.9, 4)
+            self.assertEqual(len(events), 2)
+            self.assertEqual(len(events2), 2)
 
-        ep.close()
         try:
             ep2.poll(1, 4)
         except OSError as e:
diff -r d478a2a5738a Lib/test/test_float.py
--- a/Lib/test/test_float.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_float.py	Fri Mar 20 12:51:24 2015 +0200
@@ -603,15 +603,14 @@ class FormatTestCase(unittest.TestCase):
 
 class ReprTestCase(unittest.TestCase):
     def test_repr(self):
-        floats_file = open(os.path.join(os.path.split(__file__)[0],
-                           'floating_points.txt'))
-        for line in floats_file:
-            line = line.strip()
-            if not line or line.startswith('#'):
-                continue
-            v = eval(line)
-            self.assertEqual(v, eval(repr(v)))
-        floats_file.close()
+        with open(os.path.join(os.path.split(__file__)[0],
+                  'floating_points.txt')) as floats_file:
+            for line in floats_file:
+                line = line.strip()
+                if not line or line.startswith('#'):
+                    continue
+                v = eval(line)
+                self.assertEqual(v, eval(repr(v)))
 
     @unittest.skipUnless(getattr(sys, 'float_repr_style', '') == 'short',
                          "applies only when using short float repr style")
diff -r d478a2a5738a Lib/test/test_ioctl.py
--- a/Lib/test/test_ioctl.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_ioctl.py	Fri Mar 20 12:51:24 2015 +0200
@@ -11,9 +11,9 @@ try:
 except OSError:
     raise unittest.SkipTest("Unable to open /dev/tty")
 else:
-    # Skip if another process is in foreground
-    r = fcntl.ioctl(tty, termios.TIOCGPGRP, "    ")
-    tty.close()
+    with tty:
+        # Skip if another process is in foreground
+        r = fcntl.ioctl(tty, termios.TIOCGPGRP, "    ")
     rpgrp = struct.unpack("i", r)[0]
     if rpgrp not in (os.getpgrp(), os.getsid(0)):
         raise unittest.SkipTest("Neither the process group nor the session "
diff -r d478a2a5738a Lib/test/test_os.py
--- a/Lib/test/test_os.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_os.py	Fri Mar 20 12:51:24 2015 +0200
@@ -225,9 +225,8 @@ class StatAttributeTests(unittest.TestCa
     def setUp(self):
         os.mkdir(support.TESTFN)
         self.fname = os.path.join(support.TESTFN, "f1")
-        f = open(self.fname, 'wb')
-        f.write(b"ABC")
-        f.close()
+        with open(self.fname, 'wb') as f:
+            f.write(b"ABC")
 
     def tearDown(self):
         os.unlink(self.fname)
@@ -806,9 +805,8 @@ class WalkTests(unittest.TestCase):
         os.makedirs(t2_path)
 
         for path in tmp1_path, tmp2_path, tmp3_path, tmp4_path:
-            f = open(path, "w")
-            f.write("I'm " + path + " and proud of it.  Blame test_os.\n")
-            f.close()
+            with open(path, "w") as f:
+                f.write("I'm " + path + " and proud of it.  Blame test_os.\n")
 
         if support.can_symlink():
             os.symlink(os.path.abspath(t2_path), self.link_path)
@@ -1044,9 +1042,8 @@ class MakedirTests(unittest.TestCase):
     def test_exist_ok_existing_regular_file(self):
         base = support.TESTFN
         path = os.path.join(support.TESTFN, 'dir1')
-        f = open(path, 'w')
-        f.write('abc')
-        f.close()
+        with open(path, 'w') as f:
+            f.write('abc')
         self.assertRaises(OSError, os.makedirs, path)
         self.assertRaises(OSError, os.makedirs, path, exist_ok=False)
         self.assertRaises(OSError, os.makedirs, path, exist_ok=True)
diff -r d478a2a5738a Lib/test/test_pipes.py
--- a/Lib/test/test_pipes.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_pipes.py	Fri Mar 20 12:51:24 2015 +0200
@@ -20,9 +20,8 @@ class SimplePipeTests(unittest.TestCase)
     def testSimplePipe1(self):
         t = pipes.Template()
         t.append(s_command, pipes.STDIN_STDOUT)
-        f = t.open(TESTFN, 'w')
-        f.write('hello world #1')
-        f.close()
+        with t.open(TESTFN, 'w') as f:
+            f.write('hello world #1')
         with open(TESTFN) as f:
             self.assertEqual(f.read(), 'HELLO WORLD #1')
 
diff -r d478a2a5738a Lib/test/test_pkg.py
--- a/Lib/test/test_pkg.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_pkg.py	Fri Mar 20 12:51:24 2015 +0200
@@ -81,11 +81,10 @@ class TestPkg(unittest.TestCase):
             if contents is None:
                 os.mkdir(fullname)
             else:
-                f = open(fullname, "w")
-                f.write(contents)
-                if contents and contents[-1] != '\n':
-                    f.write('\n')
-                f.close()
+                with open(fullname, "w") as f:
+                    f.write(contents)
+                    if contents and contents[-1] != '\n':
+                        f.write('\n')
         self.root = root
         # package name is the name of the first item
         self.pkgname = descr[0][0]
diff -r d478a2a5738a Lib/test/test_platform.py
--- a/Lib/test/test_platform.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_platform.py	Fri Mar 20 12:51:24 2015 +0200
@@ -190,13 +190,12 @@ class PlatformTest(unittest.TestCase):
         if platform.uname().system == 'Darwin':
             # We're on a MacOSX system, check that
             # the right version information is returned
-            fd = os.popen('sw_vers', 'r')
-            real_ver = None
-            for ln in fd:
-                if ln.startswith('ProductVersion:'):
-                    real_ver = ln.strip().split()[-1]
-                    break
-            fd.close()
+            with os.popen('sw_vers') as fd:
+                real_ver = None
+                for ln in fd:
+                    if ln.startswith('ProductVersion:'):
+                        real_ver = ln.strip().split()[-1]
+                        break
             self.assertFalse(real_ver is None)
             result_list = res[0].split('.')
             expect_list = real_ver.split('.')
diff -r d478a2a5738a Lib/test/test_poll.py
--- a/Lib/test/test_poll.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_poll.py	Fri Mar 20 12:51:24 2015 +0200
@@ -86,13 +86,12 @@ class PollTests(unittest.TestCase):
         r = p.poll()
         self.assertEqual(r[0], (FD, select.POLLNVAL))
 
-        f = open(TESTFN, 'w')
-        fd = f.fileno()
-        p = select.poll()
-        p.register(f)
-        r = p.poll()
-        self.assertEqual(r[0][0], fd)
-        f.close()
+        with open(TESTFN, 'w') as f:
+            fd = f.fileno()
+            p = select.poll()
+            p.register(f)
+            r = p.poll()
+            self.assertEqual(r[0][0], fd)
         r = p.poll()
         self.assertEqual(r[0], (fd, select.POLLNVAL))
         os.unlink(TESTFN)
diff -r d478a2a5738a Lib/test/test_random.py
--- a/Lib/test/test_random.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_random.py	Fri Mar 20 12:51:24 2015 +0200
@@ -174,9 +174,8 @@ class TestBasicOps:
                  ("randv2_64.pck", 866),
                  ("randv3.pck", 343)]
         for file, value in files:
-            f = open(support.findfile(file),"rb")
-            r = pickle.load(f)
-            f.close()
+            with open(support.findfile(file),"rb") as f:
+                r = pickle.load(f)
             self.assertEqual(int(r.random()*1000), value)
 
     def test_bug_9025(self):
diff -r d478a2a5738a Lib/test/test_runpy.py
--- a/Lib/test/test_runpy.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_runpy.py	Fri Mar 20 12:51:24 2015 +0200
@@ -234,9 +234,8 @@ class RunModuleTestCase(unittest.TestCas
                 if verbose > 1: print("  Next level in:", sub_dir)
                 if verbose > 1: print("  Created:", pkg_fname)
         mod_fname = os.path.join(sub_dir, test_fname)
-        mod_file = open(mod_fname, "w")
-        mod_file.write(source)
-        mod_file.close()
+        with open(mod_fname, "w") as mod_file:
+            mod_file.write(source)
         if verbose > 1: print("  Created:", mod_fname)
         mod_name = (pkg_name+".")*depth + mod_base
         mod_spec = importlib.util.spec_from_file_location(mod_name,
diff -r d478a2a5738a Lib/test/test_select.py
--- a/Lib/test/test_select.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_select.py	Fri Mar 20 12:51:24 2015 +0200
@@ -46,24 +46,23 @@ class SelectTestCase(unittest.TestCase):
 
     def test_select(self):
         cmd = 'for i in 0 1 2 3 4 5 6 7 8 9; do echo testing...; sleep 1; done'
-        p = os.popen(cmd, 'r')
-        for tout in (0, 1, 2, 4, 8, 16) + (None,)*10:
-            if support.verbose:
-                print('timeout =', tout)
-            rfd, wfd, xfd = select.select([p], [], [], tout)
-            if (rfd, wfd, xfd) == ([], [], []):
-                continue
-            if (rfd, wfd, xfd) == ([p], [], []):
-                line = p.readline()
+        with os.popen(cmd) as p:
+            for tout in (0, 1, 2, 4, 8, 16) + (None,)*10:
                 if support.verbose:
-                    print(repr(line))
-                if not line:
+                    print('timeout =', tout)
+                rfd, wfd, xfd = select.select([p], [], [], tout)
+                if (rfd, wfd, xfd) == ([], [], []):
+                    continue
+                if (rfd, wfd, xfd) == ([p], [], []):
+                    line = p.readline()
                     if support.verbose:
-                        print('EOF')
-                    break
-                continue
-            self.fail('Unexpected return values from select():', rfd, wfd, xfd)
-        p.close()
+                        print(repr(line))
+                    if not line:
+                        if support.verbose:
+                            print('EOF')
+                        break
+                    continue
+                self.fail('Unexpected return values from select():', rfd, wfd, xfd)
 
     # Issue 16230: Crash on select resized list
     def test_select_mutated(self):
diff -r d478a2a5738a Lib/test/test_shelve.py
--- a/Lib/test/test_shelve.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_shelve.py	Fri Mar 20 12:51:24 2015 +0200
@@ -88,15 +88,13 @@ class TestCase(unittest.TestCase):
 
     def test_in_memory_shelf(self):
         d1 = byteskeydict()
-        s = shelve.Shelf(d1, protocol=0)
-        s['key1'] = (1,2,3,4)
-        self.assertEqual(s['key1'], (1,2,3,4))
-        s.close()
+        with shelve.Shelf(d1, protocol=0) as s:
+            s['key1'] = (1,2,3,4)
+            self.assertEqual(s['key1'], (1,2,3,4))
         d2 = byteskeydict()
-        s = shelve.Shelf(d2, protocol=1)
-        s['key1'] = (1,2,3,4)
-        self.assertEqual(s['key1'], (1,2,3,4))
-        s.close()
+        with shelve.Shelf(d2, protocol=1) as s:
+            s['key1'] = (1,2,3,4)
+            self.assertEqual(s['key1'], (1,2,3,4))
 
         self.assertEqual(len(d1), 1)
         self.assertEqual(len(d2), 1)
@@ -104,20 +102,18 @@ class TestCase(unittest.TestCase):
 
     def test_mutable_entry(self):
         d1 = byteskeydict()
-        s = shelve.Shelf(d1, protocol=2, writeback=False)
-        s['key1'] = [1,2,3,4]
-        self.assertEqual(s['key1'], [1,2,3,4])
-        s['key1'].append(5)
-        self.assertEqual(s['key1'], [1,2,3,4])
-        s.close()
+        with shelve.Shelf(d1, protocol=2, writeback=False) as s:
+            s['key1'] = [1,2,3,4]
+            self.assertEqual(s['key1'], [1,2,3,4])
+            s['key1'].append(5)
+            self.assertEqual(s['key1'], [1,2,3,4])
 
         d2 = byteskeydict()
-        s = shelve.Shelf(d2, protocol=2, writeback=True)
-        s['key1'] = [1,2,3,4]
-        self.assertEqual(s['key1'], [1,2,3,4])
-        s['key1'].append(5)
-        self.assertEqual(s['key1'], [1,2,3,4,5])
-        s.close()
+        with shelve.Shelf(d2, protocol=2, writeback=True) as s:
+            s['key1'] = [1,2,3,4]
+            self.assertEqual(s['key1'], [1,2,3,4])
+            s['key1'].append(5)
+            self.assertEqual(s['key1'], [1,2,3,4,5])
 
         self.assertEqual(len(d1), 1)
         self.assertEqual(len(d2), 1)
@@ -140,11 +136,10 @@ class TestCase(unittest.TestCase):
         d = {}
         key = 'key'
         encodedkey = key.encode('utf-8')
-        s = shelve.Shelf(d, writeback=True)
-        s[key] = [1]
-        p1 = d[encodedkey]  # Will give a KeyError if backing store not updated
-        s['key'].append(2)
-        s.close()
+        with shelve.Shelf(d, writeback=True) as s:
+            s[key] = [1]
+            p1 = d[encodedkey]  # Will give a KeyError if backing store not updated
+            s['key'].append(2)
         p2 = d[encodedkey]
         self.assertNotEqual(p1, p2)  # Write creates new object in store
 
diff -r d478a2a5738a Lib/test/test_site.py
--- a/Lib/test/test_site.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_site.py	Fri Mar 20 12:51:24 2015 +0200
@@ -102,10 +102,9 @@ class HelperFunctionsTests(unittest.Test
         pth_dir = os.path.abspath(pth_dir)
         pth_basename = pth_name + '.pth'
         pth_fn = os.path.join(pth_dir, pth_basename)
-        pth_file = open(pth_fn, 'w', encoding='utf-8')
-        self.addCleanup(lambda: os.remove(pth_fn))
-        pth_file.write(contents)
-        pth_file.close()
+        with open(pth_fn, 'w', encoding='utf-8') as pth_file:
+            self.addCleanup(lambda: os.remove(pth_fn))
+            pth_file.write(contents)
         return pth_dir, pth_basename
 
     def test_addpackage_import_bad_syntax(self):
diff -r d478a2a5738a Lib/test/test_socketserver.py
--- a/Lib/test/test_socketserver.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_socketserver.py	Fri Mar 20 12:51:24 2015 +0200
@@ -147,25 +147,23 @@ class SocketServerTest(unittest.TestCase
         if verbose: print("done")
 
     def stream_examine(self, proto, addr):
-        s = socket.socket(proto, socket.SOCK_STREAM)
-        s.connect(addr)
-        s.sendall(TEST_STR)
-        buf = data = receive(s, 100)
-        while data and b'\n' not in buf:
-            data = receive(s, 100)
-            buf += data
-        self.assertEqual(buf, TEST_STR)
-        s.close()
+        with socket.socket(proto, socket.SOCK_STREAM) as s:
+            s.connect(addr)
+            s.sendall(TEST_STR)
+            buf = data = receive(s, 100)
+            while data and b'\n' not in buf:
+                data = receive(s, 100)
+                buf += data
+            self.assertEqual(buf, TEST_STR)
 
     def dgram_examine(self, proto, addr):
-        s = socket.socket(proto, socket.SOCK_DGRAM)
-        s.sendto(TEST_STR, addr)
-        buf = data = receive(s, 100)
-        while data and b'\n' not in buf:
-            data = receive(s, 100)
-            buf += data
-        self.assertEqual(buf, TEST_STR)
-        s.close()
+        with socket.socket(proto, socket.SOCK_DGRAM) as s:
+            s.sendto(TEST_STR, addr)
+            buf = data = receive(s, 100)
+            while data and b'\n' not in buf:
+                data = receive(s, 100)
+                buf += data
+            self.assertEqual(buf, TEST_STR)
 
     def test_TCPServer(self):
         self.run_server(socketserver.TCPServer,
diff -r d478a2a5738a Lib/test/test_ssl.py
--- a/Lib/test/test_ssl.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_ssl.py	Fri Mar 20 12:51:24 2015 +0200
@@ -1355,11 +1355,10 @@ class NetworkedTests(unittest.TestCase):
                 s.close()
 
             # this should fail because we have no verification certs
-            s = ssl.wrap_socket(socket.socket(socket.AF_INET),
-                                cert_reqs=ssl.CERT_REQUIRED)
-            self.assertRaisesRegex(ssl.SSLError, "certificate verify failed",
-                                   s.connect, ("svn.python.org", 443))
-            s.close()
+            with ssl.wrap_socket(socket.socket(socket.AF_INET),
+                                 cert_reqs=ssl.CERT_REQUIRED) as s:
+                self.assertRaisesRegex(ssl.SSLError, "certificate verify failed",
+                                       s.connect, ("svn.python.org", 443))
 
             # this should succeed because we specify the root cert
             s = ssl.wrap_socket(socket.socket(socket.AF_INET),
diff -r d478a2a5738a Lib/test/test_tempfile.py
--- a/Lib/test/test_tempfile.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_tempfile.py	Fri Mar 20 12:51:24 2015 +0200
@@ -466,9 +466,8 @@ class TestGetTempDir(BaseTestCase):
         # sneaky: just instantiate a NamedTemporaryFile, which
         # defaults to writing into the directory returned by
         # gettempdir.
-        file = tempfile.NamedTemporaryFile()
-        file.write(b"blat")
-        file.close()
+        with tempfile.NamedTemporaryFile() as file:
+            file.write(b"blat")
 
     def test_same_thing(self):
         # gettempdir always returns the same object
@@ -730,9 +729,8 @@ class TestNamedTemporaryFile(BaseTestCas
         # A NamedTemporaryFile is deleted when closed
         dir = tempfile.mkdtemp()
         try:
-            f = tempfile.NamedTemporaryFile(dir=dir)
-            f.write(b'blat')
-            f.close()
+            with tempfile.NamedTemporaryFile(dir=dir) as f:
+                f.write(b'blat')
             self.assertFalse(os.path.exists(f.name),
                         "NamedTemporaryFile %s exists after close" % f.name)
         finally:
diff -r d478a2a5738a Lib/test/test_threading.py
--- a/Lib/test/test_threading.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_threading.py	Fri Mar 20 12:51:24 2015 +0200
@@ -746,13 +746,11 @@ class ThreadJoinOnShutdown(BaseTestCase)
             def random_io():
                 '''Loop for a while sleeping random tiny amounts and doing some I/O.'''
                 while True:
-                    in_f = open(os.__file__, 'rb')
-                    stuff = in_f.read(200)
-                    null_f = open(os.devnull, 'wb')
-                    null_f.write(stuff)
-                    time.sleep(random.random() / 1995)
-                    null_f.close()
-                    in_f.close()
+                    with open(os.__file__, 'rb') as in_f:
+                        stuff = in_f.read(200)
+                        with open(os.devnull, 'wb') as null_f:
+                            null_f.write(stuff)
+                            time.sleep(random.random() / 1995)
                     thread_has_run.add(threading.current_thread())
 
             def main():
diff -r d478a2a5738a Lib/test/test_urllib2.py
--- a/Lib/test/test_urllib2.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_urllib2.py	Fri Mar 20 12:51:24 2015 +0200
@@ -51,10 +51,8 @@ class TrivialTests(unittest.TestCase):
         else:
             file_url = "file://%s" % fname
 
-        f = urllib.request.urlopen(file_url)
-
-        f.read()
-        f.close()
+        with urllib.request.urlopen(file_url) as f:
+            f.read()
 
     def test_parse_http_list(self):
         tests = [
diff -r d478a2a5738a Lib/test/test_urllib2_localnet.py
--- a/Lib/test/test_urllib2_localnet.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_urllib2_localnet.py	Fri Mar 20 12:51:24 2015 +0200
@@ -361,10 +361,9 @@ class ProxyAuthTests(unittest.TestCase):
         self.proxy_digest_handler.add_password(self.REALM, self.URL,
                                                self.USER, self.PASSWD)
         self.digest_auth_handler.set_qop("auth")
-        result = self.opener.open(self.URL)
-        while result.read():
-            pass
-        result.close()
+        with self.opener.open(self.URL) as result:
+            while result.read():
+                pass
 
     def test_proxy_qop_auth_int_works_or_throws_urlerror(self):
         self.proxy_digest_handler.add_password(self.REALM, self.URL,
@@ -376,11 +375,11 @@ class ProxyAuthTests(unittest.TestCase):
             # It's okay if we don't support auth-int, but we certainly
             # shouldn't receive any kind of exception here other than
             # a URLError.
-            result = None
-        if result:
-            while result.read():
-                pass
-            result.close()
+            pass
+        else:
+            with result:
+                while result.read():
+                    pass
 
 
 def GetRequestHandler(responses):
@@ -597,14 +596,11 @@ class TestUrlopen(unittest.TestCase):
 
     def test_basic(self):
         handler = self.start_server()
-        open_url = urllib.request.urlopen("http://localhost:%s" % handler.port)
-        for attr in ("read", "close", "info", "geturl"):
-            self.assertTrue(hasattr(open_url, attr), "object returned from "
-                         "urlopen lacks the %s attribute" % attr)
-        try:
+        with urllib.request.urlopen("http://localhost:%s" % handler.port) as open_url:
+            for attr in ("read", "close", "info", "geturl"):
+                self.assertTrue(hasattr(open_url, attr), "object returned from "
+                             "urlopen lacks the %s attribute" % attr)
             self.assertTrue(open_url.read(), "calling 'read' failed")
-        finally:
-            open_url.close()
 
     def test_info(self):
         handler = self.start_server()
diff -r d478a2a5738a Lib/test/test_xmlrpc.py
--- a/Lib/test/test_xmlrpc.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_xmlrpc.py	Fri Mar 20 12:51:24 2015 +0200
@@ -586,10 +586,9 @@ class SimpleServerTestCase(BaseServerTes
     def XXXtest_404(self):
         # send POST with http.client, it should return 404 header and
         # 'Not Found' message.
-        conn = httplib.client.HTTPConnection(ADDR, PORT)
-        conn.request('POST', '/this-is-not-valid')
-        response = conn.getresponse()
-        conn.close()
+        with contextlib.closing(httplib.client.HTTPConnection(ADDR, PORT)) as conn:
+            conn.request('POST', '/this-is-not-valid')
+            response = conn.getresponse()
 
         self.assertEqual(response.status, 404)
         self.assertEqual(response.reason, 'Not Found')
@@ -709,9 +708,8 @@ class SimpleServerTestCase(BaseServerTes
 
     def test_partial_post(self):
         # Check that a partial POST doesn't make the server loop: issue #14001.
-        conn = http.client.HTTPConnection(ADDR, PORT)
-        conn.request('POST', '/RPC2 HTTP/1.0\r\nContent-Length: 100\r\n\r\nbye')
-        conn.close()
+        with contextlib.closing(http.client.HTTPConnection(ADDR, PORT)) as conn:
+            conn.request('POST', '/RPC2 HTTP/1.0\r\nContent-Length: 100\r\n\r\nbye')
 
     def test_context_manager(self):
         with xmlrpclib.ServerProxy(URL) as server:
diff -r d478a2a5738a Lib/test/test_zipimport.py
--- a/Lib/test/test_zipimport.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_zipimport.py	Fri Mar 20 12:51:24 2015 +0200
@@ -406,15 +406,12 @@ class UncompressedZipImportTestCase(Impo
                      "need an unencodable filename")
     def testUnencodable(self):
         filename = support.TESTFN_UNENCODABLE + ".zip"
-        z = ZipFile(filename, "w")
-        zinfo = ZipInfo(TESTMOD + ".py", time.localtime(NOW))
-        zinfo.compress_type = self.compression
-        z.writestr(zinfo, test_src)
-        z.close()
-        try:
-            zipimport.zipimporter(filename)
-        finally:
-            os.remove(filename)
+        with ZipFile(filename, "w") as z:
+            self.addCleanup(os.remove, filename)
+            zinfo = ZipInfo(TESTMOD + ".py", time.localtime(NOW))
+            zinfo.compress_type = self.compression
+            z.writestr(zinfo, test_src)
+        zipimport.zipimporter(filename)
 
 
 @support.requires_zlib
diff -r d478a2a5738a Lib/test/test_zipimport_support.py
--- a/Lib/test/test_zipimport_support.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_zipimport_support.py	Fri Mar 20 12:51:24 2015 +0200
@@ -123,15 +123,13 @@ class ZipSupportTests(unittest.TestCase)
                                             test_src)
             zip_name, run_name = make_zip_script(d, 'test_zip',
                                                 script_name)
-            z = zipfile.ZipFile(zip_name, 'a')
-            for mod_name, src in sample_sources.items():
-                z.writestr(mod_name + ".py", src)
-            z.close()
+            with zipfile.ZipFile(zip_name, 'a') as z:
+                for mod_name, src in sample_sources.items():
+                    z.writestr(mod_name + ".py", src)
             if verbose:
-                zip_file = zipfile.ZipFile(zip_name, 'r')
-                print ('Contents of %r:' % zip_name)
-                zip_file.printdir()
-                zip_file.close()
+                with zipfile.ZipFile(zip_name, 'r') as zip_file:
+                    print ('Contents of %r:' % zip_name)
+                    zip_file.printdir()
             os.remove(script_name)
             sys.path.insert(0, zip_name)
             import test_zipped_doctest
-------------- next part --------------
diff -r d478a2a5738a Parser/asdl_c.py
--- a/Parser/asdl_c.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Parser/asdl_c.py	Fri Mar 20 12:55:15 2015 +0200
@@ -1252,41 +1252,39 @@ def main(srcfile, dump_module=False):
         sys.exit(1)
     if INC_DIR:
         p = "%s/%s-ast.h" % (INC_DIR, mod.name)
-        f = open(p, "w")
-        f.write(auto_gen_msg)
-        f.write('#include "asdl.h"\n\n')
-        c = ChainOfVisitors(TypeDefVisitor(f),
-                            StructVisitor(f),
-                            PrototypeVisitor(f),
-                            )
-        c.visit(mod)
-        f.write("PyObject* PyAST_mod2obj(mod_ty t);\n")
-        f.write("mod_ty PyAST_obj2mod(PyObject* ast, PyArena* arena, int mode);\n")
-        f.write("int PyAST_Check(PyObject* obj);\n")
-        f.close()
+        with open(p, "w") as f:
+            f.write(auto_gen_msg)
+            f.write('#include "asdl.h"\n\n')
+            c = ChainOfVisitors(TypeDefVisitor(f),
+                                StructVisitor(f),
+                                PrototypeVisitor(f),
+                                )
+            c.visit(mod)
+            f.write("PyObject* PyAST_mod2obj(mod_ty t);\n")
+            f.write("mod_ty PyAST_obj2mod(PyObject* ast, PyArena* arena, int mode);\n")
+            f.write("int PyAST_Check(PyObject* obj);\n")
 
     if SRC_DIR:
         p = os.path.join(SRC_DIR, str(mod.name) + "-ast.c")
-        f = open(p, "w")
-        f.write(auto_gen_msg)
-        f.write('#include <stddef.h>\n')
-        f.write('\n')
-        f.write('#include "Python.h"\n')
-        f.write('#include "%s-ast.h"\n' % mod.name)
-        f.write('\n')
-        f.write("static PyTypeObject AST_type;\n")
-        v = ChainOfVisitors(
-            PyTypesDeclareVisitor(f),
-            PyTypesVisitor(f),
-            Obj2ModPrototypeVisitor(f),
-            FunctionVisitor(f),
-            ObjVisitor(f),
-            Obj2ModVisitor(f),
-            ASTModuleVisitor(f),
-            PartingShots(f),
-            )
-        v.visit(mod)
-        f.close()
+        with open(p, "w") as f:
+            f.write(auto_gen_msg)
+            f.write('#include <stddef.h>\n')
+            f.write('\n')
+            f.write('#include "Python.h"\n')
+            f.write('#include "%s-ast.h"\n' % mod.name)
+            f.write('\n')
+            f.write("static PyTypeObject AST_type;\n")
+            v = ChainOfVisitors(
+                PyTypesDeclareVisitor(f),
+                PyTypesVisitor(f),
+                Obj2ModPrototypeVisitor(f),
+                FunctionVisitor(f),
+                ObjVisitor(f),
+                Obj2ModVisitor(f),
+                ASTModuleVisitor(f),
+                PartingShots(f),
+                )
+            v.visit(mod)
 
 if __name__ == "__main__":
     import sys
diff -r d478a2a5738a Tools/scripts/fixcid.py
--- a/Tools/scripts/fixcid.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/fixcid.py	Fri Mar 20 12:55:15 2015 +0200
@@ -279,36 +279,36 @@ def addsubst(substfile):
     except IOError as msg:
         err(substfile + ': cannot read substfile: ' + str(msg) + '\n')
         sys.exit(1)
-    lineno = 0
-    while 1:
-        line = fp.readline()
-        if not line: break
-        lineno = lineno + 1
-        try:
-            i = line.index('#')
-        except ValueError:
-            i = -1          # Happens to delete trailing \n
-        words = line[:i].split()
-        if not words: continue
-        if len(words) == 3 and words[0] == 'struct':
-            words[:2] = [words[0] + ' ' + words[1]]
-        elif len(words) != 2:
-            err(substfile + '%s:%r: warning: bad line: %r' % (substfile, lineno, line))
-            continue
-        if Reverse:
-            [value, key] = words
-        else:
-            [key, value] = words
-        if value[0] == '*':
-            value = value[1:]
-        if key[0] == '*':
-            key = key[1:]
-            NotInComment[key] = value
-        if key in Dict:
-            err('%s:%r: warning: overriding: %r %r\n' % (substfile, lineno, key, value))
-            err('%s:%r: warning: previous: %r\n' % (substfile, lineno, Dict[key]))
-        Dict[key] = value
-    fp.close()
+    with fp:
+        lineno = 0
+        while 1:
+            line = fp.readline()
+            if not line: break
+            lineno = lineno + 1
+            try:
+                i = line.index('#')
+            except ValueError:
+                i = -1          # Happens to delete trailing \n
+            words = line[:i].split()
+            if not words: continue
+            if len(words) == 3 and words[0] == 'struct':
+                words[:2] = [words[0] + ' ' + words[1]]
+            elif len(words) != 2:
+                err(substfile + '%s:%r: warning: bad line: %r' % (substfile, lineno, line))
+                continue
+            if Reverse:
+                [value, key] = words
+            else:
+                [key, value] = words
+            if value[0] == '*':
+                value = value[1:]
+            if key[0] == '*':
+                key = key[1:]
+                NotInComment[key] = value
+            if key in Dict:
+                err('%s:%r: warning: overriding: %r %r\n' % (substfile, lineno, key, value))
+                err('%s:%r: warning: previous: %r\n' % (substfile, lineno, Dict[key]))
+            Dict[key] = value
 
 if __name__ == '__main__':
     main()
diff -r d478a2a5738a Tools/scripts/fixdiv.py
--- a/Tools/scripts/fixdiv.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/fixdiv.py	Fri Mar 20 12:55:15 2015 +0200
@@ -185,21 +185,21 @@ def readwarnings(warningsfile):
         sys.stderr.write("can't open: %s\n" % msg)
         return
     warnings = {}
-    while 1:
-        line = f.readline()
-        if not line:
-            break
-        m = prog.match(line)
-        if not m:
-            if line.find("division") >= 0:
-                sys.stderr.write("Warning: ignored input " + line)
-            continue
-        filename, lineno, what = m.groups()
-        list = warnings.get(filename)
-        if list is None:
-            warnings[filename] = list = []
-        list.append((int(lineno), sys.intern(what)))
-    f.close()
+    with f:
+        while 1:
+            line = f.readline()
+            if not line:
+                break
+            m = prog.match(line)
+            if not m:
+                if line.find("division") >= 0:
+                    sys.stderr.write("Warning: ignored input " + line)
+                continue
+            filename, lineno, what = m.groups()
+            list = warnings.get(filename)
+            if list is None:
+                warnings[filename] = list = []
+            list.append((int(lineno), sys.intern(what)))
     return warnings
 
 def process(filename, list):
@@ -210,84 +210,84 @@ def process(filename, list):
     except IOError as msg:
         sys.stderr.write("can't open: %s\n" % msg)
         return 1
-    print("Index:", filename)
-    f = FileContext(fp)
-    list.sort()
-    index = 0 # list[:index] has been processed, list[index:] is still to do
-    g = tokenize.generate_tokens(f.readline)
-    while 1:
-        startlineno, endlineno, slashes = lineinfo = scanline(g)
-        if startlineno is None:
-            break
-        assert startlineno <= endlineno is not None
-        orphans = []
-        while index < len(list) and list[index][0] < startlineno:
-            orphans.append(list[index])
-            index += 1
-        if orphans:
-            reportphantomwarnings(orphans, f)
-        warnings = []
-        while index < len(list) and list[index][0] <= endlineno:
-            warnings.append(list[index])
-            index += 1
-        if not slashes and not warnings:
-            pass
-        elif slashes and not warnings:
-            report(slashes, "No conclusive evidence")
-        elif warnings and not slashes:
-            reportphantomwarnings(warnings, f)
-        else:
-            if len(slashes) > 1:
-                if not multi_ok:
-                    rows = []
-                    lastrow = None
-                    for (row, col), line in slashes:
-                        if row == lastrow:
-                            continue
-                        rows.append(row)
-                        lastrow = row
-                    assert rows
-                    if len(rows) == 1:
-                        print("*** More than one / operator in line", rows[0])
+    with fp:
+        print("Index:", filename)
+        f = FileContext(fp)
+        list.sort()
+        index = 0 # list[:index] has been processed, list[index:] is still to do
+        g = tokenize.generate_tokens(f.readline)
+        while 1:
+            startlineno, endlineno, slashes = lineinfo = scanline(g)
+            if startlineno is None:
+                break
+            assert startlineno <= endlineno is not None
+            orphans = []
+            while index < len(list) and list[index][0] < startlineno:
+                orphans.append(list[index])
+                index += 1
+            if orphans:
+                reportphantomwarnings(orphans, f)
+            warnings = []
+            while index < len(list) and list[index][0] <= endlineno:
+                warnings.append(list[index])
+                index += 1
+            if not slashes and not warnings:
+                pass
+            elif slashes and not warnings:
+                report(slashes, "No conclusive evidence")
+            elif warnings and not slashes:
+                reportphantomwarnings(warnings, f)
+            else:
+                if len(slashes) > 1:
+                    if not multi_ok:
+                        rows = []
+                        lastrow = None
+                        for (row, col), line in slashes:
+                            if row == lastrow:
+                                continue
+                            rows.append(row)
+                            lastrow = row
+                        assert rows
+                        if len(rows) == 1:
+                            print("*** More than one / operator in line", rows[0])
+                        else:
+                            print("*** More than one / operator per statement", end=' ')
+                            print("in lines %d-%d" % (rows[0], rows[-1]))
+                intlong = []
+                floatcomplex = []
+                bad = []
+                for lineno, what in warnings:
+                    if what in ("int", "long"):
+                        intlong.append(what)
+                    elif what in ("float", "complex"):
+                        floatcomplex.append(what)
                     else:
-                        print("*** More than one / operator per statement", end=' ')
-                        print("in lines %d-%d" % (rows[0], rows[-1]))
-            intlong = []
-            floatcomplex = []
-            bad = []
-            for lineno, what in warnings:
-                if what in ("int", "long"):
-                    intlong.append(what)
-                elif what in ("float", "complex"):
-                    floatcomplex.append(what)
-                else:
-                    bad.append(what)
-            lastrow = None
-            for (row, col), line in slashes:
-                if row == lastrow:
-                    continue
-                lastrow = row
-                line = chop(line)
-                if line[col:col+1] != "/":
-                    print("*** Can't find the / operator in line %d:" % row)
-                    print("*", line)
-                    continue
-                if bad:
-                    print("*** Bad warning for line %d:" % row, bad)
-                    print("*", line)
-                elif intlong and not floatcomplex:
-                    print("%dc%d" % (row, row))
-                    print("<", line)
-                    print("---")
-                    print(">", line[:col] + "/" + line[col:])
-                elif floatcomplex and not intlong:
-                    print("True division / operator at line %d:" % row)
-                    print("=", line)
-                elif intlong and floatcomplex:
-                    print("*** Ambiguous / operator (%s, %s) at line %d:" % (
-                        "|".join(intlong), "|".join(floatcomplex), row))
-                    print("?", line)
-    fp.close()
+                        bad.append(what)
+                lastrow = None
+                for (row, col), line in slashes:
+                    if row == lastrow:
+                        continue
+                    lastrow = row
+                    line = chop(line)
+                    if line[col:col+1] != "/":
+                        print("*** Can't find the / operator in line %d:" % row)
+                        print("*", line)
+                        continue
+                    if bad:
+                        print("*** Bad warning for line %d:" % row, bad)
+                        print("*", line)
+                    elif intlong and not floatcomplex:
+                        print("%dc%d" % (row, row))
+                        print("<", line)
+                        print("---")
+                        print(">", line[:col] + "/" + line[col:])
+                    elif floatcomplex and not intlong:
+                        print("True division / operator at line %d:" % row)
+                        print("=", line)
+                    elif intlong and floatcomplex:
+                        print("*** Ambiguous / operator (%s, %s) at line %d:" %
+                            ("|".join(intlong), "|".join(floatcomplex), row))
+                        print("?", line)
 
 def reportphantomwarnings(warnings, f):
     blocks = []
diff -r d478a2a5738a Tools/scripts/fixheader.py
--- a/Tools/scripts/fixheader.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/fixheader.py	Fri Mar 20 12:55:15 2015 +0200
@@ -15,8 +15,8 @@ def process(filename):
     except IOError as msg:
         sys.stderr.write('%s: can\'t open: %s\n' % (filename, str(msg)))
         return
-    data = f.read()
-    f.close()
+    with f:
+        data = f.read()
     if data[:2] != '/*':
         sys.stderr.write('%s does not begin with C comment\n' % filename)
         return
@@ -31,19 +31,19 @@ def process(filename):
         if ord(c)<=0x80 and c.isalnum():
             magic = magic + c.upper()
         else: magic = magic + '_'
-    sys.stdout = f
-    print('#ifndef', magic)
-    print('#define', magic)
-    print('#ifdef __cplusplus')
-    print('extern "C" {')
-    print('#endif')
-    print()
-    f.write(data)
-    print()
-    print('#ifdef __cplusplus')
-    print('}')
-    print('#endif')
-    print('#endif /*', '!'+magic, '*/')
+    with f:
+        print('#ifndef', magic, file=f)
+        print('#define', magic, file=f)
+        print('#ifdef __cplusplus', file=f)
+        print('extern "C" {', file=f)
+        print('#endif', file=f)
+        print(file=f)
+        f.write(data)
+        print(file=f)
+        print('#ifdef __cplusplus', file=f)
+        print('}', file=f)
+        print('#endif', file=f)
+        print('#endif /*', '!'+magic, '*/', file=f)
 
 if __name__ == '__main__':
     main()
diff -r d478a2a5738a Tools/scripts/gprof2html.py
--- a/Tools/scripts/gprof2html.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/gprof2html.py	Fri Mar 20 12:55:15 2015 +0200
@@ -28,14 +28,7 @@ def add_escapes(filename):
         for line in fp:
             yield html.escape(line)
 
-
-def main():
-    filename = "gprof.out"
-    if sys.argv[1:]:
-        filename = sys.argv[1]
-    outputfilename = filename + ".html"
-    input = add_escapes(filename)
-    output = open(outputfilename, "w")
+def gprof2html(input, output, filename):
     output.write(header % filename)
     for line in input:
         output.write(line)
@@ -78,7 +71,16 @@ def main():
                 part = '<a href="#call:%s">%s</a>' % (part, part)
             output.write(part)
     output.write(trailer)
-    output.close()
+
+
+def main():
+    filename = "gprof.out"
+    if sys.argv[1:]:
+        filename = sys.argv[1]
+    outputfilename = filename + ".html"
+    input = add_escapes(filename)
+    with open(outputfilename, "w") as output:
+        gprof2html(input, output, filename)
     webbrowser.open("file:" + os.path.abspath(outputfilename))
 
 if __name__ == '__main__':
diff -r d478a2a5738a Tools/scripts/texi2html.py
--- a/Tools/scripts/texi2html.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/texi2html.py	Fri Mar 20 12:55:15 2015 +0200
@@ -118,11 +118,10 @@ class HTMLNode:
             self.lines.append(line)
 
     def flush(self):
-        fp = open(self.dirname + '/' + makefile(self.name), 'w')
-        fp.write(self.prologue)
-        fp.write(self.text)
-        fp.write(self.epilogue)
-        fp.close()
+        with open(self.dirname + '/' + makefile(self.name), 'w') as fp:
+            fp.write(self.prologue)
+            fp.write(self.text)
+            fp.write(self.epilogue)
 
     def link(self, label, nodename, rel=None, rev=None):
         if nodename:
@@ -558,14 +557,14 @@ class TexinfoParser:
         except IOError as msg:
             print('*** Can\'t open include file', repr(file))
             return
-        print('!'*self.debugging, '--> file', repr(file))
-        save_done = self.done
-        save_skip = self.skip
-        save_stack = self.stack
-        self.includedepth = self.includedepth + 1
-        self.parserest(fp, 0)
-        self.includedepth = self.includedepth - 1
-        fp.close()
+        with fp:
+            print('!'*self.debugging, '--> file', repr(file))
+            save_done = self.done
+            save_skip = self.skip
+            save_stack = self.stack
+            self.includedepth = self.includedepth + 1
+            self.parserest(fp, 0)
+            self.includedepth = self.includedepth - 1
         self.done = save_done
         self.skip = save_skip
         self.stack = save_stack
@@ -1770,78 +1769,75 @@ class HTMLHelp:
 
         # PROJECT FILE
         try:
-            fp = open(projectfile,'w')
-            print('[OPTIONS]', file=fp)
-            print('Auto Index=Yes', file=fp)
-            print('Binary TOC=No', file=fp)
-            print('Binary Index=Yes', file=fp)
-            print('Compatibility=1.1', file=fp)
-            print('Compiled file=' + resultfile + '', file=fp)
-            print('Contents file=' + contentfile + '', file=fp)
-            print('Default topic=' + defaulttopic + '', file=fp)
-            print('Error log file=ErrorLog.log', file=fp)
-            print('Index file=' + indexfile + '', file=fp)
-            print('Title=' + title + '', file=fp)
-            print('Display compile progress=Yes', file=fp)
-            print('Full-text search=Yes', file=fp)
-            print('Default window=main', file=fp)
-            print('', file=fp)
-            print('[WINDOWS]', file=fp)
-            print('main=,"' + contentfile + '","' + indexfile
-                        + '","","",,,,,0x23520,222,0x1046,[10,10,780,560],'
-                        '0xB0000,,,,,,0', file=fp)
-            print('', file=fp)
-            print('[FILES]', file=fp)
-            print('', file=fp)
-            self.dumpfiles(fp)
-            fp.close()
+            with open(projectfile, 'w') as fp:
+                print('[OPTIONS]', file=fp)
+                print('Auto Index=Yes', file=fp)
+                print('Binary TOC=No', file=fp)
+                print('Binary Index=Yes', file=fp)
+                print('Compatibility=1.1', file=fp)
+                print('Compiled file=' + resultfile + '', file=fp)
+                print('Contents file=' + contentfile + '', file=fp)
+                print('Default topic=' + defaulttopic + '', file=fp)
+                print('Error log file=ErrorLog.log', file=fp)
+                print('Index file=' + indexfile + '', file=fp)
+                print('Title=' + title + '', file=fp)
+                print('Display compile progress=Yes', file=fp)
+                print('Full-text search=Yes', file=fp)
+                print('Default window=main', file=fp)
+                print('', file=fp)
+                print('[WINDOWS]', file=fp)
+                print('main=,"' + contentfile + '","' + indexfile
+                            + '","","",,,,,0x23520,222,0x1046,[10,10,780,560],'
+                            '0xB0000,,,,,,0', file=fp)
+                print('', file=fp)
+                print('[FILES]', file=fp)
+                print('', file=fp)
+                self.dumpfiles(fp)
         except IOError as msg:
             print(projectfile, ':', msg)
             sys.exit(1)
 
         # CONTENT FILE
         try:
-            fp = open(contentfile,'w')
-            print('<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">', file=fp)
-            print('<!-- This file defines the table of contents -->', file=fp)
-            print('<HTML>', file=fp)
-            print('<HEAD>', file=fp)
-            print('<meta name="GENERATOR"'
-                        'content="Microsoft&reg; HTML Help Workshop 4.1">', file=fp)
-            print('<!-- Sitemap 1.0 -->', file=fp)
-            print('</HEAD>', file=fp)
-            print('<BODY>', file=fp)
-            print('   <OBJECT type="text/site properties">', file=fp)
-            print('     <param name="Window Styles" value="0x800025">', file=fp)
-            print('     <param name="comment" value="title:">', file=fp)
-            print('     <param name="comment" value="base:">', file=fp)
-            print('   </OBJECT>', file=fp)
-            self.dumpnodes(fp)
-            print('</BODY>', file=fp)
-            print('</HTML>', file=fp)
-            fp.close()
+            with open(contentfile, 'w') as fp:
+                print('<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">', file=fp)
+                print('<!-- This file defines the table of contents -->', file=fp)
+                print('<HTML>', file=fp)
+                print('<HEAD>', file=fp)
+                print('<meta name="GENERATOR" '
+                      'content="Microsoft&reg; HTML Help Workshop 4.1">', file=fp)
+                print('<!-- Sitemap 1.0 -->', file=fp)
+                print('</HEAD>', file=fp)
+                print('<BODY>', file=fp)
+                print('   <OBJECT type="text/site properties">', file=fp)
+                print('     <param name="Window Styles" value="0x800025">', file=fp)
+                print('     <param name="comment" value="title:">', file=fp)
+                print('     <param name="comment" value="base:">', file=fp)
+                print('   </OBJECT>', file=fp)
+                self.dumpnodes(fp)
+                print('</BODY>', file=fp)
+                print('</HTML>', file=fp)
         except IOError as msg:
             print(contentfile, ':', msg)
             sys.exit(1)
 
         # INDEX FILE
         try:
-            fp = open(indexfile  ,'w')
-            print('<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">', file=fp)
-            print('<!-- This file defines the index -->', file=fp)
-            print('<HTML>', file=fp)
-            print('<HEAD>', file=fp)
-            print('<meta name="GENERATOR"'
-                        'content="Microsoft&reg; HTML Help Workshop 4.1">', file=fp)
-            print('<!-- Sitemap 1.0 -->', file=fp)
-            print('</HEAD>', file=fp)
-            print('<BODY>', file=fp)
-            print('<OBJECT type="text/site properties">', file=fp)
-            print('</OBJECT>', file=fp)
-            self.dumpindex(fp)
-            print('</BODY>', file=fp)
-            print('</HTML>', file=fp)
-            fp.close()
+            with open(indexfile, 'w') as fp:
+                print('<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">', file=fp)
+                print('<!-- This file defines the index -->', file=fp)
+                print('<HTML>', file=fp)
+                print('<HEAD>', file=fp)
+                print('<meta name="GENERATOR" '
+                      'content="Microsoft&reg; HTML Help Workshop 4.1">', file=fp)
+                print('<!-- Sitemap 1.0 -->', file=fp)
+                print('</HEAD>', file=fp)
+                print('<BODY>', file=fp)
+                print('<OBJECT type="text/site properties">', file=fp)
+                print('</OBJECT>', file=fp)
+                self.dumpindex(fp)
+                print('</BODY>', file=fp)
+                print('</HTML>', file=fp)
         except IOError as msg:
             print(indexfile  , ':', msg)
             sys.exit(1)
@@ -2064,8 +2060,8 @@ def test():
         print(file, ':', msg)
         sys.exit(1)
 
-    parser.parse(fp)
-    fp.close()
+    with fp:
+        parser.parse(fp)
     parser.report()
 
     htmlhelp.finalize()
diff -r d478a2a5738a Tools/scripts/treesync.py
--- a/Tools/scripts/treesync.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/treesync.py	Fri Mar 20 12:55:15 2015 +0200
@@ -23,7 +23,7 @@ entry in the master tree are synchronize
 
 """
 
-import os, sys, stat, getopt
+import os, sys, stat, getopt, shutil
 
 # Interactivity options
 default_answer = "ask"
@@ -96,7 +96,9 @@ def process(slave, master):
                 subdirs.append((slavename, mastername))
     if cvsdir:
         entries = os.path.join(cvsdir, "Entries")
-        for e in open(entries).readlines():
+        with open(entries) as f:
+            lines = f.readlines()
+        for e in lines:
             words = e.split('/')
             if words[0] == '' and words[1:]:
                 name = words[1]
@@ -110,47 +112,45 @@ def compare(slave, master):
     try:
         sf = open(slave, 'r')
     except IOError:
-        sf = None
-    try:
-        mf = open(master, 'rb')
-    except IOError:
-        mf = None
-    if not sf:
-        if not mf:
+        try:
+            with open(master, 'rb'): pass
+        except IOError:
             print("Neither master nor slave exists", master)
             return
         print("Creating missing slave", slave)
         copy(master, slave, answer=create_files)
         return
-    if not mf:
-        print("Not updating missing master", master)
-        return
-    if sf and mf:
-        if identical(sf, mf):
+    with sf:
+        try:
+            mf = open(master, 'rb')
+        except IOError:
+            print("Not updating missing master", master)
             return
-    sft = mtime(sf)
-    mft = mtime(mf)
-    if mft > sft:
-        # Master is newer -- copy master to slave
-        sf.close()
-        mf.close()
-        print("Master             ", master)
-        print("is newer than slave", slave)
-        copy(master, slave, answer=write_slave)
-        return
-    # Slave is newer -- copy slave to master
-    print("Slave is", sft-mft, "seconds newer than master")
-    # But first check what to do about CRLF
-    mf.seek(0)
-    fun = funnychars(mf)
-    mf.close()
-    sf.close()
-    if fun:
-        print("***UPDATING MASTER (BINARY COPY)***")
-        copy(slave, master, "rb", answer=write_master)
-    else:
-        print("***UPDATING MASTER***")
-        copy(slave, master, "r", answer=write_master)
+        with mf:
+            if identical(sf, mf):
+                return
+            sft = mtime(sf)
+            mft = mtime(mf)
+            if mft > sft:
+                # Master is newer -- copy master to slave
+                print("Master             ", master)
+                print("is newer than slave", slave)
+                args = (master, slave)
+                answer = write_slave
+            else:
+                # Slave is newer -- copy slave to master
+                print("Slave is", sft-mft, "seconds newer than master")
+                # But first check what to do about CRLF
+                mf.seek(0)
+                fun = funnychars(mf)
+                if fun:
+                    print("***UPDATING MASTER (BINARY COPY)***")
+                    args = (slave, master, "rb")
+                else:
+                    print("***UPDATING MASTER***")
+                    args = (slave, master, "r")
+                answer=write_master
+    copy(*args, answer=answer)
 
 BUFSIZE = 16*1024
 
@@ -178,14 +178,12 @@ def copy(src, dst, rmode="rb", wmode="wb
     print("     to", dst)
     if not okay("okay to copy? ", answer):
         return
-    f = open(src, rmode)
-    g = open(dst, wmode)
-    while 1:
-        buf = f.read(BUFSIZE)
-        if not buf: break
-        g.write(buf)
-    f.close()
-    g.close()
+    with open(src, rmode) as f, \
+         open(dst, wmode) as g:
+        while 1:
+            buf = f.read(BUFSIZE)
+            if not buf: break
+            g.write(buf)
 
 def raw_input(prompt):
     sys.stdout.write(prompt)

From report at bugs.python.org  Fri Mar 20 13:09:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 12:09:51 +0000
Subject: [issue23719] PEP 475: port test_eintr to Windows
Message-ID: <1426853391.45.0.421512531157.issue23719@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Currently, test_eintr is complelty skipped on Windows. time.sleep() was also patched on Windows to retry when interrupted by a signal (issue #23646) and I was able to see a different when testing manually.

test_eintr is currently implemented with signal.setitimer() and os.fork(). Windows doesn't have signal.setitimer(), signal.alarm(), nor os.fork(), but it's possible to send a signal to another process using os.kill() (by the way, see the issue #14484 "missing return in win32_kill?").

At least, time.sleep() should be tested on Windows.

----------
messages: 238652
nosy: haypo
priority: normal
severity: normal
status: open
title: PEP 475: port test_eintr to Windows
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23719>
_______________________________________

From report at bugs.python.org  Fri Mar 20 13:09:59 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 12:09:59 +0000
Subject: [issue23719] PEP 475: port test_eintr to Windows
In-Reply-To: <1426853391.45.0.421512531157.issue23719@psf.upfronthosting.co.za>
Message-ID: <1426853399.51.0.983314958124.issue23719@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
components: +Tests, Windows
nosy: +steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23719>
_______________________________________

From report at bugs.python.org  Fri Mar 20 13:10:19 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 12:10:19 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>
Message-ID: <1426853419.62.0.629301425726.issue23648@psf.upfronthosting.co.za>


STINNER Victor added the comment:

New issue #23719: "port test_eintr to Windows".

----------
dependencies: +PEP 475: port test_eintr to Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Fri Mar 20 13:10:39 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 12:10:39 +0000
Subject: [issue23715] PEP 475: handle EINTR in the signal module
In-Reply-To: <1426814009.06.0.724045685729.issue23715@psf.upfronthosting.co.za>
Message-ID: <1426853439.26.0.778951436542.issue23715@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23715>
_______________________________________

From report at bugs.python.org  Fri Mar 20 13:11:45 2015
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 20 Mar 2015 12:11:45 +0000
Subject: [issue23476] SSL cert verify fail for "www.verisign.com"
In-Reply-To: <1424221637.85.0.898475945708.issue23476@psf.upfronthosting.co.za>
Message-ID: <1426853505.11.0.0236364095137.issue23476@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23476>
_______________________________________

From report at bugs.python.org  Fri Mar 20 13:26:25 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Mar 2015 12:26:25 +0000
Subject: [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1426854385.07.0.515607143382.issue22832@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: docs at python -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22832>
_______________________________________

From report at bugs.python.org  Fri Mar 20 13:26:30 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 12:26:30 +0000
Subject: [issue14480] os.kill on Windows should accept zero as signal
In-Reply-To: <1333437794.42.0.926195578505.issue14480@psf.upfronthosting.co.za>
Message-ID: <1426854390.16.0.789445821033.issue14480@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> 0 has no special meaning on Windows so I'd rather not add another special case for posix emulation. Additionally, 0 unfortunately already means two things as it is: signal.CTRL_C_EVENT and the int 0.

I agree, it's not a good idea to support os.kill(pid, 0) on Windows. I reject the issue.

See also the issue #14484.

----------
nosy: +haypo
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14480>
_______________________________________

From report at bugs.python.org  Fri Mar 20 13:36:25 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Mar 2015 12:36:25 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za>
Message-ID: <1426854985.87.0.777793725937.issue22831@psf.upfronthosting.co.za>


Martin Panter added the comment:

There were a couple mistakes I found; see Reitveld. I was going to say to leave the open(mode="r") parameter as it is, since an explicit "r" is more readable, but since you already took some out, I?m not going to complain.

While many of the changes look worthwhile, I do worry that some of them will never be tested (at least until say Python 3.14 or something). E.g. I just tried running Tools/scripts/dutree.py cos it looked interesting, but was confronted with the ?unorderable types: int() < NoneType()? Python 2-ism.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22831>
_______________________________________

From report at bugs.python.org  Fri Mar 20 13:38:53 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 12:38:53 +0000
Subject: [issue23715] PEP 475: handle EINTR in the signal module
In-Reply-To: <1426814009.06.0.724045685729.issue23715@psf.upfronthosting.co.za>
Message-ID: <20150320123850.70032.16913@psf.io>


Roundup Robot added the comment:

New changeset 8f9925a02fe7 by Victor Stinner in branch 'default':
Issue #23715: Enhance test.script_helper to investigate test_eintr failure
https://hg.python.org/cpython/rev/8f9925a02fe7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23715>
_______________________________________

From report at bugs.python.org  Fri Mar 20 13:40:03 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 20 Mar 2015 12:40:03 +0000
Subject: [issue23042] ctypes module doesn't build on FreeBSD x86
In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za>
Message-ID: <1426855203.21.0.711410349818.issue23042@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

Modules/_ctypes/libffi in branches 2.7, 3.4, default is currently a copy of libffi 3.1.
Is problem reproducible with libffi 3.2.1? If not, then it might be better to update Modules/_ctypes/libffi to libffi 3.2.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23042>
_______________________________________

From report at bugs.python.org  Fri Mar 20 13:43:30 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 20 Mar 2015 12:43:30 +0000
Subject: [issue23699] Add a macro to ease writing rich comparisons
In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za>
Message-ID: <1426855410.95.0.297635930032.issue23699@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

Serhiy: Thanks for looking at this!
I think it should fall in the same category as Py_RETURN_TRUE or Py_RETURN_NONE. Sure, it's easy to reimplement, but a lot of extensions need it; why should everyone need to write the same code in a dozen different ways?
I specifically want this usable in third-party code.

The implementation of Py_RICHCOMPARE is in the first patch. The second is example use.
The signature mirrors richcmpfunc. Why would op be better as first argument?

Stefan: Which optimizer should I look at? Is it important to generate the same code? 

Sorry if I'm asking for something obvious, I'm not a regular here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23699>
_______________________________________

From report at bugs.python.org  Fri Mar 20 13:43:44 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 12:43:44 +0000
Subject: [issue23715] PEP 475: handle EINTR in the signal module
In-Reply-To: <1426814009.06.0.724045685729.issue23715@psf.upfronthosting.co.za>
Message-ID: <20150320124341.24250.4248@psf.io>


Roundup Robot added the comment:

New changeset 79aed09a9fa5 by Victor Stinner in branch 'default':
Issue #23715: Fix test_eintr, skip tests on signal.sigwaitinfo() and
https://hg.python.org/cpython/rev/79aed09a9fa5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23715>
_______________________________________

From report at bugs.python.org  Fri Mar 20 13:52:20 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 12:52:20 +0000
Subject: [issue23696] zipimport: chain ImportError to OSError
In-Reply-To: <1426640296.98.0.079062899559.issue23696@psf.upfronthosting.co.za>
Message-ID: <20150320125217.30724.68827@psf.io>


Roundup Robot added the comment:

New changeset 022d64b503b8 by Victor Stinner in branch 'default':
Issue #23696: Remove test on ZipImportError.__context__ because the context is
https://hg.python.org/cpython/rev/022d64b503b8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23696>
_______________________________________

From report at bugs.python.org  Fri Mar 20 13:56:26 2015
From: report at bugs.python.org (Alexey Kazantsev)
Date: Fri, 20 Mar 2015 12:56:26 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
Message-ID: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>


New submission from Alexey Kazantsev:

Pythons prior to 3.4.0 print

Vector!
Device!

while >=3.4.0 print

Device!
Vector!

If we replace Main with Vector on line 21, the behavior becomes random: in 50% of all cases it prints the wrong sequence, in other 50% the right. Our team treats this as a bug for several reasons:

1) Objects should be destroyed in breadth first reference tree traversal order, starting from the root. There are no cycles. It is nonsense to have freed children in parent's destructor.

2) Our applications suffer very much from this bug. Real "Vector" holds GPGPU memory and real "Device" holds the context, and CUDA/OpenCL require the context to be freed the last. With CUDA, the invalid destructor call order leads to segmentation faults.

This may have something to deal with the implementation of PEP 442 (though in our case there no reference cycles at all).

----------
files: bug.py
messages: 238661
nosy: Alexey Kazantsev
priority: normal
severity: normal
status: open
title: __del__() order is broken since 3.4.0
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38599/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Fri Mar 20 13:56:48 2015
From: report at bugs.python.org (Alexey Kazantsev)
Date: Fri, 20 Mar 2015 12:56:48 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
In-Reply-To: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>
Message-ID: <1426856208.24.0.0147145380924.issue23720@psf.upfronthosting.co.za>


Changes by Alexey Kazantsev <ajk.xyz at gmail.com>:


----------
components: +Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Fri Mar 20 13:58:55 2015
From: report at bugs.python.org (Vadim Markovtsev)
Date: Fri, 20 Mar 2015 12:58:55 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
In-Reply-To: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>
Message-ID: <1426856335.82.0.167028029127.issue23720@psf.upfronthosting.co.za>


Vadim Markovtsev added the comment:

+1

----------
nosy: +Vadim Markovtsev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Fri Mar 20 14:02:47 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 13:02:47 +0000
Subject: [issue23715] PEP 475: handle EINTR in the signal module
In-Reply-To: <1426814009.06.0.724045685729.issue23715@psf.upfronthosting.co.za>
Message-ID: <20150320130243.11900.62839@psf.io>


Roundup Robot added the comment:

New changeset ed8c2a4a6d3d by Victor Stinner in branch 'default':
Issue #23715: Fix test_script_helper
https://hg.python.org/cpython/rev/ed8c2a4a6d3d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23715>
_______________________________________

From report at bugs.python.org  Fri Mar 20 14:15:30 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 13:15:30 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426857330.92.0.771079118828.issue23700@psf.upfronthosting.co.za>


STINNER Victor added the comment:

tempfile_iter_fix.patch looks good to me, can you commit it please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 14:16:50 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Mar 2015 13:16:50 +0000
Subject: [issue23681] Have -b warn when directly comparing ints and bytes
In-Reply-To: <1426525530.11.0.0814957947674.issue23681@psf.upfronthosting.co.za>
Message-ID: <1426857410.84.0.405795592134.issue23681@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I did one final pass on the patch and only had wording comments, so tweak those and it LGTM. Assigned to Serhiy since it's obviously his patch. =)

Only other thing is to either open up a separate bug or at least apply the fixes to the stdlib in Python 3.4 as well as 3.5.

----------
assignee: brett.cannon -> serhiy.storchaka
nosy: +larry
stage: patch review -> commit review
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23681>
_______________________________________

From report at bugs.python.org  Fri Mar 20 14:17:41 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Fri, 20 Mar 2015 13:17:41 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1426857461.5.0.514338199316.issue23688@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

ok, I've prepared a patch including tests based on my last suggestion, which I think is ready for getting reviewed.

----------
Added file: http://bugs.python.org/file38600/write_bytes_like_objects.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Fri Mar 20 14:23:26 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 20 Mar 2015 13:23:26 +0000
Subject: [issue23042] ctypes module doesn't build on FreeBSD x86
In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za>
Message-ID: <1426857806.75.0.584252055876.issue23042@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

I would prefer to have someone with good libffi knowledge to chime in here. It's easy to just revert the patch, but it may be even better to upgrade the included libffi lib.

But probably not to 3.2.1, since this still has the same bug it seems:

https://github.com/atgreen/libffi/blob/v3.2.1/src/x86/ffi.c#L401

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23042>
_______________________________________

From report at bugs.python.org  Fri Mar 20 14:28:51 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Mar 2015 13:28:51 +0000
Subject: [issue23721] Set up a daily test coverage run
Message-ID: <1426858130.98.0.810512379451.issue23721@psf.upfronthosting.co.za>


New submission from Brett Cannon:

devinabox has instructions on how to get the best test coverage for Python possible: https://hg.python.org/devinabox/file/1eeb96fe98f1/README#l124 . It would probably be good to get a test report at least daily to help keep an eye on general test coverage and to help new contributors to know where they can help by contributing more tests.

Otherwise we should try to get something like https://coveralls.io/ set up on https://github.com/python/cpython

----------
messages: 238668
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Set up a daily test coverage run

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23721>
_______________________________________

From report at bugs.python.org  Fri Mar 20 14:33:34 2015
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 20 Mar 2015 13:33:34 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
In-Reply-To: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>
Message-ID: <1426858414.82.0.367019348121.issue23720@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Actually there *is* a cycle:
  assert a.vector is a.vector.device.__class__.__del__.__globals__['a'].vector

A workaround is to not store objects with __del__ in module globals...
Or have only one (the Main instance in your case)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Fri Mar 20 14:39:19 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 13:39:19 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1426854985.87.0.777793725937.issue22831@psf.upfronthosting.co.za>
Message-ID: <3408634.JG9RbX3NfB@raxxla>


Serhiy Storchaka added the comment:

Here are updated patches with fixed mistakes found by Martin.

> While many of the changes look worthwhile, I do worry that some of them will
> never be tested (at least until say Python 3.14 or something). E.g. I just
> tried running Tools/scripts/dutree.py cos it looked interesting, but was
> confronted with the ?unorderable types: int() < NoneType()? Python 2-ism.

Yes, sad, but Tools/scripts/ is full of Python 2-isms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22831>
_______________________________________

From report at bugs.python.org  Fri Mar 20 14:39:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 13:39:53 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1426854985.87.0.777793725937.issue22831@psf.upfronthosting.co.za>
Message-ID: <6153497.X4pU8daJc1@raxxla>


Serhiy Storchaka added the comment:

?'??????, 20-???-2015 12:36:25 ?? ????????:
> Martin Panter added the comment:
> 
> There were a couple mistakes I found; see Reitveld. I was going to say to
> leave the open(mode="r") parameter as it is, since an explicit "r" is more
> readable, but since you already took some out, I?m not going to complain.
> 
> While many of the changes look worthwhile, I do worry that some of them will
> never be tested (at least until say Python 3.14 or something). E.g. I just
> tried running Tools/scripts/dutree.py cos it looked interesting, but was
> confronted with the ?unorderable types: int() < NoneType()? Python 2-ism.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22831>
> _______________________________________

----------
Added file: http://bugs.python.org/file38601/fd_leaks_tests1_2.patch
Added file: http://bugs.python.org/file38602/fd_leaks_tools1_2.patch
Added file: http://bugs.python.org/file38603/fd_leaks_tools2_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22831>
_______________________________________
-------------- next part --------------
diff -r d478a2a5738a Lib/test/test_dbm_dumb.py
--- a/Lib/test/test_dbm_dumb.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_dbm_dumb.py	Fri Mar 20 14:17:30 2015 +0200
@@ -2,6 +2,7 @@
    Original by Roger E. Masse
 """
 
+import contextlib
 import io
 import operator
 import os
@@ -31,12 +32,11 @@ class DumbDBMTestCase(unittest.TestCase)
              }
 
     def test_dumbdbm_creation(self):
-        f = dumbdbm.open(_fname, 'c')
-        self.assertEqual(list(f.keys()), [])
-        for key in self._dict:
-            f[key] = self._dict[key]
-        self.read_helper(f)
-        f.close()
+        with contextlib.closing(dumbdbm.open(_fname, 'c')) as f:
+            self.assertEqual(list(f.keys()), [])
+            for key in self._dict:
+                f[key] = self._dict[key]
+            self.read_helper(f)
 
     @unittest.skipUnless(hasattr(os, 'umask'), 'test needs os.umask()')
     @unittest.skipUnless(hasattr(os, 'chmod'), 'test needs os.chmod()')
@@ -69,63 +69,55 @@ class DumbDBMTestCase(unittest.TestCase)
 
     def test_dumbdbm_modification(self):
         self.init_db()
-        f = dumbdbm.open(_fname, 'w')
-        self._dict[b'g'] = f[b'g'] = b"indented"
-        self.read_helper(f)
-        f.close()
+        with contextlib.closing(dumbdbm.open(_fname, 'w')) as f:
+            self._dict[b'g'] = f[b'g'] = b"indented"
+            self.read_helper(f)
 
     def test_dumbdbm_read(self):
         self.init_db()
-        f = dumbdbm.open(_fname, 'r')
-        self.read_helper(f)
-        f.close()
+        with contextlib.closing(dumbdbm.open(_fname, 'r')) as f:
+            self.read_helper(f)
 
     def test_dumbdbm_keys(self):
         self.init_db()
-        f = dumbdbm.open(_fname)
-        keys = self.keys_helper(f)
-        f.close()
+        with contextlib.closing(dumbdbm.open(_fname)) as f:
+            keys = self.keys_helper(f)
 
     def test_write_contains(self):
-        f = dumbdbm.open(_fname)
-        f[b'1'] = b'hello'
-        self.assertIn(b'1', f)
-        f.close()
+        with contextlib.closing(dumbdbm.open(_fname)) as f:
+            f[b'1'] = b'hello'
+            self.assertIn(b'1', f)
 
     def test_write_write_read(self):
         # test for bug #482460
-        f = dumbdbm.open(_fname)
-        f[b'1'] = b'hello'
-        f[b'1'] = b'hello2'
-        f.close()
-        f = dumbdbm.open(_fname)
-        self.assertEqual(f[b'1'], b'hello2')
-        f.close()
+        with contextlib.closing(dumbdbm.open(_fname)) as f:
+            f[b'1'] = b'hello'
+            f[b'1'] = b'hello2'
+        with contextlib.closing(dumbdbm.open(_fname)) as f:
+            self.assertEqual(f[b'1'], b'hello2')
 
     def test_str_read(self):
         self.init_db()
-        f = dumbdbm.open(_fname, 'r')
-        self.assertEqual(f['\u00fc'], self._dict['\u00fc'.encode('utf-8')])
+        with contextlib.closing(dumbdbm.open(_fname, 'r')) as f:
+            self.assertEqual(f['\u00fc'], self._dict['\u00fc'.encode('utf-8')])
 
     def test_str_write_contains(self):
         self.init_db()
-        f = dumbdbm.open(_fname)
-        f['\u00fc'] = b'!'
-        f['1'] = 'a'
-        f.close()
-        f = dumbdbm.open(_fname, 'r')
-        self.assertIn('\u00fc', f)
-        self.assertEqual(f['\u00fc'.encode('utf-8')],
-                         self._dict['\u00fc'.encode('utf-8')])
-        self.assertEqual(f[b'1'], b'a')
+        with contextlib.closing(dumbdbm.open(_fname)) as f:
+            f['\u00fc'] = b'!'
+            f['1'] = 'a'
+        with contextlib.closing(dumbdbm.open(_fname, 'r')) as f:
+            self.assertIn('\u00fc', f)
+            self.assertEqual(f['\u00fc'.encode('utf-8')],
+                             self._dict['\u00fc'.encode('utf-8')])
+            self.assertEqual(f[b'1'], b'a')
 
     def test_line_endings(self):
         # test for bug #1172763: dumbdbm would die if the line endings
         # weren't what was expected.
-        f = dumbdbm.open(_fname)
-        f[b'1'] = b'hello'
-        f[b'2'] = b'hello2'
-        f.close()
+        with contextlib.closing(dumbdbm.open(_fname)) as f:
+            f[b'1'] = b'hello'
+            f[b'2'] = b'hello2'
 
         # Mangle the file by changing the line separator to Windows or Unix
         with io.open(_fname + '.dir', 'rb') as file:
@@ -148,10 +140,9 @@ class DumbDBMTestCase(unittest.TestCase)
             self.assertEqual(self._dict[key], f[key])
 
     def init_db(self):
-        f = dumbdbm.open(_fname, 'w')
-        for k in self._dict:
-            f[k] = self._dict[k]
-        f.close()
+        with contextlib.closing(dumbdbm.open(_fname, 'w')) as f:
+            for k in self._dict:
+                f[k] = self._dict[k]
 
     def keys_helper(self, f):
         keys = sorted(f.keys())
@@ -165,25 +156,23 @@ class DumbDBMTestCase(unittest.TestCase)
         import random
         d = {}  # mirror the database
         for dummy in range(5):
-            f = dumbdbm.open(_fname)
-            for dummy in range(100):
-                k = random.choice('abcdefghijklm')
-                if random.random() < 0.2:
-                    if k in d:
-                        del d[k]
-                        del f[k]
-                else:
-                    v = random.choice((b'a', b'b', b'c')) * random.randrange(10000)
-                    d[k] = v
-                    f[k] = v
-                    self.assertEqual(f[k], v)
-            f.close()
+            with contextlib.closing(dumbdbm.open(_fname)) as f:
+                for dummy in range(100):
+                    k = random.choice('abcdefghijklm')
+                    if random.random() < 0.2:
+                        if k in d:
+                            del d[k]
+                            del f[k]
+                    else:
+                        v = random.choice((b'a', b'b', b'c')) * random.randrange(10000)
+                        d[k] = v
+                        f[k] = v
+                        self.assertEqual(f[k], v)
 
-            f = dumbdbm.open(_fname)
-            expected = sorted((k.encode("latin-1"), v) for k, v in d.items())
-            got = sorted(f.items())
-            self.assertEqual(expected, got)
-            f.close()
+            with contextlib.closing(dumbdbm.open(_fname)) as f:
+                expected = sorted((k.encode("latin-1"), v) for k, v in d.items())
+                got = sorted(f.items())
+                self.assertEqual(expected, got)
 
     def test_context_manager(self):
         with dumbdbm.open(_fname, 'c') as db:
diff -r d478a2a5738a Lib/test/test_mmap.py
--- a/Lib/test/test_mmap.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_mmap.py	Fri Mar 20 14:17:30 2015 +0200
@@ -268,13 +268,12 @@ class MmapTests(unittest.TestCase):
 
     def test_find_end(self):
         # test the new 'end' parameter works as expected
-        f = open(TESTFN, 'wb+')
-        data = b'one two ones'
-        n = len(data)
-        f.write(data)
-        f.flush()
-        m = mmap.mmap(f.fileno(), n)
-        f.close()
+        with open(TESTFN, 'wb+') as f:
+            data = b'one two ones'
+            n = len(data)
+            f.write(data)
+            f.flush()
+            m = mmap.mmap(f.fileno(), n)
 
         self.assertEqual(m.find(b'one'), 0)
         self.assertEqual(m.find(b'ones'), 8)
@@ -287,13 +286,12 @@ class MmapTests(unittest.TestCase):
 
     def test_rfind(self):
         # test the new 'end' parameter works as expected
-        f = open(TESTFN, 'wb+')
-        data = b'one two ones'
-        n = len(data)
-        f.write(data)
-        f.flush()
-        m = mmap.mmap(f.fileno(), n)
-        f.close()
+        with open(TESTFN, 'wb+') as f:
+            data = b'one two ones'
+            n = len(data)
+            f.write(data)
+            f.flush()
+            m = mmap.mmap(f.fileno(), n)
 
         self.assertEqual(m.rfind(b'one'), 8)
         self.assertEqual(m.rfind(b'one '), 0)
@@ -306,31 +304,24 @@ class MmapTests(unittest.TestCase):
 
     def test_double_close(self):
         # make sure a double close doesn't crash on Solaris (Bug# 665913)
-        f = open(TESTFN, 'wb+')
+        with open(TESTFN, 'wb+') as f:
+            f.write(2**16 * b'a') # Arbitrary character
 
-        f.write(2**16 * b'a') # Arbitrary character
-        f.close()
-
-        f = open(TESTFN, 'rb')
-        mf = mmap.mmap(f.fileno(), 2**16, access=mmap.ACCESS_READ)
-        mf.close()
-        mf.close()
-        f.close()
+        with open(TESTFN, 'rb') as f:
+            mf = mmap.mmap(f.fileno(), 2**16, access=mmap.ACCESS_READ)
+            mf.close()
+            mf.close()
 
     @unittest.skipUnless(hasattr(os, "stat"), "needs os.stat()")
     def test_entire_file(self):
         # test mapping of entire file by passing 0 for map length
-        f = open(TESTFN, "wb+")
+        with open(TESTFN, "wb+") as f:
+            f.write(2**16 * b'm') # Arbitrary character
 
-        f.write(2**16 * b'm') # Arbitrary character
-        f.close()
-
-        f = open(TESTFN, "rb+")
-        mf = mmap.mmap(f.fileno(), 0)
-        self.assertEqual(len(mf), 2**16, "Map size should equal file size.")
-        self.assertEqual(mf.read(2**16), 2**16 * b"m")
-        mf.close()
-        f.close()
+        with open(TESTFN, "rb+") as f, \
+             mmap.mmap(f.fileno(), 0) as mf:
+                self.assertEqual(len(mf), 2**16, "Map size should equal file size.")
+                self.assertEqual(mf.read(2**16), 2**16 * b"m")
 
     @unittest.skipUnless(hasattr(os, "stat"), "needs os.stat()")
     def test_length_0_offset(self):
@@ -358,16 +349,15 @@ class MmapTests(unittest.TestCase):
 
     def test_move(self):
         # make move works everywhere (64-bit format problem earlier)
-        f = open(TESTFN, 'wb+')
+        with open(TESTFN, 'wb+') as f:
 
-        f.write(b"ABCDEabcde") # Arbitrary character
-        f.flush()
+            f.write(b"ABCDEabcde") # Arbitrary character
+            f.flush()
 
-        mf = mmap.mmap(f.fileno(), 10)
-        mf.move(5, 0, 5)
-        self.assertEqual(mf[:], b"ABCDEABCDE", "Map move should have duplicated front 5")
-        mf.close()
-        f.close()
+            mf = mmap.mmap(f.fileno(), 10)
+            mf.move(5, 0, 5)
+            self.assertEqual(mf[:], b"ABCDEABCDE", "Map move should have duplicated front 5")
+            mf.close()
 
         # more excessive test
         data = b"0123456789"
@@ -565,10 +555,9 @@ class MmapTests(unittest.TestCase):
         mapsize = 10
         with open(TESTFN, "wb") as fp:
             fp.write(b"a"*mapsize)
-        f = open(TESTFN, "rb")
-        m = mmap.mmap(f.fileno(), mapsize, prot=mmap.PROT_READ)
-        self.assertRaises(TypeError, m.write, "foo")
-        f.close()
+        with open(TESTFN, "rb") as f:
+            m = mmap.mmap(f.fileno(), mapsize, prot=mmap.PROT_READ)
+            self.assertRaises(TypeError, m.write, "foo")
 
     def test_error(self):
         self.assertIs(mmap.error, OSError)
@@ -577,9 +566,8 @@ class MmapTests(unittest.TestCase):
         data = b"0123456789"
         with open(TESTFN, "wb") as fp:
             fp.write(b"x"*len(data))
-        f = open(TESTFN, "r+b")
-        m = mmap.mmap(f.fileno(), len(data))
-        f.close()
+        with open(TESTFN, "r+b") as f:
+            m = mmap.mmap(f.fileno(), len(data))
         # Test write_byte()
         for i in range(len(data)):
             self.assertEqual(m.tell(), i)
diff -r d478a2a5738a Lib/test/test_socket.py
--- a/Lib/test/test_socket.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_socket.py	Fri Mar 20 14:17:30 2015 +0200
@@ -686,10 +686,9 @@ class GeneralModuleTests(unittest.TestCa
         self.assertEqual(repr(s), expected)
 
     def test_weakref(self):
-        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-        p = proxy(s)
-        self.assertEqual(p.fileno(), s.fileno())
-        s.close()
+        with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
+            p = proxy(s)
+            self.assertEqual(p.fileno(), s.fileno())
         s = None
         try:
             p.fileno()
@@ -933,23 +932,20 @@ class GeneralModuleTests(unittest.TestCa
         # Testing default timeout
         # The default timeout should initially be None
         self.assertEqual(socket.getdefaulttimeout(), None)
-        s = socket.socket()
-        self.assertEqual(s.gettimeout(), None)
-        s.close()
+        with socket.socket() as s:
+            self.assertEqual(s.gettimeout(), None)
 
         # Set the default timeout to 10, and see if it propagates
         socket.setdefaulttimeout(10)
         self.assertEqual(socket.getdefaulttimeout(), 10)
-        s = socket.socket()
-        self.assertEqual(s.gettimeout(), 10)
-        s.close()
+        with socket.socket() as s:
+            self.assertEqual(s.gettimeout(), 10)
 
         # Reset the default timeout to None, and see if it propagates
         socket.setdefaulttimeout(None)
         self.assertEqual(socket.getdefaulttimeout(), None)
-        s = socket.socket()
-        self.assertEqual(s.gettimeout(), None)
-        s.close()
+        with socket.socket() as s:
+            self.assertEqual(s.gettimeout(), None)
 
         # Check that setting it to an invalid value raises ValueError
         self.assertRaises(ValueError, socket.setdefaulttimeout, -1)
@@ -1156,24 +1152,22 @@ class GeneralModuleTests(unittest.TestCa
 
     def testSendAfterClose(self):
         # testing send() after close() with timeout
-        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-        sock.settimeout(1)
-        sock.close()
+        with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
+            sock.settimeout(1)
         self.assertRaises(OSError, sock.send, b"spam")
 
     def testNewAttributes(self):
         # testing .family, .type and .protocol
 
-        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-        self.assertEqual(sock.family, socket.AF_INET)
-        if hasattr(socket, 'SOCK_CLOEXEC'):
-            self.assertIn(sock.type,
-                          (socket.SOCK_STREAM | socket.SOCK_CLOEXEC,
-                           socket.SOCK_STREAM))
-        else:
-            self.assertEqual(sock.type, socket.SOCK_STREAM)
-        self.assertEqual(sock.proto, 0)
-        sock.close()
+        with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
+            self.assertEqual(sock.family, socket.AF_INET)
+            if hasattr(socket, 'SOCK_CLOEXEC'):
+                self.assertIn(sock.type,
+                              (socket.SOCK_STREAM | socket.SOCK_CLOEXEC,
+                               socket.SOCK_STREAM))
+            else:
+                self.assertEqual(sock.type, socket.SOCK_STREAM)
+            self.assertEqual(sock.proto, 0)
 
     def test_getsockaddrarg(self):
         sock = socket.socket()
@@ -1400,10 +1394,9 @@ class GeneralModuleTests(unittest.TestCa
     def test_listen_backlog_overflow(self):
         # Issue 15989
         import _testcapi
-        srv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
-        srv.bind((HOST, 0))
-        self.assertRaises(OverflowError, srv.listen, _testcapi.INT_MAX + 1)
-        srv.close()
+        with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as srv:
+            srv.bind((HOST, 0))
+            self.assertRaises(OverflowError, srv.listen, _testcapi.INT_MAX + 1)
 
     @unittest.skipUnless(support.IPV6_ENABLED, 'IPv6 required for this test.')
     def test_flowinfo(self):
diff -r d478a2a5738a Lib/test/test_tarfile.py
--- a/Lib/test/test_tarfile.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_tarfile.py	Fri Mar 20 14:17:30 2015 +0200
@@ -127,49 +127,47 @@ class UstarReadTest(ReadTest, unittest.T
             data = fobj.read()
 
         tarinfo = self.tar.getmember("ustar/regtype")
-        fobj = self.tar.extractfile(tarinfo)
-
-        text = fobj.read()
-        fobj.seek(0)
-        self.assertEqual(0, fobj.tell(),
-                     "seek() to file's start failed")
-        fobj.seek(2048, 0)
-        self.assertEqual(2048, fobj.tell(),
-                     "seek() to absolute position failed")
-        fobj.seek(-1024, 1)
-        self.assertEqual(1024, fobj.tell(),
-                     "seek() to negative relative position failed")
-        fobj.seek(1024, 1)
-        self.assertEqual(2048, fobj.tell(),
-                     "seek() to positive relative position failed")
-        s = fobj.read(10)
-        self.assertEqual(s, data[2048:2058],
-                     "read() after seek failed")
-        fobj.seek(0, 2)
-        self.assertEqual(tarinfo.size, fobj.tell(),
-                     "seek() to file's end failed")
-        self.assertEqual(fobj.read(), b"",
-                     "read() at file's end did not return empty string")
-        fobj.seek(-tarinfo.size, 2)
-        self.assertEqual(0, fobj.tell(),
-                     "relative seek() to file's end failed")
-        fobj.seek(512)
-        s1 = fobj.readlines()
-        fobj.seek(512)
-        s2 = fobj.readlines()
-        self.assertEqual(s1, s2,
-                     "readlines() after seek failed")
-        fobj.seek(0)
-        self.assertEqual(len(fobj.readline()), fobj.tell(),
-                     "tell() after readline() failed")
-        fobj.seek(512)
-        self.assertEqual(len(fobj.readline()) + 512, fobj.tell(),
-                     "tell() after seek() and readline() failed")
-        fobj.seek(0)
-        line = fobj.readline()
-        self.assertEqual(fobj.read(), data[len(line):],
-                     "read() after readline() failed")
-        fobj.close()
+        with self.tar.extractfile(tarinfo) as fobj:
+            text = fobj.read()
+            fobj.seek(0)
+            self.assertEqual(0, fobj.tell(),
+                         "seek() to file's start failed")
+            fobj.seek(2048, 0)
+            self.assertEqual(2048, fobj.tell(),
+                         "seek() to absolute position failed")
+            fobj.seek(-1024, 1)
+            self.assertEqual(1024, fobj.tell(),
+                         "seek() to negative relative position failed")
+            fobj.seek(1024, 1)
+            self.assertEqual(2048, fobj.tell(),
+                         "seek() to positive relative position failed")
+            s = fobj.read(10)
+            self.assertEqual(s, data[2048:2058],
+                         "read() after seek failed")
+            fobj.seek(0, 2)
+            self.assertEqual(tarinfo.size, fobj.tell(),
+                         "seek() to file's end failed")
+            self.assertEqual(fobj.read(), b"",
+                         "read() at file's end did not return empty string")
+            fobj.seek(-tarinfo.size, 2)
+            self.assertEqual(0, fobj.tell(),
+                         "relative seek() to file's end failed")
+            fobj.seek(512)
+            s1 = fobj.readlines()
+            fobj.seek(512)
+            s2 = fobj.readlines()
+            self.assertEqual(s1, s2,
+                         "readlines() after seek failed")
+            fobj.seek(0)
+            self.assertEqual(len(fobj.readline()), fobj.tell(),
+                         "tell() after readline() failed")
+            fobj.seek(512)
+            self.assertEqual(len(fobj.readline()) + 512, fobj.tell(),
+                         "tell() after seek() and readline() failed")
+            fobj.seek(0)
+            line = fobj.readline()
+            self.assertEqual(fobj.read(), data[len(line):],
+                         "read() after readline() failed")
 
     def test_fileobj_text(self):
         with self.tar.extractfile("ustar/regtype") as fobj:
@@ -437,15 +435,14 @@ class MiscReadTestBase(CommonReadTest):
             fobj.seek(offset)
 
             # Test if the tarfile starts with the second member.
-            tar = tar.open(self.tarname, mode="r:", fileobj=fobj)
-            t = tar.next()
-            self.assertEqual(t.name, name)
-            # Read to the end of fileobj and test if seeking back to the
-            # beginning works.
-            tar.getmembers()
-            self.assertEqual(tar.extractfile(t).read(), data,
-                    "seek back did not work")
-            tar.close()
+            with tar.open(self.tarname, mode="r:", fileobj=fobj) as tar:
+                t = tar.next()
+                self.assertEqual(t.name, name)
+                # Read to the end of fileobj and test if seeking back to the
+                # beginning works.
+                tar.getmembers()
+                self.assertEqual(tar.extractfile(t).read(), data,
+                        "seek back did not work")
 
     def test_fail_comp(self):
         # For Gzip and Bz2 Tests: fail with a ReadError on an uncompressed file.
@@ -968,9 +965,8 @@ class WriteTestBase(TarTest):
 
     def test_fileobj_no_close(self):
         fobj = io.BytesIO()
-        tar = tarfile.open(fileobj=fobj, mode=self.mode)
-        tar.addfile(tarfile.TarInfo("foo"))
-        tar.close()
+        with tarfile.open(fileobj=fobj, mode=self.mode) as tar:
+            tar.addfile(tarfile.TarInfo("foo"))
         self.assertFalse(fobj.closed, "external fileobjs must never closed")
         # Issue #20238: Incomplete gzip output with mode="w:gz"
         data = fobj.getvalue()
@@ -1210,19 +1206,16 @@ class WriteTest(WriteTestBase, unittest.
             with open(source_file,'w') as f:
                 f.write('something\n')
             os.symlink(source_file, target_file)
-            tar = tarfile.open(temparchive,'w')
-            tar.add(source_file)
-            tar.add(target_file)
-            tar.close()
+            with tarfile.open(temparchive, 'w') as tar:
+                tar.add(source_file)
+                tar.add(target_file)
             # Let's extract it to the location which contains the symlink
-            tar = tarfile.open(temparchive,'r')
-            # this should not raise OSError: [Errno 17] File exists
-            try:
-                tar.extractall(path=tempdir)
-            except OSError:
-                self.fail("extractall failed with symlinked files")
-            finally:
-                tar.close()
+            with tarfile.open(temparchive) as tar:
+                # this should not raise OSError: [Errno 17] File exists
+                try:
+                    tar.extractall(path=tempdir)
+                except OSError:
+                    self.fail("extractall failed with symlinked files")
         finally:
             support.unlink(temparchive)
             support.rmtree(tempdir)
diff -r d478a2a5738a Lib/test/test_uu.py
--- a/Lib/test/test_uu.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_uu.py	Fri Mar 20 14:17:30 2015 +0200
@@ -172,26 +172,21 @@ class UUFileTest(unittest.TestCase):
         fin = fout = None
         try:
             support.unlink(self.tmpin)
-            fin = open(self.tmpin, 'wb')
-            fin.write(plaintext)
-            fin.close()
+            with open(self.tmpin, 'wb') as fin:
+                fin.write(plaintext)
 
-            fin = open(self.tmpin, 'rb')
-            fout = open(self.tmpout, 'wb')
-            uu.encode(fin, fout, self.tmpin, mode=0o644)
-            fin.close()
-            fout.close()
+            with open(self.tmpin, 'rb') as fin, \
+                 open(self.tmpout, 'wb') as fout:
+                uu.encode(fin, fout, self.tmpin, mode=0o644)
 
-            fout = open(self.tmpout, 'rb')
-            s = fout.read()
-            fout.close()
+            with open(self.tmpout, 'rb') as fout:
+                s = fout.read()
             self.assertEqual(s, encodedtextwrapped(0o644, self.tmpin))
 
             # in_file and out_file as filenames
             uu.encode(self.tmpin, self.tmpout, self.tmpin, mode=0o644)
-            fout = open(self.tmpout, 'rb')
-            s = fout.read()
-            fout.close()
+            with open(self.tmpout, 'rb') as fout:
+                s = fout.read()
             self.assertEqual(s, encodedtextwrapped(0o644, self.tmpin))
 
         finally:
@@ -202,17 +197,14 @@ class UUFileTest(unittest.TestCase):
         f = None
         try:
             support.unlink(self.tmpin)
-            f = open(self.tmpin, 'wb')
-            f.write(encodedtextwrapped(0o644, self.tmpout))
-            f.close()
+            with open(self.tmpin, 'wb') as f:
+                f.write(encodedtextwrapped(0o644, self.tmpout))
 
-            f = open(self.tmpin, 'rb')
-            uu.decode(f)
-            f.close()
+            with open(self.tmpin, 'rb') as f:
+                uu.decode(f)
 
-            f = open(self.tmpout, 'rb')
-            s = f.read()
-            f.close()
+            with open(self.tmpout, 'rb') as f:
+                s = f.read()
             self.assertEqual(s, plaintext)
             # XXX is there an xp way to verify the mode?
         finally:
@@ -222,15 +214,13 @@ class UUFileTest(unittest.TestCase):
         f = None
         try:
             support.unlink(self.tmpin)
-            f = open(self.tmpin, 'wb')
-            f.write(encodedtextwrapped(0o644, self.tmpout))
-            f.close()
+            with open(self.tmpin, 'wb') as f:
+                f.write(encodedtextwrapped(0o644, self.tmpout))
 
             uu.decode(self.tmpin)
 
-            f = open(self.tmpout, 'rb')
-            s = f.read()
-            f.close()
+            with open(self.tmpout, 'rb') as f:
+                s = f.read()
             self.assertEqual(s, plaintext)
         finally:
             self._kill(f)
@@ -241,13 +231,11 @@ class UUFileTest(unittest.TestCase):
         try:
             f = io.BytesIO(encodedtextwrapped(0o644, self.tmpout))
 
-            f = open(self.tmpin, 'rb')
-            uu.decode(f)
-            f.close()
+            with open(self.tmpin, 'rb') as f:
+                uu.decode(f)
 
-            f = open(self.tmpin, 'rb')
-            self.assertRaises(uu.Error, uu.decode, f)
-            f.close()
+            with open(self.tmpin, 'rb') as f:
+                self.assertRaises(uu.Error, uu.decode, f)
         finally:
             self._kill(f)
 
diff -r d478a2a5738a Lib/test/test_zipfile64.py
--- a/Lib/test/test_zipfile64.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Lib/test/test_zipfile64.py	Fri Mar 20 14:17:30 2015 +0200
@@ -32,42 +32,39 @@ class TestsWithSourceFile(unittest.TestC
         self.data = '\n'.join(line_gen).encode('ascii')
 
         # And write it to a file.
-        fp = open(TESTFN, "wb")
-        fp.write(self.data)
-        fp.close()
+        with open(TESTFN, "wb") as fp:
+            fp.write(self.data)
 
     def zipTest(self, f, compression):
         # Create the ZIP archive.
-        zipfp = zipfile.ZipFile(f, "w", compression)
+        with zipfile.ZipFile(f, "w", compression) as zipfp:
 
-        # It will contain enough copies of self.data to reach about 6GB of
-        # raw data to store.
-        filecount = 6*1024**3 // len(self.data)
+            # It will contain enough copies of self.data to reach about 6GB of
+            # raw data to store.
+            filecount = 6*1024**3 // len(self.data)
 
-        next_time = time.time() + _PRINT_WORKING_MSG_INTERVAL
-        for num in range(filecount):
-            zipfp.writestr("testfn%d" % num, self.data)
-            # Print still working message since this test can be really slow
-            if next_time <= time.time():
-                next_time = time.time() + _PRINT_WORKING_MSG_INTERVAL
-                print((
-                   '  zipTest still writing %d of %d, be patient...' %
-                   (num, filecount)), file=sys.__stdout__)
-                sys.__stdout__.flush()
-        zipfp.close()
+            next_time = time.time() + _PRINT_WORKING_MSG_INTERVAL
+            for num in range(filecount):
+                zipfp.writestr("testfn%d" % num, self.data)
+                # Print still working message since this test can be really slow
+                if next_time <= time.time():
+                    next_time = time.time() + _PRINT_WORKING_MSG_INTERVAL
+                    print((
+                       '  zipTest still writing %d of %d, be patient...' %
+                       (num, filecount)), file=sys.__stdout__)
+                    sys.__stdout__.flush()
 
         # Read the ZIP archive
-        zipfp = zipfile.ZipFile(f, "r", compression)
-        for num in range(filecount):
-            self.assertEqual(zipfp.read("testfn%d" % num), self.data)
-            # Print still working message since this test can be really slow
-            if next_time <= time.time():
-                next_time = time.time() + _PRINT_WORKING_MSG_INTERVAL
-                print((
-                   '  zipTest still reading %d of %d, be patient...' %
-                   (num, filecount)), file=sys.__stdout__)
-                sys.__stdout__.flush()
-        zipfp.close()
+        with zipfile.ZipFile(f, "r", compression) as zipfp:
+            for num in range(filecount):
+                self.assertEqual(zipfp.read("testfn%d" % num), self.data)
+                # Print still working message since this test can be really slow
+                if next_time <= time.time():
+                    next_time = time.time() + _PRINT_WORKING_MSG_INTERVAL
+                    print((
+                       '  zipTest still reading %d of %d, be patient...' %
+                       (num, filecount)), file=sys.__stdout__)
+                    sys.__stdout__.flush()
 
     def testStored(self):
         # Try the temp file first.  If we do TESTFN2 first, then it hogs
@@ -92,56 +89,50 @@ class OtherTests(unittest.TestCase):
     def testMoreThan64kFiles(self):
         # This test checks that more than 64k files can be added to an archive,
         # and that the resulting archive can be read properly by ZipFile
-        zipf = zipfile.ZipFile(TESTFN, mode="w", allowZip64=True)
-        zipf.debug = 100
-        numfiles = (1 << 16) * 3//2
-        for i in range(numfiles):
-            zipf.writestr("foo%08d" % i, "%d" % (i**3 % 57))
-        self.assertEqual(len(zipf.namelist()), numfiles)
-        zipf.close()
+        with zipfile.ZipFile(TESTFN, mode="w", allowZip64=True) as zipf:
+            zipf.debug = 100
+            numfiles = (1 << 16) * 3//2
+            for i in range(numfiles):
+                zipf.writestr("foo%08d" % i, "%d" % (i**3 % 57))
+            self.assertEqual(len(zipf.namelist()), numfiles)
 
-        zipf2 = zipfile.ZipFile(TESTFN, mode="r")
-        self.assertEqual(len(zipf2.namelist()), numfiles)
-        for i in range(numfiles):
-            content = zipf2.read("foo%08d" % i).decode('ascii')
-            self.assertEqual(content, "%d" % (i**3 % 57))
-        zipf2.close()
+        with zipfile.ZipFile(TESTFN, mode="r") as zipf2:
+            self.assertEqual(len(zipf2.namelist()), numfiles)
+            for i in range(numfiles):
+                content = zipf2.read("foo%08d" % i).decode('ascii')
+                self.assertEqual(content, "%d" % (i**3 % 57))
 
     def testMoreThan64kFilesAppend(self):
-        zipf = zipfile.ZipFile(TESTFN, mode="w", allowZip64=False)
-        zipf.debug = 100
-        numfiles = (1 << 16) - 1
-        for i in range(numfiles):
-            zipf.writestr("foo%08d" % i, "%d" % (i**3 % 57))
-        self.assertEqual(len(zipf.namelist()), numfiles)
-        with self.assertRaises(zipfile.LargeZipFile):
-            zipf.writestr("foo%08d" % numfiles, b'')
-        self.assertEqual(len(zipf.namelist()), numfiles)
-        zipf.close()
+        with zipfile.ZipFile(TESTFN, mode="w", allowZip64=False) as zipf:
+            zipf.debug = 100
+            numfiles = (1 << 16) - 1
+            for i in range(numfiles):
+                zipf.writestr("foo%08d" % i, "%d" % (i**3 % 57))
+            self.assertEqual(len(zipf.namelist()), numfiles)
+            with self.assertRaises(zipfile.LargeZipFile):
+                zipf.writestr("foo%08d" % numfiles, b'')
+            self.assertEqual(len(zipf.namelist()), numfiles)
 
-        zipf = zipfile.ZipFile(TESTFN, mode="a", allowZip64=False)
-        zipf.debug = 100
-        self.assertEqual(len(zipf.namelist()), numfiles)
-        with self.assertRaises(zipfile.LargeZipFile):
-            zipf.writestr("foo%08d" % numfiles, b'')
-        self.assertEqual(len(zipf.namelist()), numfiles)
-        zipf.close()
+        with zipfile.ZipFile(TESTFN, mode="a", allowZip64=False) as zipf:
+            zipf.debug = 100
+            self.assertEqual(len(zipf.namelist()), numfiles)
+            with self.assertRaises(zipfile.LargeZipFile):
+                zipf.writestr("foo%08d" % numfiles, b'')
+            self.assertEqual(len(zipf.namelist()), numfiles)
 
-        zipf = zipfile.ZipFile(TESTFN, mode="a", allowZip64=True)
-        zipf.debug = 100
-        self.assertEqual(len(zipf.namelist()), numfiles)
-        numfiles2 = (1 << 16) * 3//2
-        for i in range(numfiles, numfiles2):
-            zipf.writestr("foo%08d" % i, "%d" % (i**3 % 57))
-        self.assertEqual(len(zipf.namelist()), numfiles2)
-        zipf.close()
+        with zipfile.ZipFile(TESTFN, mode="a", allowZip64=True) as zipf:
+            zipf.debug = 100
+            self.assertEqual(len(zipf.namelist()), numfiles)
+            numfiles2 = (1 << 16) * 3//2
+            for i in range(numfiles, numfiles2):
+                zipf.writestr("foo%08d" % i, "%d" % (i**3 % 57))
+            self.assertEqual(len(zipf.namelist()), numfiles2)
 
-        zipf2 = zipfile.ZipFile(TESTFN, mode="r")
-        self.assertEqual(len(zipf2.namelist()), numfiles2)
-        for i in range(numfiles2):
-            content = zipf2.read("foo%08d" % i).decode('ascii')
-            self.assertEqual(content, "%d" % (i**3 % 57))
-        zipf2.close()
+        with zipfile.ZipFile(TESTFN, mode="r") as zipf2:
+            self.assertEqual(len(zipf2.namelist()), numfiles2)
+            for i in range(numfiles2):
+                content = zipf2.read("foo%08d" % i).decode('ascii')
+                self.assertEqual(content, "%d" % (i**3 % 57))
 
     def tearDown(self):
         support.unlink(TESTFN)
-------------- next part --------------
diff -r d478a2a5738a Parser/asdl_c.py
--- a/Parser/asdl_c.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Parser/asdl_c.py	Fri Mar 20 15:28:09 2015 +0200
@@ -1252,41 +1252,39 @@ def main(srcfile, dump_module=False):
         sys.exit(1)
     if INC_DIR:
         p = "%s/%s-ast.h" % (INC_DIR, mod.name)
-        f = open(p, "w")
-        f.write(auto_gen_msg)
-        f.write('#include "asdl.h"\n\n')
-        c = ChainOfVisitors(TypeDefVisitor(f),
-                            StructVisitor(f),
-                            PrototypeVisitor(f),
-                            )
-        c.visit(mod)
-        f.write("PyObject* PyAST_mod2obj(mod_ty t);\n")
-        f.write("mod_ty PyAST_obj2mod(PyObject* ast, PyArena* arena, int mode);\n")
-        f.write("int PyAST_Check(PyObject* obj);\n")
-        f.close()
+        with open(p, "w") as f:
+            f.write(auto_gen_msg)
+            f.write('#include "asdl.h"\n\n')
+            c = ChainOfVisitors(TypeDefVisitor(f),
+                                StructVisitor(f),
+                                PrototypeVisitor(f),
+                                )
+            c.visit(mod)
+            f.write("PyObject* PyAST_mod2obj(mod_ty t);\n")
+            f.write("mod_ty PyAST_obj2mod(PyObject* ast, PyArena* arena, int mode);\n")
+            f.write("int PyAST_Check(PyObject* obj);\n")
 
     if SRC_DIR:
         p = os.path.join(SRC_DIR, str(mod.name) + "-ast.c")
-        f = open(p, "w")
-        f.write(auto_gen_msg)
-        f.write('#include <stddef.h>\n')
-        f.write('\n')
-        f.write('#include "Python.h"\n')
-        f.write('#include "%s-ast.h"\n' % mod.name)
-        f.write('\n')
-        f.write("static PyTypeObject AST_type;\n")
-        v = ChainOfVisitors(
-            PyTypesDeclareVisitor(f),
-            PyTypesVisitor(f),
-            Obj2ModPrototypeVisitor(f),
-            FunctionVisitor(f),
-            ObjVisitor(f),
-            Obj2ModVisitor(f),
-            ASTModuleVisitor(f),
-            PartingShots(f),
-            )
-        v.visit(mod)
-        f.close()
+        with open(p, "w") as f:
+            f.write(auto_gen_msg)
+            f.write('#include <stddef.h>\n')
+            f.write('\n')
+            f.write('#include "Python.h"\n')
+            f.write('#include "%s-ast.h"\n' % mod.name)
+            f.write('\n')
+            f.write("static PyTypeObject AST_type;\n")
+            v = ChainOfVisitors(
+                PyTypesDeclareVisitor(f),
+                PyTypesVisitor(f),
+                Obj2ModPrototypeVisitor(f),
+                FunctionVisitor(f),
+                ObjVisitor(f),
+                Obj2ModVisitor(f),
+                ASTModuleVisitor(f),
+                PartingShots(f),
+                )
+            v.visit(mod)
 
 if __name__ == "__main__":
     import sys
diff -r d478a2a5738a Tools/scripts/fixcid.py
--- a/Tools/scripts/fixcid.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/fixcid.py	Fri Mar 20 15:28:09 2015 +0200
@@ -279,36 +279,36 @@ def addsubst(substfile):
     except IOError as msg:
         err(substfile + ': cannot read substfile: ' + str(msg) + '\n')
         sys.exit(1)
-    lineno = 0
-    while 1:
-        line = fp.readline()
-        if not line: break
-        lineno = lineno + 1
-        try:
-            i = line.index('#')
-        except ValueError:
-            i = -1          # Happens to delete trailing \n
-        words = line[:i].split()
-        if not words: continue
-        if len(words) == 3 and words[0] == 'struct':
-            words[:2] = [words[0] + ' ' + words[1]]
-        elif len(words) != 2:
-            err(substfile + '%s:%r: warning: bad line: %r' % (substfile, lineno, line))
-            continue
-        if Reverse:
-            [value, key] = words
-        else:
-            [key, value] = words
-        if value[0] == '*':
-            value = value[1:]
-        if key[0] == '*':
-            key = key[1:]
-            NotInComment[key] = value
-        if key in Dict:
-            err('%s:%r: warning: overriding: %r %r\n' % (substfile, lineno, key, value))
-            err('%s:%r: warning: previous: %r\n' % (substfile, lineno, Dict[key]))
-        Dict[key] = value
-    fp.close()
+    with fp:
+        lineno = 0
+        while 1:
+            line = fp.readline()
+            if not line: break
+            lineno = lineno + 1
+            try:
+                i = line.index('#')
+            except ValueError:
+                i = -1          # Happens to delete trailing \n
+            words = line[:i].split()
+            if not words: continue
+            if len(words) == 3 and words[0] == 'struct':
+                words[:2] = [words[0] + ' ' + words[1]]
+            elif len(words) != 2:
+                err(substfile + '%s:%r: warning: bad line: %r' % (substfile, lineno, line))
+                continue
+            if Reverse:
+                [value, key] = words
+            else:
+                [key, value] = words
+            if value[0] == '*':
+                value = value[1:]
+            if key[0] == '*':
+                key = key[1:]
+                NotInComment[key] = value
+            if key in Dict:
+                err('%s:%r: warning: overriding: %r %r\n' % (substfile, lineno, key, value))
+                err('%s:%r: warning: previous: %r\n' % (substfile, lineno, Dict[key]))
+            Dict[key] = value
 
 if __name__ == '__main__':
     main()
diff -r d478a2a5738a Tools/scripts/fixdiv.py
--- a/Tools/scripts/fixdiv.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/fixdiv.py	Fri Mar 20 15:28:09 2015 +0200
@@ -185,21 +185,21 @@ def readwarnings(warningsfile):
         sys.stderr.write("can't open: %s\n" % msg)
         return
     warnings = {}
-    while 1:
-        line = f.readline()
-        if not line:
-            break
-        m = prog.match(line)
-        if not m:
-            if line.find("division") >= 0:
-                sys.stderr.write("Warning: ignored input " + line)
-            continue
-        filename, lineno, what = m.groups()
-        list = warnings.get(filename)
-        if list is None:
-            warnings[filename] = list = []
-        list.append((int(lineno), sys.intern(what)))
-    f.close()
+    with f:
+        while 1:
+            line = f.readline()
+            if not line:
+                break
+            m = prog.match(line)
+            if not m:
+                if line.find("division") >= 0:
+                    sys.stderr.write("Warning: ignored input " + line)
+                continue
+            filename, lineno, what = m.groups()
+            list = warnings.get(filename)
+            if list is None:
+                warnings[filename] = list = []
+            list.append((int(lineno), sys.intern(what)))
     return warnings
 
 def process(filename, list):
@@ -210,84 +210,84 @@ def process(filename, list):
     except IOError as msg:
         sys.stderr.write("can't open: %s\n" % msg)
         return 1
-    print("Index:", filename)
-    f = FileContext(fp)
-    list.sort()
-    index = 0 # list[:index] has been processed, list[index:] is still to do
-    g = tokenize.generate_tokens(f.readline)
-    while 1:
-        startlineno, endlineno, slashes = lineinfo = scanline(g)
-        if startlineno is None:
-            break
-        assert startlineno <= endlineno is not None
-        orphans = []
-        while index < len(list) and list[index][0] < startlineno:
-            orphans.append(list[index])
-            index += 1
-        if orphans:
-            reportphantomwarnings(orphans, f)
-        warnings = []
-        while index < len(list) and list[index][0] <= endlineno:
-            warnings.append(list[index])
-            index += 1
-        if not slashes and not warnings:
-            pass
-        elif slashes and not warnings:
-            report(slashes, "No conclusive evidence")
-        elif warnings and not slashes:
-            reportphantomwarnings(warnings, f)
-        else:
-            if len(slashes) > 1:
-                if not multi_ok:
-                    rows = []
-                    lastrow = None
-                    for (row, col), line in slashes:
-                        if row == lastrow:
-                            continue
-                        rows.append(row)
-                        lastrow = row
-                    assert rows
-                    if len(rows) == 1:
-                        print("*** More than one / operator in line", rows[0])
+    with fp:
+        print("Index:", filename)
+        f = FileContext(fp)
+        list.sort()
+        index = 0 # list[:index] has been processed, list[index:] is still to do
+        g = tokenize.generate_tokens(f.readline)
+        while 1:
+            startlineno, endlineno, slashes = lineinfo = scanline(g)
+            if startlineno is None:
+                break
+            assert startlineno <= endlineno is not None
+            orphans = []
+            while index < len(list) and list[index][0] < startlineno:
+                orphans.append(list[index])
+                index += 1
+            if orphans:
+                reportphantomwarnings(orphans, f)
+            warnings = []
+            while index < len(list) and list[index][0] <= endlineno:
+                warnings.append(list[index])
+                index += 1
+            if not slashes and not warnings:
+                pass
+            elif slashes and not warnings:
+                report(slashes, "No conclusive evidence")
+            elif warnings and not slashes:
+                reportphantomwarnings(warnings, f)
+            else:
+                if len(slashes) > 1:
+                    if not multi_ok:
+                        rows = []
+                        lastrow = None
+                        for (row, col), line in slashes:
+                            if row == lastrow:
+                                continue
+                            rows.append(row)
+                            lastrow = row
+                        assert rows
+                        if len(rows) == 1:
+                            print("*** More than one / operator in line", rows[0])
+                        else:
+                            print("*** More than one / operator per statement", end=' ')
+                            print("in lines %d-%d" % (rows[0], rows[-1]))
+                intlong = []
+                floatcomplex = []
+                bad = []
+                for lineno, what in warnings:
+                    if what in ("int", "long"):
+                        intlong.append(what)
+                    elif what in ("float", "complex"):
+                        floatcomplex.append(what)
                     else:
-                        print("*** More than one / operator per statement", end=' ')
-                        print("in lines %d-%d" % (rows[0], rows[-1]))
-            intlong = []
-            floatcomplex = []
-            bad = []
-            for lineno, what in warnings:
-                if what in ("int", "long"):
-                    intlong.append(what)
-                elif what in ("float", "complex"):
-                    floatcomplex.append(what)
-                else:
-                    bad.append(what)
-            lastrow = None
-            for (row, col), line in slashes:
-                if row == lastrow:
-                    continue
-                lastrow = row
-                line = chop(line)
-                if line[col:col+1] != "/":
-                    print("*** Can't find the / operator in line %d:" % row)
-                    print("*", line)
-                    continue
-                if bad:
-                    print("*** Bad warning for line %d:" % row, bad)
-                    print("*", line)
-                elif intlong and not floatcomplex:
-                    print("%dc%d" % (row, row))
-                    print("<", line)
-                    print("---")
-                    print(">", line[:col] + "/" + line[col:])
-                elif floatcomplex and not intlong:
-                    print("True division / operator at line %d:" % row)
-                    print("=", line)
-                elif intlong and floatcomplex:
-                    print("*** Ambiguous / operator (%s, %s) at line %d:" % (
-                        "|".join(intlong), "|".join(floatcomplex), row))
-                    print("?", line)
-    fp.close()
+                        bad.append(what)
+                lastrow = None
+                for (row, col), line in slashes:
+                    if row == lastrow:
+                        continue
+                    lastrow = row
+                    line = chop(line)
+                    if line[col:col+1] != "/":
+                        print("*** Can't find the / operator in line %d:" % row)
+                        print("*", line)
+                        continue
+                    if bad:
+                        print("*** Bad warning for line %d:" % row, bad)
+                        print("*", line)
+                    elif intlong and not floatcomplex:
+                        print("%dc%d" % (row, row))
+                        print("<", line)
+                        print("---")
+                        print(">", line[:col] + "/" + line[col:])
+                    elif floatcomplex and not intlong:
+                        print("True division / operator at line %d:" % row)
+                        print("=", line)
+                    elif intlong and floatcomplex:
+                        print("*** Ambiguous / operator (%s, %s) at line %d:" %
+                            ("|".join(intlong), "|".join(floatcomplex), row))
+                        print("?", line)
 
 def reportphantomwarnings(warnings, f):
     blocks = []
diff -r d478a2a5738a Tools/scripts/fixheader.py
--- a/Tools/scripts/fixheader.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/fixheader.py	Fri Mar 20 15:28:09 2015 +0200
@@ -15,8 +15,8 @@ def process(filename):
     except IOError as msg:
         sys.stderr.write('%s: can\'t open: %s\n' % (filename, str(msg)))
         return
-    data = f.read()
-    f.close()
+    with f:
+        data = f.read()
     if data[:2] != '/*':
         sys.stderr.write('%s does not begin with C comment\n' % filename)
         return
@@ -31,19 +31,19 @@ def process(filename):
         if ord(c)<=0x80 and c.isalnum():
             magic = magic + c.upper()
         else: magic = magic + '_'
-    sys.stdout = f
-    print('#ifndef', magic)
-    print('#define', magic)
-    print('#ifdef __cplusplus')
-    print('extern "C" {')
-    print('#endif')
-    print()
-    f.write(data)
-    print()
-    print('#ifdef __cplusplus')
-    print('}')
-    print('#endif')
-    print('#endif /*', '!'+magic, '*/')
+    with f:
+        print('#ifndef', magic, file=f)
+        print('#define', magic, file=f)
+        print('#ifdef __cplusplus', file=f)
+        print('extern "C" {', file=f)
+        print('#endif', file=f)
+        print(file=f)
+        f.write(data)
+        print(file=f)
+        print('#ifdef __cplusplus', file=f)
+        print('}', file=f)
+        print('#endif', file=f)
+        print('#endif /*', '!'+magic, '*/', file=f)
 
 if __name__ == '__main__':
     main()
diff -r d478a2a5738a Tools/scripts/gprof2html.py
--- a/Tools/scripts/gprof2html.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/gprof2html.py	Fri Mar 20 15:28:09 2015 +0200
@@ -28,14 +28,7 @@ def add_escapes(filename):
         for line in fp:
             yield html.escape(line)
 
-
-def main():
-    filename = "gprof.out"
-    if sys.argv[1:]:
-        filename = sys.argv[1]
-    outputfilename = filename + ".html"
-    input = add_escapes(filename)
-    output = open(outputfilename, "w")
+def gprof2html(input, output, filename):
     output.write(header % filename)
     for line in input:
         output.write(line)
@@ -78,7 +71,16 @@ def main():
                 part = '<a href="#call:%s">%s</a>' % (part, part)
             output.write(part)
     output.write(trailer)
-    output.close()
+
+
+def main():
+    filename = "gprof.out"
+    if sys.argv[1:]:
+        filename = sys.argv[1]
+    outputfilename = filename + ".html"
+    input = add_escapes(filename)
+    with open(outputfilename, "w") as output:
+        gprof2html(input, output, filename)
     webbrowser.open("file:" + os.path.abspath(outputfilename))
 
 if __name__ == '__main__':
diff -r d478a2a5738a Tools/scripts/texi2html.py
--- a/Tools/scripts/texi2html.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/texi2html.py	Fri Mar 20 15:28:09 2015 +0200
@@ -118,11 +118,10 @@ class HTMLNode:
             self.lines.append(line)
 
     def flush(self):
-        fp = open(self.dirname + '/' + makefile(self.name), 'w')
-        fp.write(self.prologue)
-        fp.write(self.text)
-        fp.write(self.epilogue)
-        fp.close()
+        with open(self.dirname + '/' + makefile(self.name), 'w') as fp:
+            fp.write(self.prologue)
+            fp.write(self.text)
+            fp.write(self.epilogue)
 
     def link(self, label, nodename, rel=None, rev=None):
         if nodename:
@@ -558,14 +557,14 @@ class TexinfoParser:
         except IOError as msg:
             print('*** Can\'t open include file', repr(file))
             return
-        print('!'*self.debugging, '--> file', repr(file))
-        save_done = self.done
-        save_skip = self.skip
-        save_stack = self.stack
-        self.includedepth = self.includedepth + 1
-        self.parserest(fp, 0)
-        self.includedepth = self.includedepth - 1
-        fp.close()
+        with fp:
+            print('!'*self.debugging, '--> file', repr(file))
+            save_done = self.done
+            save_skip = self.skip
+            save_stack = self.stack
+            self.includedepth = self.includedepth + 1
+            self.parserest(fp, 0)
+            self.includedepth = self.includedepth - 1
         self.done = save_done
         self.skip = save_skip
         self.stack = save_stack
@@ -1770,78 +1769,75 @@ class HTMLHelp:
 
         # PROJECT FILE
         try:
-            fp = open(projectfile,'w')
-            print('[OPTIONS]', file=fp)
-            print('Auto Index=Yes', file=fp)
-            print('Binary TOC=No', file=fp)
-            print('Binary Index=Yes', file=fp)
-            print('Compatibility=1.1', file=fp)
-            print('Compiled file=' + resultfile + '', file=fp)
-            print('Contents file=' + contentfile + '', file=fp)
-            print('Default topic=' + defaulttopic + '', file=fp)
-            print('Error log file=ErrorLog.log', file=fp)
-            print('Index file=' + indexfile + '', file=fp)
-            print('Title=' + title + '', file=fp)
-            print('Display compile progress=Yes', file=fp)
-            print('Full-text search=Yes', file=fp)
-            print('Default window=main', file=fp)
-            print('', file=fp)
-            print('[WINDOWS]', file=fp)
-            print('main=,"' + contentfile + '","' + indexfile
-                        + '","","",,,,,0x23520,222,0x1046,[10,10,780,560],'
-                        '0xB0000,,,,,,0', file=fp)
-            print('', file=fp)
-            print('[FILES]', file=fp)
-            print('', file=fp)
-            self.dumpfiles(fp)
-            fp.close()
+            with open(projectfile, 'w') as fp:
+                print('[OPTIONS]', file=fp)
+                print('Auto Index=Yes', file=fp)
+                print('Binary TOC=No', file=fp)
+                print('Binary Index=Yes', file=fp)
+                print('Compatibility=1.1', file=fp)
+                print('Compiled file=' + resultfile + '', file=fp)
+                print('Contents file=' + contentfile + '', file=fp)
+                print('Default topic=' + defaulttopic + '', file=fp)
+                print('Error log file=ErrorLog.log', file=fp)
+                print('Index file=' + indexfile + '', file=fp)
+                print('Title=' + title + '', file=fp)
+                print('Display compile progress=Yes', file=fp)
+                print('Full-text search=Yes', file=fp)
+                print('Default window=main', file=fp)
+                print('', file=fp)
+                print('[WINDOWS]', file=fp)
+                print('main=,"' + contentfile + '","' + indexfile
+                            + '","","",,,,,0x23520,222,0x1046,[10,10,780,560],'
+                            '0xB0000,,,,,,0', file=fp)
+                print('', file=fp)
+                print('[FILES]', file=fp)
+                print('', file=fp)
+                self.dumpfiles(fp)
         except IOError as msg:
             print(projectfile, ':', msg)
             sys.exit(1)
 
         # CONTENT FILE
         try:
-            fp = open(contentfile,'w')
-            print('<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">', file=fp)
-            print('<!-- This file defines the table of contents -->', file=fp)
-            print('<HTML>', file=fp)
-            print('<HEAD>', file=fp)
-            print('<meta name="GENERATOR"'
-                        'content="Microsoft&reg; HTML Help Workshop 4.1">', file=fp)
-            print('<!-- Sitemap 1.0 -->', file=fp)
-            print('</HEAD>', file=fp)
-            print('<BODY>', file=fp)
-            print('   <OBJECT type="text/site properties">', file=fp)
-            print('     <param name="Window Styles" value="0x800025">', file=fp)
-            print('     <param name="comment" value="title:">', file=fp)
-            print('     <param name="comment" value="base:">', file=fp)
-            print('   </OBJECT>', file=fp)
-            self.dumpnodes(fp)
-            print('</BODY>', file=fp)
-            print('</HTML>', file=fp)
-            fp.close()
+            with open(contentfile, 'w') as fp:
+                print('<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">', file=fp)
+                print('<!-- This file defines the table of contents -->', file=fp)
+                print('<HTML>', file=fp)
+                print('<HEAD>', file=fp)
+                print('<meta name="GENERATOR" '
+                      'content="Microsoft&reg; HTML Help Workshop 4.1">', file=fp)
+                print('<!-- Sitemap 1.0 -->', file=fp)
+                print('</HEAD>', file=fp)
+                print('<BODY>', file=fp)
+                print('   <OBJECT type="text/site properties">', file=fp)
+                print('     <param name="Window Styles" value="0x800025">', file=fp)
+                print('     <param name="comment" value="title:">', file=fp)
+                print('     <param name="comment" value="base:">', file=fp)
+                print('   </OBJECT>', file=fp)
+                self.dumpnodes(fp)
+                print('</BODY>', file=fp)
+                print('</HTML>', file=fp)
         except IOError as msg:
             print(contentfile, ':', msg)
             sys.exit(1)
 
         # INDEX FILE
         try:
-            fp = open(indexfile  ,'w')
-            print('<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">', file=fp)
-            print('<!-- This file defines the index -->', file=fp)
-            print('<HTML>', file=fp)
-            print('<HEAD>', file=fp)
-            print('<meta name="GENERATOR"'
-                        'content="Microsoft&reg; HTML Help Workshop 4.1">', file=fp)
-            print('<!-- Sitemap 1.0 -->', file=fp)
-            print('</HEAD>', file=fp)
-            print('<BODY>', file=fp)
-            print('<OBJECT type="text/site properties">', file=fp)
-            print('</OBJECT>', file=fp)
-            self.dumpindex(fp)
-            print('</BODY>', file=fp)
-            print('</HTML>', file=fp)
-            fp.close()
+            with open(indexfile, 'w') as fp:
+                print('<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">', file=fp)
+                print('<!-- This file defines the index -->', file=fp)
+                print('<HTML>', file=fp)
+                print('<HEAD>', file=fp)
+                print('<meta name="GENERATOR" '
+                      'content="Microsoft&reg; HTML Help Workshop 4.1">', file=fp)
+                print('<!-- Sitemap 1.0 -->', file=fp)
+                print('</HEAD>', file=fp)
+                print('<BODY>', file=fp)
+                print('<OBJECT type="text/site properties">', file=fp)
+                print('</OBJECT>', file=fp)
+                self.dumpindex(fp)
+                print('</BODY>', file=fp)
+                print('</HTML>', file=fp)
         except IOError as msg:
             print(indexfile  , ':', msg)
             sys.exit(1)
@@ -2064,8 +2060,8 @@ def test():
         print(file, ':', msg)
         sys.exit(1)
 
-    parser.parse(fp)
-    fp.close()
+    with fp:
+        parser.parse(fp)
     parser.report()
 
     htmlhelp.finalize()
-------------- next part --------------
diff -r d478a2a5738a Tools/demo/markov.py
--- a/Tools/demo/markov.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/demo/markov.py	Fri Mar 20 12:55:59 2015 +0200
@@ -79,8 +79,8 @@ def test():
             else:
                 f = open(filename, 'r')
             if debug: print('processing', filename, '...')
-            text = f.read()
-            f.close()
+            with f:
+                text = f.read()
             paralist = text.split('\n\n')
             for para in paralist:
                 if debug > 1: print('feeding ...')
diff -r d478a2a5738a Tools/demo/rpython.py
--- a/Tools/demo/rpython.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/demo/rpython.py	Fri Mar 20 12:55:59 2015 +0200
@@ -22,17 +22,16 @@ def main():
         port = int(port[i+1:])
         host = host[:i]
     command = ' '.join(sys.argv[2:])
-    s = socket(AF_INET, SOCK_STREAM)
-    s.connect((host, port))
-    s.send(command.encode())
-    s.shutdown(SHUT_WR)
-    reply = b''
-    while True:
-        data = s.recv(BUFSIZE)
-        if not data:
-            break
-        reply += data
-    print(reply.decode(), end=' ')
-    s.close()
+    with socket(AF_INET, SOCK_STREAM) as s:
+        s.connect((host, port))
+        s.send(command.encode())
+        s.shutdown(SHUT_WR)
+        reply = b''
+        while True:
+            data = s.recv(BUFSIZE)
+            if not data:
+                break
+            reply += data
+        print(reply.decode(), end=' ')
 
 main()
diff -r d478a2a5738a Tools/demo/rpythond.py
--- a/Tools/demo/rpythond.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/demo/rpythond.py	Fri Mar 20 12:55:59 2015 +0200
@@ -26,16 +26,16 @@ def main():
     s.listen(1)
     while True:
         conn, (remotehost, remoteport) = s.accept()
-        print('connection from', remotehost, remoteport)
-        request = b''
-        while 1:
-            data = conn.recv(BUFSIZE)
-            if not data:
-                break
-            request += data
-        reply = execute(request.decode())
-        conn.send(reply.encode())
-        conn.close()
+        with conn:
+            print('connection from', remotehost, remoteport)
+            request = b''
+            while 1:
+                data = conn.recv(BUFSIZE)
+                if not data:
+                    break
+                request += data
+            reply = execute(request.decode())
+            conn.send(reply.encode())
 
 def execute(request):
     stdout = sys.stdout
diff -r d478a2a5738a Tools/freeze/checkextensions_win32.py
--- a/Tools/freeze/checkextensions_win32.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/freeze/checkextensions_win32.py	Fri Mar 20 12:55:59 2015 +0200
@@ -130,7 +130,8 @@ def parse_dsp(dsp):
     ret = []
     dsp_path, dsp_name = os.path.split(dsp)
     try:
-        lines = open(dsp, "r").readlines()
+        with open(dsp, "r") as fp:
+            lines = fp.readlines()
     except IOError as msg:
         sys.stderr.write("%s: %s\n" % (dsp, msg))
         return None
diff -r d478a2a5738a Tools/freeze/freeze.py
--- a/Tools/freeze/freeze.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/freeze/freeze.py	Fri Mar 20 12:55:59 2015 +0200
@@ -144,7 +144,8 @@ def main():
         # last option can not be "-i", so this ensures "pos+1" is in range!
         if sys.argv[pos] == '-i':
             try:
-                options = open(sys.argv[pos+1]).read().split()
+                with open(sys.argv[pos+1]) as infp:
+                    options = infp.read().split()
             except IOError as why:
                 usage("File name '%s' specified with the -i option "
                       "can not be read - %s" % (sys.argv[pos+1], why) )
diff -r d478a2a5738a Tools/i18n/msgfmt.py
--- a/Tools/i18n/msgfmt.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/i18n/msgfmt.py	Fri Mar 20 12:55:59 2015 +0200
@@ -109,7 +109,8 @@ def make(filename, outfile):
         outfile = os.path.splitext(infile)[0] + '.mo'
 
     try:
-        lines = open(infile, 'rb').readlines()
+        with open(infile, 'rb') as f:
+            lines = f.readlines()
     except IOError as msg:
         print(msg, file=sys.stderr)
         sys.exit(1)
@@ -199,7 +200,8 @@ def make(filename, outfile):
     output = generate()
 
     try:
-        open(outfile,"wb").write(output)
+        with open(outfile,"wb") as f:
+            f.write(output)
     except IOError as msg:
         print(msg, file=sys.stderr)
 
diff -r d478a2a5738a Tools/i18n/pygettext.py
--- a/Tools/i18n/pygettext.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/i18n/pygettext.py	Fri Mar 20 12:55:59 2015 +0200
@@ -595,9 +595,8 @@ def main():
     # initialize list of strings to exclude
     if options.excludefilename:
         try:
-            fp = open(options.excludefilename)
-            options.toexclude = fp.readlines()
-            fp.close()
+            with open(options.excludefilename) as fp:
+                options.toexclude = fp.readlines()
         except IOError:
             print(_(
                 "Can't read --exclude-file: %s") % options.excludefilename, file=sys.stderr)
diff -r d478a2a5738a Tools/pybench/pybench.py
--- a/Tools/pybench/pybench.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/pybench/pybench.py	Fri Mar 20 12:55:59 2015 +0200
@@ -893,10 +893,9 @@ python pybench.py -s p25.pybench -c p21.
 
         if compare_to:
             try:
-                f = open(compare_to,'rb')
-                bench = pickle.load(f)
-                bench.name = compare_to
-                f.close()
+                with open(compare_to,'rb') as f:
+                    bench = pickle.load(f)
+                    bench.name = compare_to
                 compare_to = bench
             except IOError as reason:
                 print('* Error opening/reading file %s: %s' % (
@@ -906,10 +905,9 @@ python pybench.py -s p25.pybench -c p21.
 
         if show_bench:
             try:
-                f = open(show_bench,'rb')
-                bench = pickle.load(f)
-                bench.name = show_bench
-                f.close()
+                with open(show_bench,'rb') as f:
+                    bench = pickle.load(f)
+                    bench.name = show_bench
                 bench.print_header()
                 if compare_to:
                     bench.print_comparison(compare_to,
@@ -960,10 +958,9 @@ python pybench.py -s p25.pybench -c p21.
 
         if reportfile:
             try:
-                f = open(reportfile,'wb')
-                bench.name = reportfile
-                pickle.dump(bench,f)
-                f.close()
+                with open(reportfile,'wb') as f:
+                    bench.name = reportfile
+                    pickle.dump(bench,f)
             except IOError as reason:
                 print('* Error opening/writing reportfile %s: %s' % (
                     reportfile,
diff -r d478a2a5738a Tools/scripts/cleanfuture.py
--- a/Tools/scripts/cleanfuture.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/cleanfuture.py	Fri Mar 20 12:55:59 2015 +0200
@@ -96,11 +96,11 @@ def check(file):
         errprint("%r: I/O Error: %s" % (file, str(msg)))
         return
 
-    ff = FutureFinder(f, file)
-    changed = ff.run()
-    if changed:
-        ff.gettherest()
-    f.close()
+    with f:
+        ff = FutureFinder(f, file)
+        changed = ff.run()
+        if changed:
+            ff.gettherest()
     if changed:
         if verbose:
             print("changed.")
@@ -122,9 +122,8 @@ def check(file):
             os.rename(file, bak)
             if verbose:
                 print("renamed", file, "to", bak)
-            g = open(file, "w")
-            ff.write(g)
-            g.close()
+            with open(file, "w") as g:
+                ff.write(g)
             if verbose:
                 print("wrote new", file)
     else:
diff -r d478a2a5738a Tools/scripts/combinerefs.py
--- a/Tools/scripts/combinerefs.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/combinerefs.py	Fri Mar 20 12:55:59 2015 +0200
@@ -85,9 +85,7 @@ def read(fileiter, pat, whilematch):
         else:
             break
 
-def combine(fname):
-    f = open(fname)
-
+def combinefile(f):
     fi = iter(f)
 
     for line in read(fi, re.compile(r'^Remaining objects:$'), False):
@@ -121,8 +119,11 @@ def combine(fname):
             print('[%s->%s]' % (addr2rc[addr], rc), end=' ')
         print(guts, addr2guts[addr])
 
-    f.close()
     print("%d objects before, %d after" % (before, after))
 
+def combine(fname):
+    with open(fname) as f:
+        combinefile(f)
+
 if __name__ == '__main__':
     combine(sys.argv[1])
diff -r d478a2a5738a Tools/scripts/dutree.py
--- a/Tools/scripts/dutree.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/dutree.py	Fri Mar 20 12:55:59 2015 +0200
@@ -4,18 +4,18 @@
 import os, sys, errno
 
 def main():
-    p = os.popen('du ' + ' '.join(sys.argv[1:]), 'r')
     total, d = None, {}
-    for line in p.readlines():
-        i = 0
-        while line[i] in '0123456789': i = i+1
-        size = eval(line[:i])
-        while line[i] in ' \t': i = i+1
-        filename = line[i:-1]
-        comps = filename.split('/')
-        if comps[0] == '': comps[0] = '/'
-        if comps[len(comps)-1] == '': del comps[len(comps)-1]
-        total, d = store(size, comps, total, d)
+    with os.popen('du ' + ' '.join(sys.argv[1:])) as p:
+        for line in p:
+            i = 0
+            while line[i] in '0123456789': i = i+1
+            size = eval(line[:i])
+            while line[i] in ' \t': i = i+1
+            filename = line[i:-1]
+            comps = filename.split('/')
+            if comps[0] == '': comps[0] = '/'
+            if comps[len(comps)-1] == '': del comps[len(comps)-1]
+            total, d = store(size, comps, total, d)
     try:
         display(total, d)
     except IOError as e:
diff -r d478a2a5738a Tools/scripts/eptags.py
--- a/Tools/scripts/eptags.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/eptags.py	Fri Mar 20 12:55:59 2015 +0200
@@ -28,29 +28,30 @@ def treat_file(filename, outfp):
     except:
         sys.stderr.write('Cannot open %s\n'%filename)
         return
-    charno = 0
-    lineno = 0
-    tags = []
-    size = 0
-    while 1:
-        line = fp.readline()
-        if not line:
-            break
-        lineno = lineno + 1
-        m = matcher.search(line)
-        if m:
-            tag = m.group(0) + '\177%d,%d\n' % (lineno, charno)
-            tags.append(tag)
-            size = size + len(tag)
-        charno = charno + len(line)
+    with fp:
+        charno = 0
+        lineno = 0
+        tags = []
+        size = 0
+        while 1:
+            line = fp.readline()
+            if not line:
+                break
+            lineno = lineno + 1
+            m = matcher.search(line)
+            if m:
+                tag = m.group(0) + '\177%d,%d\n' % (lineno, charno)
+                tags.append(tag)
+                size = size + len(tag)
+            charno = charno + len(line)
     outfp.write('\f\n%s,%d\n' % (filename,size))
     for tag in tags:
         outfp.write(tag)
 
 def main():
-    outfp = open('TAGS', 'w')
-    for filename in sys.argv[1:]:
-        treat_file(filename, outfp)
+    with open('TAGS', 'w') as outfp:
+        for filename in sys.argv[1:]:
+            treat_file(filename, outfp)
 
 if __name__=="__main__":
     main()
diff -r d478a2a5738a Tools/scripts/finddiv.py
--- a/Tools/scripts/finddiv.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/finddiv.py	Fri Mar 20 12:55:59 2015 +0200
@@ -55,17 +55,17 @@ def process(filename, listnames):
     except IOError as msg:
         sys.stderr.write("Can't open: %s\n" % msg)
         return 1
-    g = tokenize.generate_tokens(fp.readline)
-    lastrow = None
-    for type, token, (row, col), end, line in g:
-        if token in ("/", "/="):
-            if listnames:
-                print(filename)
-                break
-            if row != lastrow:
-                lastrow = row
-                print("%s:%d:%s" % (filename, row, line), end=' ')
-    fp.close()
+    with fp:
+        g = tokenize.generate_tokens(fp.readline)
+        lastrow = None
+        for type, token, (row, col), end, line in g:
+            if token in ("/", "/="):
+                if listnames:
+                    print(filename)
+                    break
+                if row != lastrow:
+                    lastrow = row
+                    print("%s:%d:%s" % (filename, row, line), end=' ')
 
 def processdir(dir, listnames):
     try:
diff -r d478a2a5738a Tools/scripts/fixnotice.py
--- a/Tools/scripts/fixnotice.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/fixnotice.py	Fri Mar 20 12:55:59 2015 +0200
@@ -73,22 +73,19 @@ def main():
         elif opt == '--dry-run':
             DRYRUN = 1
         elif opt == '--oldnotice':
-            fp = open(arg)
-            OLD_NOTICE = fp.read()
-            fp.close()
+            with open(arg) as fp:
+                OLD_NOTICE = fp.read()
         elif opt == '--newnotice':
-            fp = open(arg)
-            NEW_NOTICE = fp.read()
-            fp.close()
+            with open(arg) as fp:
+                NEW_NOTICE = fp.read()
 
     for arg in args:
         process(arg)
 
 
 def process(file):
-    f = open(file)
-    data = f.read()
-    f.close()
+    with open(file) as f:
+        data = f.read()
     i = data.find(OLD_NOTICE)
     if i < 0:
         if VERBOSE:
@@ -102,9 +99,8 @@ def process(file):
     data = data[:i] + NEW_NOTICE + data[i+len(OLD_NOTICE):]
     new = file + ".new"
     backup = file + ".bak"
-    f = open(new, "w")
-    f.write(data)
-    f.close()
+    with open(new, "w") as f:
+        f.write(data)
     os.rename(file, backup)
     os.rename(new, file)
 
diff -r d478a2a5738a Tools/scripts/fixps.py
--- a/Tools/scripts/fixps.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/fixps.py	Fri Mar 20 12:55:59 2015 +0200
@@ -14,20 +14,18 @@ def main():
         except IOError as msg:
             print(filename, ': can\'t open :', msg)
             continue
-        line = f.readline()
-        if not re.match('^#! */usr/local/bin/python', line):
-            print(filename, ': not a /usr/local/bin/python script')
-            f.close()
-            continue
-        rest = f.read()
-        f.close()
+        with f:
+            line = f.readline()
+            if not re.match('^#! */usr/local/bin/python', line):
+                print(filename, ': not a /usr/local/bin/python script')
+                continue
+            rest = f.read()
         line = re.sub('/usr/local/bin/python',
                       '/usr/bin/env python', line)
         print(filename, ':', repr(line))
-        f = open(filename, "w")
-        f.write(line)
-        f.write(rest)
-        f.close()
+        with open(filename, "w") as f:
+            f.write(line)
+            f.write(rest)
 
 if __name__ == '__main__':
     main()
diff -r d478a2a5738a Tools/scripts/get-remote-certificate.py
--- a/Tools/scripts/get-remote-certificate.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/get-remote-certificate.py	Fri Mar 20 12:55:59 2015 +0200
@@ -29,9 +29,8 @@ def fetch_server_certificate (host, port
             return None
         else:
             tn = tempfile.mktemp()
-            fp = open(tn, "wb")
-            fp.write(m.group(1) + b"\n")
-            fp.close()
+            with open(tn, "wb") as fp:
+                fp.write(m.group(1) + b"\n")
             try:
                 tn2 = (outfile or tempfile.mktemp())
                 status, output = subproc(r'openssl x509 -in "%s" -out "%s"' %
@@ -39,9 +38,8 @@ def fetch_server_certificate (host, port
                 if status != 0:
                     raise RuntimeError('OpenSSL x509 failed with status %s and '
                                        'output: %r' % (status, output))
-                fp = open(tn2, 'rb')
-                data = fp.read()
-                fp.close()
+                with open(tn2, 'rb') as fp:
+                    data = fp.read()
                 os.unlink(tn2)
                 return data
             finally:
@@ -49,9 +47,8 @@ def fetch_server_certificate (host, port
 
     if sys.platform.startswith("win"):
         tfile = tempfile.mktemp()
-        fp = open(tfile, "w")
-        fp.write("quit\n")
-        fp.close()
+        with open(tfile, "w") as fp:
+            fp.write("quit\n")
         try:
             status, output = subproc(
                 'openssl s_client -connect "%s:%s" -showcerts < "%s"' %
diff -r d478a2a5738a Tools/scripts/h2py.py
--- a/Tools/scripts/h2py.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/h2py.py	Fri Mar 20 12:55:59 2015 +0200
@@ -69,23 +69,21 @@ def main():
             sys.stdout.write('# Generated by h2py from stdin\n')
             process(sys.stdin, sys.stdout)
         else:
-            fp = open(filename, 'r')
-            outfile = os.path.basename(filename)
-            i = outfile.rfind('.')
-            if i > 0: outfile = outfile[:i]
-            modname = outfile.upper()
-            outfile = modname + '.py'
-            outfp = open(outfile, 'w')
-            outfp.write('# Generated by h2py from %s\n' % filename)
-            filedict = {}
-            for dir in searchdirs:
-                if filename[:len(dir)] == dir:
-                    filedict[filename[len(dir)+1:]] = None  # no '/' trailing
-                    importable[filename[len(dir)+1:]] = modname
-                    break
-            process(fp, outfp)
-            outfp.close()
-            fp.close()
+            with open(filename) as fp:
+                outfile = os.path.basename(filename)
+                i = outfile.rfind('.')
+                if i > 0: outfile = outfile[:i]
+                modname = outfile.upper()
+                outfile = modname + '.py'
+                with open(outfile, 'w') as outfp:
+                    outfp.write('# Generated by h2py from %s\n' % filename)
+                    filedict = {}
+                    for dir in searchdirs:
+                        if filename[:len(dir)] == dir:
+                            filedict[filename[len(dir)+1:]] = None  # no '/' trailing
+                            importable[filename[len(dir)+1:]] = modname
+                            break
+                    process(fp, outfp)
 
 def pytify(body):
     # replace ignored patterns by spaces
@@ -161,9 +159,10 @@ def process(fp, outfp, env = {}):
                     except IOError:
                         pass
                 if inclfp:
-                    outfp.write(
-                            '\n# Included from %s\n' % filename)
-                    process(inclfp, outfp, env)
+                    with inclfp:
+                        outfp.write(
+                                '\n# Included from %s\n' % filename)
+                        process(inclfp, outfp, env)
                 else:
                     sys.stderr.write('Warning - could not find file %s\n' %
                                      filename)
diff -r d478a2a5738a Tools/scripts/ifdef.py
--- a/Tools/scripts/ifdef.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/ifdef.py	Fri Mar 20 12:55:59 2015 +0200
@@ -45,9 +45,8 @@ def main():
         if filename == '-':
             process(sys.stdin, sys.stdout)
         else:
-            f = open(filename, 'r')
-            process(f, sys.stdout)
-            f.close()
+            with open(filename) as f:
+                process(f, sys.stdout)
 
 def process(fpi, fpo):
     keywords = ('if', 'ifdef', 'ifndef', 'else', 'endif')
diff -r d478a2a5738a Tools/scripts/md5sum.py
--- a/Tools/scripts/md5sum.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/md5sum.py	Fri Mar 20 12:55:59 2015 +0200
@@ -47,10 +47,10 @@ def printsum(filename, out=sys.stdout):
     except IOError as msg:
         sys.stderr.write('%s: Can\'t open: %s\n' % (filename, msg))
         return 1
-    if fnfilter:
-        filename = fnfilter(filename)
-    sts = printsumfp(fp, filename, out)
-    fp.close()
+    with fp:
+        if fnfilter:
+            filename = fnfilter(filename)
+        sts = printsumfp(fp, filename, out)
     return sts
 
 def printsumfp(fp, filename, out=sys.stdout):
diff -r d478a2a5738a Tools/scripts/mkreal.py
--- a/Tools/scripts/mkreal.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/mkreal.py	Fri Mar 20 12:55:59 2015 +0200
@@ -18,14 +18,13 @@ def mkrealfile(name):
     st = os.stat(name) # Get the mode
     mode = S_IMODE(st[ST_MODE])
     linkto = os.readlink(name) # Make sure again it's a symlink
-    f_in = open(name, 'r') # This ensures it's a file
-    os.unlink(name)
-    f_out = open(name, 'w')
-    while 1:
-        buf = f_in.read(BUFSIZE)
-        if not buf: break
-        f_out.write(buf)
-    del f_out # Flush data to disk before changing mode
+    with open(name, 'rb') as f_in: # This ensures it's a file
+        os.unlink(name)
+        with open(name, 'wb') as f_out:
+            while 1:
+                buf = f_in.read(BUFSIZE)
+                if not buf: break
+                f_out.write(buf)
     os.chmod(name, mode)
 
 def mkrealdir(name):
diff -r d478a2a5738a Tools/scripts/nm2def.py
--- a/Tools/scripts/nm2def.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/nm2def.py	Fri Mar 20 12:55:59 2015 +0200
@@ -42,7 +42,8 @@ NM = 'nm -p -g %s'                      
 
 def symbols(lib=PYTHONLIB,types=('T','C','D')):
 
-    lines = os.popen(NM % lib).readlines()
+    with os.popen(NM % lib) as pipe:
+        lines = pipe.readlines()
     lines = [s.strip() for s in lines]
     symbols = {}
     for line in lines:
@@ -97,7 +98,7 @@ def main():
     exports = export_list(s)
     f = sys.stdout # open('PC/python_nt.def','w')
     f.write(DEF_TEMPLATE % (exports))
-    f.close()
+    # f.close()
 
 if __name__ == '__main__':
     main()
diff -r d478a2a5738a Tools/scripts/objgraph.py
--- a/Tools/scripts/objgraph.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/objgraph.py	Fri Mar 20 12:55:59 2015 +0200
@@ -180,7 +180,8 @@ def main():
         if filename == '-':
             readinput(sys.stdin)
         else:
-            readinput(open(filename, 'r'))
+            with open(filename) as f:
+                readinput(f)
     #
     warndups()
     #
diff -r d478a2a5738a Tools/scripts/parseentities.py
--- a/Tools/scripts/parseentities.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/parseentities.py	Fri Mar 20 12:55:59 2015 +0200
@@ -50,13 +50,15 @@ def writefile(f,defs):
 
 if __name__ == '__main__':
     if len(sys.argv) > 1:
-        infile = open(sys.argv[1])
+        with open(sys.argv[1]) as infile:
+            text = infile.read()
     else:
-        infile = sys.stdin
+        text = sys.stdin.read()
+
+    defs = parse(text)
+
     if len(sys.argv) > 2:
-        outfile = open(sys.argv[2],'w')
+        with open(sys.argv[2],'w') as outfile:
+            writefile(outfile, defs)
     else:
-        outfile = sys.stdout
-    text = infile.read()
-    defs = parse(text)
-    writefile(outfile,defs)
+        writefile(sys.stdout, defs)
diff -r d478a2a5738a Tools/scripts/pathfix.py
--- a/Tools/scripts/pathfix.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/pathfix.py	Fri Mar 20 12:55:59 2015 +0200
@@ -97,29 +97,27 @@ def fix(filename):
     except IOError as msg:
         err('%s: cannot open: %r\n' % (filename, msg))
         return 1
-    line = f.readline()
-    fixed = fixline(line)
-    if line == fixed:
-        rep(filename+': no change\n')
-        f.close()
-        return
-    head, tail = os.path.split(filename)
-    tempname = os.path.join(head, '@' + tail)
-    try:
-        g = open(tempname, 'wb')
-    except IOError as msg:
-        f.close()
-        err('%s: cannot create: %r\n' % (tempname, msg))
-        return 1
-    rep(filename + ': updating\n')
-    g.write(fixed)
-    BUFSIZE = 8*1024
-    while 1:
-        buf = f.read(BUFSIZE)
-        if not buf: break
-        g.write(buf)
-    g.close()
-    f.close()
+    with f:
+        line = f.readline()
+        fixed = fixline(line)
+        if line == fixed:
+            rep(filename+': no change\n')
+            return
+        head, tail = os.path.split(filename)
+        tempname = os.path.join(head, '@' + tail)
+        try:
+            g = open(tempname, 'wb')
+        except IOError as msg:
+            err('%s: cannot create: %r\n' % (tempname, msg))
+            return 1
+        with g:
+            rep(filename + ': updating\n')
+            g.write(fixed)
+            BUFSIZE = 8*1024
+            while 1:
+                buf = f.read(BUFSIZE)
+                if not buf: break
+                g.write(buf)
 
     # Finishing touch -- move files
 
diff -r d478a2a5738a Tools/scripts/pdeps.py
--- a/Tools/scripts/pdeps.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/pdeps.py	Fri Mar 20 12:55:59 2015 +0200
@@ -64,29 +64,28 @@ m_from = re.compile('^[ \t]*import[ \t]+
 # Collect data from one file
 #
 def process(filename, table):
-    fp = open(filename, 'r')
-    mod = os.path.basename(filename)
-    if mod[-3:] == '.py':
-        mod = mod[:-3]
-    table[mod] = list = []
-    while 1:
-        line = fp.readline()
-        if not line: break
-        while line[-1:] == '\\':
-            nextline = fp.readline()
-            if not nextline: break
-            line = line[:-1] + nextline
-        m_found = m_import.match(line) or m_from.match(line)
-        if m_found:
-            (a, b), (a1, b1) = m_found.regs[:2]
-        else: continue
-        words = line[a1:b1].split(',')
-        # print '#', line, words
-        for word in words:
-            word = word.strip()
-            if word not in list:
-                list.append(word)
-    fp.close()
+    with open(filename) as fp:
+        mod = os.path.basename(filename)
+        if mod[-3:] == '.py':
+            mod = mod[:-3]
+        table[mod] = list = []
+        while 1:
+            line = fp.readline()
+            if not line: break
+            while line[-1:] == '\\':
+                nextline = fp.readline()
+                if not nextline: break
+                line = line[:-1] + nextline
+            m_found = m_import.match(line) or m_from.match(line)
+            if m_found:
+                (a, b), (a1, b1) = m_found.regs[:2]
+            else: continue
+            words = line[a1:b1].split(',')
+            # print '#', line, words
+            for word in words:
+                word = word.strip()
+                if word not in list:
+                    list.append(word)
 
 
 # Compute closure (this is in fact totally general)
diff -r d478a2a5738a Tools/scripts/ptags.py
--- a/Tools/scripts/ptags.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/ptags.py	Fri Mar 20 12:55:59 2015 +0200
@@ -19,9 +19,9 @@ def main():
     for filename in args:
         treat_file(filename)
     if tags:
-        fp = open('tags', 'w')
-        tags.sort()
-        for s in tags: fp.write(s)
+        with open('tags', 'w') as fp:
+            tags.sort()
+            for s in tags: fp.write(s)
 
 
 expr = '^[ \t]*(def|class)[ \t]+([a-zA-Z0-9_]+)[ \t]*[:\(]'
@@ -33,21 +33,22 @@ def treat_file(filename):
     except:
         sys.stderr.write('Cannot open %s\n' % filename)
         return
-    base = os.path.basename(filename)
-    if base[-3:] == '.py':
-        base = base[:-3]
-    s = base + '\t' + filename + '\t' + '1\n'
-    tags.append(s)
-    while 1:
-        line = fp.readline()
-        if not line:
-            break
-        m = matcher.match(line)
-        if m:
-            content = m.group(0)
-            name = m.group(2)
-            s = name + '\t' + filename + '\t/^' + content + '/\n'
-            tags.append(s)
+    with fp:
+        base = os.path.basename(filename)
+        if base[-3:] == '.py':
+            base = base[:-3]
+        s = base + '\t' + filename + '\t' + '1\n'
+        tags.append(s)
+        while 1:
+            line = fp.readline()
+            if not line:
+                break
+            m = matcher.match(line)
+            if m:
+                content = m.group(0)
+                name = m.group(2)
+                s = name + '\t' + filename + '\t/^' + content + '/\n'
+                tags.append(s)
 
 if __name__ == '__main__':
     main()
diff -r d478a2a5738a Tools/scripts/rgrep.py
--- a/Tools/scripts/rgrep.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/rgrep.py	Fri Mar 20 12:55:59 2015 +0200
@@ -30,29 +30,30 @@ def main():
         f = open(filename)
     except IOError as msg:
         usage("can't open %r: %s" % (filename, msg), 1)
-    f.seek(0, 2)
-    pos = f.tell()
-    leftover = None
-    while pos > 0:
-        size = min(pos, bufsize)
-        pos = pos - size
-        f.seek(pos)
-        buffer = f.read(size)
-        lines = buffer.split("\n")
-        del buffer
-        if leftover is None:
-            if not lines[-1]:
-                del lines[-1]
-        else:
-            lines[-1] = lines[-1] + leftover
-        if pos > 0:
-            leftover = lines[0]
-            del lines[0]
-        else:
-            leftover = None
-        for line in reversed(lines):
-            if prog.search(line):
-                print(line)
+    with f:
+        f.seek(0, 2)
+        pos = f.tell()
+        leftover = None
+        while pos > 0:
+            size = min(pos, bufsize)
+            pos = pos - size
+            f.seek(pos)
+            buffer = f.read(size)
+            lines = buffer.split("\n")
+            del buffer
+            if leftover is None:
+                if not lines[-1]:
+                    del lines[-1]
+            else:
+                lines[-1] = lines[-1] + leftover
+            if pos > 0:
+                leftover = lines[0]
+                del lines[0]
+            else:
+                leftover = None
+            for line in reversed(lines):
+                if prog.search(line):
+                    print(line)
 
 
 def usage(msg, code=2):
diff -r d478a2a5738a Tools/scripts/svneol.py
--- a/Tools/scripts/svneol.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/scripts/svneol.py	Fri Mar 20 12:55:59 2015 +0200
@@ -39,7 +39,8 @@ import subprocess
 def propfiles(root, fn):
     default = os.path.join(root, ".svn", "props", fn + ".svn-work")
     try:
-        format = int(open(os.path.join(root, ".svn", "format")).read().strip())
+        with open(os.path.join(root, ".svn", "format")) as f:
+            format = int(f.read().strip())
     except IOError:
         return []
     if format in (8, 9):
@@ -60,27 +61,27 @@ def proplist(root, fn):
             # no properties file: not under version control,
             # or no properties set
             continue
-        while True:
-            # key-value pairs, of the form
-            # K <length>
-            # <keyname>NL
-            # V length
-            # <value>NL
-            # END
-            line = f.readline()
-            if line.startswith("END"):
-                break
-            assert line.startswith("K ")
-            L = int(line.split()[1])
-            key = f.read(L)
-            result.append(key)
-            f.readline()
-            line = f.readline()
-            assert line.startswith("V ")
-            L = int(line.split()[1])
-            value = f.read(L)
-            f.readline()
-        f.close()
+        with f:
+            while True:
+                # key-value pairs, of the form
+                # K <length>
+                # <keyname>NL
+                # V length
+                # <value>NL
+                # END
+                line = f.readline()
+                if line.startswith("END"):
+                    break
+                assert line.startswith("K ")
+                L = int(line.split()[1])
+                key = f.read(L)
+                result.append(key)
+                f.readline()
+                line = f.readline()
+                assert line.startswith("V ")
+                L = int(line.split()[1])
+                value = f.read(L)
+                f.readline()
     return result
 
 
diff -r d478a2a5738a Tools/unicode/gencjkcodecs.py
--- a/Tools/unicode/gencjkcodecs.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/unicode/gencjkcodecs.py	Fri Mar 20 12:55:59 2015 +0200
@@ -61,7 +61,8 @@ def gencodecs(prefix):
                                        encoding=enc.lower(),
                                        owner=loc)
             codecpath = os.path.join(prefix, enc + '.py')
-            open(codecpath, 'w').write(code)
+            with open(codecpath, 'w') as f:
+                f.write(code)
 
 if __name__ == '__main__':
     import sys
diff -r d478a2a5738a Tools/unicode/gencodec.py
--- a/Tools/unicode/gencodec.py	Fri Mar 20 10:37:34 2015 +0100
+++ b/Tools/unicode/gencodec.py	Fri Mar 20 12:55:59 2015 +0200
@@ -72,9 +72,8 @@ def parsecodes(codes, len=len, range=ran
 
 def readmap(filename):
 
-    f = open(filename,'r')
-    lines = f.readlines()
-    f.close()
+    with open(filename) as f:
+        lines = f.readlines()
     enc2uni = {}
     identity = []
     unmapped = list(range(256))
@@ -359,18 +358,16 @@ encoding_table = codecs.charmap_build(de
 def pymap(name,map,pyfile,encodingname,comments=1):
 
     code = codegen(name,map,encodingname,comments)
-    f = open(pyfile,'w')
-    f.write(code)
-    f.close()
+    with open(pyfile,'w') as f:
+        f.write(code)
 
 def marshalmap(name,map,marshalfile):
 
     d = {}
     for e,(u,c) in map.items():
         d[e] = (u,c)
-    f = open(marshalfile,'wb')
-    marshal.dump(d,f)
-    f.close()
+    with open(marshalfile,'wb') as f:
+        marshal.dump(d,f)
 
 def convertdir(dir, dirprefix='', nameprefix='', comments=1):
 
@@ -411,8 +408,8 @@ def rewritepythondir(dir, dirprefix='', 
         print('converting %s to %s' % (mapname,
                                        dirprefix + codefile))
         try:
-            map = marshal.load(open(os.path.join(dir,mapname),
-                               'rb'))
+            with open(os.path.join(dir, mapname), 'rb') as f:
+                map = marshal.load(f)
             if not map:
                 print('* map is empty; skipping')
             else:

From report at bugs.python.org  Fri Mar 20 14:44:21 2015
From: report at bugs.python.org (Martin Teichmann)
Date: Fri, 20 Mar 2015 13:44:21 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
Message-ID: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>


New submission from Martin Teichmann:

When a new class is initialized with __init__ in a metaclass,
the __class__ cell of the class about to be initialized is not
set yet, meaning that super() does not work.

This is a known but fixable problem. The attached patch moves
the initialization of __class__ from the end of __build_class__
into type.__new__. This avoids the proliferation of methods
which don't have the __class__ cell set.

----------
components: Interpreter Core
files: patch
messages: 238672
nosy: Martin.Teichmann
priority: normal
severity: normal
status: open
title: During metaclass.__init__, super() of the constructed class does not work
versions: Python 3.5
Added file: http://bugs.python.org/file38604/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23722>
_______________________________________

From report at bugs.python.org  Fri Mar 20 14:54:25 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 20 Mar 2015 13:54:25 +0000
Subject: [issue23699] Add a macro to ease writing rich comparisons
In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za>
Message-ID: <1426859665.76.0.70220169545.issue23699@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

Attaching another patch:

- Leave _decimal alone per maintainer's wishes
- Fixes issues pointed out in the review
- Use Py_RICHCOMPARE also in _tkinter
- More improvements in the other affected modules

----------
Added file: http://bugs.python.org/file38605/0002-Use-Py_RICHCOMPARE-in-rich-comparisons.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23699>
_______________________________________

From report at bugs.python.org  Fri Mar 20 14:56:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 13:56:02 +0000
Subject: [issue23699] Add a macro to ease writing rich comparisons
In-Reply-To: <1426855410.95.0.297635930032.issue23699@psf.upfronthosting.co.za>
Message-ID: <7358191.Rcgm0z3cSD@raxxla>


Serhiy Storchaka added the comment:

> I think it should fall in the same category as Py_RETURN_TRUE or
> Py_RETURN_NONE. Sure, it's easy to reimplement, but a lot of extensions
> need it; why should everyone need to write the same code in a dozen
> different ways? I specifically want this usable in third-party code.

The interface of Py_RETURN_TRUE is simple and unambiguous. Py_RICHCOMPARE is 
more complex and unobvious. One question is about the order of arguments 
(opcode as first argument looks better on my taste). Other question is about 
return value. Should it be an integer 0 or 1, Python object.

Stefan ask good question about implementation. A sequence of ifs can be less 
efficient than one switch.

Py_RETURN_TRUE and Py_RETURN_NONE are used hundreds times in CPython code and 
in any large extension (and can be used more). But the use case of 
Py_RICHCOMPARE is pretty limited.

> The implementation of Py_RICHCOMPARE is in the first patch.

Ah, I see the code in text patch, but on Rietveld it isn't visible. Perhaps 
Rietveld doesn't show some parts from the second patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23699>
_______________________________________

From report at bugs.python.org  Fri Mar 20 15:07:11 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Fri, 20 Mar 2015 14:07:11 +0000
Subject: [issue23529] Limit decompressed data when reading from LZMAFile and
 BZ2File
In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za>
Message-ID: <1426860431.01.0.550966816866.issue23529@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

The patch has a huge block replacement in the gzip.py module starting at GzipFile.write, which makes it large and hard to identify changes. Could that be ameliorated or is it too much work right now?

----------
nosy: +wolma

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23529>
_______________________________________

From report at bugs.python.org  Fri Mar 20 15:07:42 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 20 Mar 2015 14:07:42 +0000
Subject: [issue22181] os.urandom() should use Linux 3.17 getrandom() syscall
In-Reply-To: <1407713563.4.0.264701036097.issue22181@psf.upfronthosting.co.za>
Message-ID: <1426860462.72.0.734132903373.issue22181@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

> New changeset 4491bdb6527b by Victor Stinner in branch 'default':
> Issue #22181: The availability of the getrandom() is now checked in configure,
> https://hg.python.org/cpython/rev/4491bdb6527b

You forgot to run aclocal, which resulted in PKG_PROG_PKG_CONFIG not being expanded in configure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22181>
_______________________________________

From report at bugs.python.org  Fri Mar 20 15:13:16 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 14:13:16 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426860796.55.0.753033559131.issue23700@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> csv.reader(fileobj) returns the generator created by fileobj.__iter__, but no reference to it is kept so the object gets destroyed right afterwards. This closes the generator and because it uses yield from also the contained subgenerator, which is the file itself.

Yes, there are no references to to the generator, created by fileobj.__iter__, but there are references to fileobj itself and to the file fileobj.file. I still don't understand why the file is closed. This looks as a bug.

Committed existing fix only to make buildbots green.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 15:13:44 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 14:13:44 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <20150320141340.16932.50638@psf.io>


Roundup Robot added the comment:

New changeset a90ec6b96af2 by Serhiy Storchaka in branch '3.4':
Issue #23700: NamedTemporaryFile iterator closed underlied file object in
https://hg.python.org/cpython/rev/a90ec6b96af2

New changeset e639750ecd92 by Serhiy Storchaka in branch 'default':
Issue #23700: NamedTemporaryFile iterator closed underlied file object in
https://hg.python.org/cpython/rev/e639750ecd92

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 15:15:45 2015
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 20 Mar 2015 14:15:45 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
In-Reply-To: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>
Message-ID: <1426860945.83.0.437941039189.issue23720@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Fri Mar 20 15:26:18 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 20 Mar 2015 14:26:18 +0000
Subject: [issue23717] strptime() with year-weekday pair can produce invalid
 data
In-Reply-To: <1426850371.96.0.168304833853.issue23717@psf.upfronthosting.co.za>
Message-ID: <1426861578.63.0.00557307376086.issue23717@psf.upfronthosting.co.za>


Skip Montanaro added the comment:

I don't think this is a bug. From the 2.7.9 docs:

The default values used to fill in any missing data when more accurate values cannot be inferred are (1900, 1, 1, 0, 0, 0, 0, 1, -1).

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23717>
_______________________________________

From report at bugs.python.org  Fri Mar 20 15:30:29 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Mar 2015 14:30:29 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
In-Reply-To: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>
Message-ID: <1426861829.88.0.301291691525.issue23720@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Amaury is right. In your case you could keep track of the Vectors in the Device object and invalidate them when the Device is destroyed (using e.g. a WeakSet). Or Vector could delegate its destruction to Device, e.g.:


class Device(object):        
    destroyed = False

    def __del__(self):
        self.destroyed = True

    def _dealloc_vector(self, v):
        if not self.destroyed:
            ...


class Vector(object):        
    def __init__(self, device):
        self.device = device
        
    def __del__(self):
        self.device._dealloc_vector(self)

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Fri Mar 20 15:33:30 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 20 Mar 2015 14:33:30 +0000
Subject: [issue23699] Add a macro to ease writing rich comparisons
In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za>
Message-ID: <1426862010.16.0.447674039696.issue23699@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

Making it a function might help with the following issues:
- series of comparisons and PyBool_FromLong is less efficient than switch and Py_RETURN_*. But it would add a function call.
- it might be too complex for a macro

Do you think that would help?

As for the signature, I would like this to mirror richcmpfunc and PyObject_RichCompareBool. And returning PyObjexct*, not 0/1, is an important part of reducing boilerplate; in cases where 0/1 would be helpful you can easily work with cmp-style -1/0/1 values before using this to convert them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23699>
_______________________________________

From report at bugs.python.org  Fri Mar 20 15:36:45 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 14:36:45 +0000
Subject: [issue23717] strptime() with year-weekday pair can produce invalid
 data
In-Reply-To: <1426850371.96.0.168304833853.issue23717@psf.upfronthosting.co.za>
Message-ID: <1426862205.14.0.000556867647518.issue23717@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Actually you can got invalid data for any date.

>>> time.strptime('2015 3 20', '%Y %m %d')
time.struct_time(tm_year=2015, tm_mon=3, tm_mday=20, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=4, tm_yday=79, tm_isdst=-1)
>>> time.strptime('2015 3 20 0', '%Y %m %d %w')
time.struct_time(tm_year=2015, tm_mon=3, tm_mday=20, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=79, tm_isdst=-1)

All date values are known, the problem is that they contradict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23717>
_______________________________________

From report at bugs.python.org  Fri Mar 20 15:38:16 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Fri, 20 Mar 2015 14:38:16 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426862296.08.0.221969878889.issue23700@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

so let's look at this step-by-step (and I hope I fully understood this myself):

- calling fileobj.__iter__ creates a generator because the method uses yield from

- that generator does not get assigned to any reference so it will be garbage-collected

- when the generator is garbage-collected, the subgenerator specified to the rigth of the yield from is finalized (that is PEP380-mandated behavior) and, in this case, that is iter(self.file)

- for an io module-based fileobject, iter(f) is f and finalizing it means that its close method will be called

So this is not about the file object getting garbage-collected, it is about it getting closed.

Since PEP380 explicitly mentions that problem with yield from and a shared subiterator, I don't think you can call it a bug, but I think it is very problematic behavior as illustrated by this issue because client code is supposed to know whether a particular generator uses yield from or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 15:38:46 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 20 Mar 2015 14:38:46 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1426862326.87.0.720691550906.issue2211@psf.upfronthosting.co.za>


Demian Brecht added the comment:

> idmap was removed in 14b65de9b798, translate was removed in 99027c2b3fd2 when their became unnecessary.

I'd venture to say they slipped through the cracks. Following the deprecation procedure here would be favourable IMHO as to give users a sufficient heads up that their will be a breakage upcoming, however unlikely that the parameter is actually in use in practice. There's nothing lost by marking it deprecated and removing it for 3.6(+).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Fri Mar 20 15:41:55 2015
From: report at bugs.python.org (Paul Moore)
Date: Fri, 20 Mar 2015 14:41:55 +0000
Subject: [issue23657] Don't do isinstance checks in zipapp
In-Reply-To: <1426258210.85.0.503105299924.issue23657@psf.upfronthosting.co.za>
Message-ID: <1426862515.93.0.57229812223.issue23657@psf.upfronthosting.co.za>


Paul Moore added the comment:

Updated patch. Added the requested test and a set of tests for the command line API. This also highlighted a bug in the command line --info option, which is also fixed.

Coverage now:

Name          Stmts   Miss  Cover   Missing
-------------------------------------------
test_zipapp     254     12    95%   252-257, 263-268
zipapp          102      2    98%   30, 192
-------------------------------------------
TOTAL           356     14    96%

Remaining misses are Unix-only tests (this was run on Windows) and the __main__ block.

----------
Added file: http://bugs.python.org/file38606/duck_typed_zipapp.v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23657>
_______________________________________

From report at bugs.python.org  Fri Mar 20 15:44:29 2015
From: report at bugs.python.org (J. Morton)
Date: Fri, 20 Mar 2015 14:44:29 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426862669.43.0.218394124755.issue22516@psf.upfronthosting.co.za>


J. Morton added the comment:

First, thanks for the comments - perhaps there's hope. 

But from the viewpoint of a typical user (who does not care about what goes on in the background), some of what has been said does not match the realities of development in a corporate environment.

1 ? Anyone who is working on a Windows box controlled by an overly anal-retentive IM department (i.e. no admin rights) will not be able to install Python.  Either make the ?just for me? option unrestricted or remove it entirely.   Time wasted trying to install Python when it can?t be done does endear Python to new users and comes across as being rather unprofessional.  I haven?t gone to the web page lately, but as an absolute minimum the page for the ?just for me? option needs to state that Admin rights are needed.
2 ? Anyone forced to use Windows and is NOT a total python fanatic will NEVER go to the pain of building it.  In the corporate world - on any platform - this approach is generally unrealistic given the other tools already out there (not worth the time/effort/pain involved, especially if the boss is breathing down your neck about the project schedule).  And even if they want to, they may not be able to build/install it ? no tools, as per point 1.
3 ? I do not see the comments (in msg238567) ?require a second MSI that is configured to not ask for administrative privileges? and ?hosting twice of many files? as having much validity.   To better serve the community a better approach is to REPLACE the pointlessly restrictive ?admin rights?  installer with an unrestricted version (it?s how I got Firefox on this machine) ? hence only one set of files.  This set should be, as much as possible, completely independent of everything else on the system (disk space is cheap, networks are fast and the file sizes are, relatively speaking, small).

4 - I haven't yet tried the "MSI' workaround (in msg238560) so I don't know if it will work on my restricted system.  If it does, the workaround should appear on the web page.

Finally (as pure self-interest) I'd like a version compatible with Eclipse/PyDev.

I do appreciate and encourage what you guys are doing and also understand the realities of what you do.  But my viewpoint is, that to have closed this issue without properly addressing the basic problem reminds me of an ostrich with its head in the sand.

----------
status: closed -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Fri Mar 20 15:56:28 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 14:56:28 +0000
Subject: [issue23681] Have -b warn when directly comparing ints and bytes
In-Reply-To: <1426525530.11.0.0814957947674.issue23681@psf.upfronthosting.co.za>
Message-ID: <20150320145625.16932.14009@psf.io>


Roundup Robot added the comment:

New changeset 104c55bc2276 by Serhiy Storchaka in branch '3.4':
Issue #23681: Fixed Python 2 to 3 poring bugs.
https://hg.python.org/cpython/rev/104c55bc2276

New changeset 817f1f47824c by Serhiy Storchaka in branch 'default':
Issue #23681: Fixed Python 2 to 3 poring bugs.
https://hg.python.org/cpython/rev/817f1f47824c

New changeset 68e9cf0ae93d by Serhiy Storchaka in branch 'default':
Issue #23681: The -b option now affects comparisons of bytes with int.
https://hg.python.org/cpython/rev/68e9cf0ae93d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23681>
_______________________________________

From report at bugs.python.org  Fri Mar 20 15:59:46 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 14:59:46 +0000
Subject: [issue23681] Have -b warn when directly comparing ints and bytes
In-Reply-To: <1426525530.11.0.0814957947674.issue23681@psf.upfronthosting.co.za>
Message-ID: <1426863586.0.0.396044908626.issue23681@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23681>
_______________________________________

From report at bugs.python.org  Fri Mar 20 16:03:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 15:03:32 +0000
Subject: [issue22181] os.urandom() should use Linux 3.17 getrandom() syscall
In-Reply-To: <1407713563.4.0.264701036097.issue22181@psf.upfronthosting.co.za>
Message-ID: <20150320150320.30042.51675@psf.io>


Roundup Robot added the comment:

New changeset b8ceb071159f by Victor Stinner in branch 'default':
Issue #22181: Run "aclocal; autoconf; autoheader" to regenerate configure
https://hg.python.org/cpython/rev/b8ceb071159f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22181>
_______________________________________

From report at bugs.python.org  Fri Mar 20 16:07:23 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Mar 2015 15:07:23 +0000
Subject: [issue11726] clarify that linecache only works on files that can be
 decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <1426864043.08.0.366181726349.issue11726@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think that that patch that Victor committed is incorrect, and that Thomas's patch is closer to correct.  People *do* use linecache with files other than python source files, and as far as I can see we are not going to stop supporting that.  Given the original docs the intent clearly was that the interface be general, not python-file-specific.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11726>
_______________________________________

From report at bugs.python.org  Fri Mar 20 16:20:13 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Mar 2015 15:20:13 +0000
Subject: [issue11726] clarify that linecache only works on files that can be
 decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <1426864813.63.0.468124360796.issue11726@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, on further investigation I guess it wasn't intended to be so general :)  But I still think we should make a nod to the reality that it can be used on other text files.  I'll re-close the issue but I may add a sentence to the docs.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11726>
_______________________________________

From report at bugs.python.org  Fri Mar 20 16:22:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 15:22:08 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426864928.55.0.93029263627.issue23700@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your explanation Wolfgang! Now it is clear to me. The issue is that the generator calls the close() method of the subgenerator, but if the subgenerator is a file, the close() method closes (surprise!) the file. Two different protocols use the same method.

Interesting, how many similar bugs was introduced by blindly replacing "for/yield" with "yield from"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 16:22:24 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 15:22:24 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426864944.4.0.658651149147.issue23700@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 16:32:45 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 15:32:45 +0000
Subject: [issue11726] clarify that linecache only works on files that can be
 decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <20150320153242.24254.20201@psf.io>


Roundup Robot added the comment:

New changeset ceb14ecc1942 by R David Murray in branch '3.4':
#11726: Make linecache docs reflect that all files are treated the same.
https://hg.python.org/cpython/rev/ceb14ecc1942

New changeset 1a5c72f9ff53 by R David Murray in branch 'default':
Merge: #11726: Make linecache docs reflect that all files are treated the same.
https://hg.python.org/cpython/rev/1a5c72f9ff53

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11726>
_______________________________________

From report at bugs.python.org  Fri Mar 20 16:34:39 2015
From: report at bugs.python.org (Mark Mikofski)
Date: Fri, 20 Mar 2015 15:34:39 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426865679.97.0.0276928651311.issue22516@psf.upfronthosting.co.za>


Mark Mikofski added the comment:

1. J morton: just install Anacondahttp://continuum.io/downloads

2. I will take a look at the msi and see if I can accommodate both installs in the same installer

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Fri Mar 20 16:45:45 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 20 Mar 2015 15:45:45 +0000
Subject: [issue22958] Constructors of weakref mapping classes don't accept
 "self" and "dict" keyword arguments
In-Reply-To: <1417104803.61.0.896440563309.issue22958@psf.upfronthosting.co.za>
Message-ID: <1426866345.39.0.947302802349.issue22958@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

lgtm

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22958>
_______________________________________

From report at bugs.python.org  Fri Mar 20 16:46:48 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 20 Mar 2015 15:46:48 +0000
Subject: [issue23717] strptime() with year-weekday pair can produce invalid
 data
In-Reply-To: <1426862205.14.0.000556867647518.issue23717@psf.upfronthosting.co.za>
Message-ID: <CANc-5Uyz3xqST-=dKy6gYJzbXJVg=W3d6qVY9keghY8moHJQ+A@mail.gmail.com>


Skip Montanaro added the comment:

>>>> time.strptime('2015 3 20 0', '%Y %m %d %w')
> time.struct_time(tm_year=2015, tm_mon=3, tm_mday=20, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=79, tm_isdst=-1)
>
> All date values are known, the problem is that they contradict.

Garbage in, garbage out. :-) Clearly today is not Sunday. I not sure
there is a correct answer in the face of contradictory inputs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23717>
_______________________________________

From report at bugs.python.org  Fri Mar 20 16:50:54 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 20 Mar 2015 15:50:54 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426866654.91.0.766640719408.issue22516@psf.upfronthosting.co.za>


Steve Dower added the comment:

@Mark: You can't - MSIs have a single flag indicating whether they should elevate or not. That's why I moved the 3.5 installer to a new format. Unfortunately, since we're in a transitional state, admin privileges are necessary to install the new CRT version, but the per-user is a true per-user for 3.5 (and when the new CRT is already installed via normal Windows Updates, you won't even be prompted).

@J. Morton: I appreciate the suggestion of only supporting per-user installs, and I'm heading towards that position. It won't be changing for 2.7 or 3.4 at this stage, but I do plan to discuss exactly this issue soon with the core team and figure out what we're actually trying to achieve with our installers.

I would never suggest that somebody build Python themselves unless they are a distribution, and ISTM that even on Windows, 99% of Python users should be getting a distribution rather than the python.org installers. (Which makes the python.org installers fairly redundant, hence my plans to discuss what they should be trying to achieve.)

The /a "install" is not a real installation, and though it "works", it isn't necessarily supported. (It's actually a transformation of the MSI file to separate the files to install from the installer - you should see the MSI file get considerably smaller after you run that command.) In particular, the py.exe launcher is not going to work, and many other programs that automatically detect Python will also fail.

Not sure what you mean about "compatible with PyDev/Eclipse". It's their responsibility to be compatible with Python (and I say this as the lead developer of Python Tools for Visual Studio, where we've pulled all sorts of tricks to remain compatible with Python :) ).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Fri Mar 20 16:51:42 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Mar 2015 15:51:42 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426866702.16.0.558224613586.issue23700@psf.upfronthosting.co.za>


R. David Murray added the comment:

Isn't there some discussion somewhere that if iter(x) returns x you probably have buggy code?  Maybe it is io that is broken, design-wise.  I think there was another issue related to iter(file) recently...someone surprised by the fact that you can't iterate a file twice without reopening it...the source of that problem is similar.  Not that it necessarily soluble, but it is certainly *interesting* :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 17:02:55 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Mar 2015 16:02:55 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426866702.16.0.558224613586.issue23700@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbXvadTkr0v6tyXypKw=RmcWp=3+ahNb+T6XxVFgKmdiQ@mail.gmail.com>


STINNER Victor added the comment:

> Isn't there some discussion somewhere that if iter(x) returns x you probably have buggy code?

I agree that the issue comes from TextIOWrapper.__iter__(),
BufferedReader.__iter__() and FileIO.__iter__() returns simply return
self *and* have a close method. The issue is not "yield from".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 17:13:38 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Fri, 20 Mar 2015 16:13:38 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426868018.97.0.21995057526.issue23700@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

You are probably right that the io classes are broken.

>From https://docs.python.org/3/library/stdtypes.html#iterator-types:

Once an iterator?s __next__() method raises StopIteration, it must continue to do so on subsequent calls. Implementations that do not obey this property are deemed broken.


One consequence of __iter__ returning self is that the above is not guaranteed:

>>> with open('somefile', 'w') as f:
	f.write('some text')

	
9
>>> with open('somefile', 'r') as f:
	i = iter(f)
	assert f is i
	for line in i:
		print(line)
	try:
		next(i)
	except StopIteration:
		print('exhausted iterator')
	f.seek(0)
	print(next(i))

	
some text
exhausted iterator
0
some text

So the io classes are *officially* broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 17:24:00 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Fri, 20 Mar 2015 16:24:00 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426868640.61.0.91965249835.issue23700@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

OTOH, it would be very hard to change the way fileobjects compared to designing yield from differently so I'd still blame it partly.
Maybe it is unfortunate that generators have a close method instead of, say, __close__ ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Fri Mar 20 17:41:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 16:41:30 +0000
Subject: [issue23419] Faster default __reduce__ for classes without __init__
In-Reply-To: <1423479644.09.0.947345755494.issue23419@psf.upfronthosting.co.za>
Message-ID: <1426869690.45.0.603661252404.issue23419@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

For a namedtuple such as turtle.Vec2D there is no significant difference in the time of unpickling. But for simpler type it is.

$ ./python -m timeit -s 'import pickle, turtle; global I' -s 'class I(int): pass' -s 'p = pickle.dumps([I(i) for i in range(1000)], 3)' -- 'pickle.loads(p)'

Before: 1000 loops, best of 3: 1.6 msec per loop
After:  1000 loops, best of 3: 1.82 msec per loop

So I withdraw my patch. Unpickling performance is more important than pickling performance, and status quo wins. Sorry for the noise.

----------
assignee:  -> serhiy.storchaka
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23419>
_______________________________________

From report at bugs.python.org  Fri Mar 20 18:00:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 17:00:08 +0000
Subject: [issue23717] strptime() with year-weekday pair can produce invalid
 data
In-Reply-To: <1426850371.96.0.168304833853.issue23717@psf.upfronthosting.co.za>
Message-ID: <1426870808.73.0.928365549054.issue23717@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Agree. But may be at least emit a warning?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23717>
_______________________________________

From report at bugs.python.org  Fri Mar 20 18:26:20 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 20 Mar 2015 17:26:20 +0000
Subject: [issue23662] Cookie.domain is undocumented
In-Reply-To: <1426345280.31.0.365548742215.issue23662@psf.upfronthosting.co.za>
Message-ID: <1426872380.7.0.319826758692.issue23662@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +demian.brecht

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23662>
_______________________________________

From report at bugs.python.org  Fri Mar 20 18:58:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 17:58:36 +0000
Subject: [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1426874316.81.0.593557752997.issue22832@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Except brackets the patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22832>
_______________________________________

From report at bugs.python.org  Fri Mar 20 19:14:42 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Mar 2015 18:14:42 +0000
Subject: [issue23723] Provide a way to disable bytecode staleness checks
Message-ID: <1426875282.27.0.254210392532.issue23723@psf.upfronthosting.co.za>


New submission from Brett Cannon:

In environments where bytecode generation is thoroughly controlled, it would be nice if there was a way to specify that the bytecode file is externally guaranteed to be up-to-date, and thus skip any stat call involving bytecode verification. Could be represented with a timestamp of either all zeroes or ones in the bytecode file header.

----------
assignee: brett.cannon
components: Interpreter Core
messages: 238704
nosy: brett.cannon, gregory.p.smith, twouters
priority: low
severity: normal
status: open
title: Provide a way to disable bytecode staleness checks
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23723>
_______________________________________

From report at bugs.python.org  Fri Mar 20 19:15:58 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Mar 2015 18:15:58 +0000
Subject: [issue23723] Provide a way to disable bytecode staleness checks
In-Reply-To: <1426875282.27.0.254210392532.issue23723@psf.upfronthosting.co.za>
Message-ID: <1426875358.41.0.168344469982.issue23723@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

What is the benefit?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23723>
_______________________________________

From report at bugs.python.org  Fri Mar 20 19:18:36 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 18:18:36 +0000
Subject: [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <20150320181833.30720.5675@psf.io>


Roundup Robot added the comment:

New changeset a3c9c2c92b87 by Serhiy Storchaka in branch 'default':
Issue #22832: Tweaked parameter names for fcntl module to better match
https://hg.python.org/cpython/rev/a3c9c2c92b87

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22832>
_______________________________________

From report at bugs.python.org  Fri Mar 20 19:19:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 18:19:55 +0000
Subject: [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1426875595.98.0.697658299746.issue22832@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks you for your patch Alex.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22832>
_______________________________________

From report at bugs.python.org  Fri Mar 20 19:26:11 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 20 Mar 2015 18:26:11 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1426875971.61.0.780257266511.issue23524@psf.upfronthosting.co.za>


Steve Dower added the comment:

Any chance of a review on the newest patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23524>
_______________________________________

From report at bugs.python.org  Fri Mar 20 19:39:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 18:39:15 +0000
Subject: [issue23705] Speed-up deque.__contains__
In-Reply-To: <1426749915.16.0.735258813195.issue23705@psf.upfronthosting.co.za>
Message-ID: <1426876755.86.0.0330433826754.issue23705@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Except one line with dubious spacing the patch LGTM.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23705>
_______________________________________

From report at bugs.python.org  Fri Mar 20 19:46:02 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Mar 2015 18:46:02 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426877161.99.0.392292344448.issue22516@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

> 99% of Python users should be getting a distribution rather than the python.org installers.

I do not understand this at all.  Why?  My understanding is that at least some of the separate distributions are separate gardens cut off from the wider pip-accessible python ecosystem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Fri Mar 20 19:50:08 2015
From: report at bugs.python.org (Umank Behera)
Date: Fri, 20 Mar 2015 18:50:08 +0000
Subject: [issue23724] Stack Trace should show argument value passed into a
 function, not just the keyword
Message-ID: <1426877408.78.0.379022955074.issue23724@psf.upfronthosting.co.za>


New submission from Umank Behera:

Code:
def main(foo):
    raise Exception("Some Exception")

bar = 1
main(bar)
----

On execution:
Traceback (most recent call last):
  File "st.py", line 5, in <module>
    main(bar)
  File "st.py", line 2, in main
    raise Exception("Some Exception")
Exception: Some Exception
----

It should show the value of bar is 1 on the first frame printed.

----------
files: st.py
messages: 238711
nosy: Umank Behera
priority: normal
severity: normal
status: open
title: Stack Trace should show argument value passed into a function, not just the keyword
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38607/st.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23724>
_______________________________________

From report at bugs.python.org  Fri Mar 20 19:52:19 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 20 Mar 2015 18:52:19 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426877539.27.0.449580068288.issue22516@psf.upfronthosting.co.za>


Steve Dower added the comment:

> My understanding is that at least some of the separate distributions are separate gardens cut off from the wider pip-accessible python ecosystem.

Maybe some are, but certainly not all of them. There are sometimes cross-dependencies that require you to go to the same source for libraries (e.g. scipy and numpy need to be compatible), and if they've rebuilt Python itself then PyPI wheels may not work, but none of the major distros block or inhibit pip at all to my knowledge.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Fri Mar 20 20:14:52 2015
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Fri, 20 Mar 2015 19:14:52 +0000
Subject: [issue23725] [PATCH] update tempfile docs to say that TemporaryFile
 is secure
Message-ID: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>


New submission from Zbyszek J?drzejewski-Szmek:

tempfile docs can use some refreshing.

----------
components: Library (Lib)
files: 0001-docs-update-description-of-TemporaryFile-and-tempfil.patch
keywords: patch
messages: 238713
nosy: zbysz
priority: normal
severity: normal
status: open
title: [PATCH] update tempfile docs to say that TemporaryFile is secure
versions: Python 3.5
Added file: http://bugs.python.org/file38608/0001-docs-update-description-of-TemporaryFile-and-tempfil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23725>
_______________________________________

From report at bugs.python.org  Fri Mar 20 20:18:40 2015
From: report at bugs.python.org (Tim Graham)
Date: Fri, 20 Mar 2015 19:18:40 +0000
Subject: [issue22758] Regression in Python 3.2 cookie parsing
In-Reply-To: <1414577677.93.0.364604019199.issue22758@psf.upfronthosting.co.za>
Message-ID: <1426879120.78.0.454910154088.issue22758@psf.upfronthosting.co.za>


Tim Graham added the comment:

Patch updated to fix conflict in NEWS. Could we have it committed to ensure it gets fixed in the next 3.2 released?

----------
Added file: http://bugs.python.org/file38609/secure-httponly-3.2-backport.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22758>
_______________________________________

From report at bugs.python.org  Fri Mar 20 20:35:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 19:35:11 +0000
Subject: [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1426880111.04.0.811723600985.issue22341@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

These notes was added by Gregory in r68535. Ask him if they still are needed.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22341>
_______________________________________

From report at bugs.python.org  Fri Mar 20 20:36:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 19:36:55 +0000
Subject: [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1426880215.12.0.986679006157.issue22341@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue4903.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22341>
_______________________________________

From report at bugs.python.org  Fri Mar 20 20:40:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 19:40:27 +0000
Subject: [issue23306] Within zipfile,
 use of zlib.crc32 raises OverflowError at argument-parsing time on
 large strings
In-Reply-To: <1422056966.81.0.518971767948.issue23306@psf.upfronthosting.co.za>
Message-ID: <1426880427.94.0.650125766118.issue23306@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23306>
_______________________________________

From report at bugs.python.org  Fri Mar 20 21:10:47 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Mar 2015 20:10:47 +0000
Subject: [issue23705] Speed-up deque.__contains__
In-Reply-To: <1426749915.16.0.735258813195.issue23705@psf.upfronthosting.co.za>
Message-ID: <1426882247.86.0.364866815997.issue23705@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

It would be nice to add a test for the RuntimeError case.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23705>
_______________________________________

From report at bugs.python.org  Fri Mar 20 21:25:57 2015
From: report at bugs.python.org (Eugene Toder)
Date: Fri, 20 Mar 2015 20:25:57 +0000
Subject: [issue23726] Don't enable GC for classes that don't add new fields
Message-ID: <1426883157.79.0.718081112041.issue23726@psf.upfronthosting.co.za>


New submission from Eugene Toder:

As far as I can tell, if a new class does not add any new fields, and its base class doesn't use GC, there's no reason to enable GC for the new class.
This is useful for creating lightweight wrappers around classes implemented in C.

----------
files: class_gc.diff
keywords: patch
messages: 238718
nosy: eltoder, pitrou
priority: normal
severity: normal
status: open
title: Don't enable GC for classes that don't add new fields
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file38610/class_gc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23726>
_______________________________________

From report at bugs.python.org  Fri Mar 20 21:35:14 2015
From: report at bugs.python.org (Paul Moore)
Date: Fri, 20 Mar 2015 20:35:14 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426883714.62.0.827702022605.issue22516@psf.upfronthosting.co.za>


Paul Moore added the comment:

> 99% of Python users should be getting a distribution rather than the python.org installers

I'm not at all convinced by this logic. On Windows, as far as I'm aware, the only "major" Python distributions are Anaconda and Enthought, both of which are intended mainly for the scientific community.

What "distribution" would you suggest for a web developer? For a system admin who wants to write automation scripts? For a database admin doing reporting and automation? For an application developer planning on packaging his application with py2exe/cx_freeze? For a game developer embedding Python? I'd assume all of those target audiences would use the python.org installers.

Honestly, my guess (conceded, this is based on no actual metrics) would be that 99% of Windows users use the python.org installers, certainly not the other way around.

----------
nosy: +paul.moore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Fri Mar 20 21:35:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 20:35:47 +0000
Subject: [issue23726] Don't enable GC for classes that don't add new fields
In-Reply-To: <1426883157.79.0.718081112041.issue23726@psf.upfronthosting.co.za>
Message-ID: <1426883747.51.0.86451493583.issue23726@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
components: +Interpreter Core
nosy: +serhiy.storchaka
stage:  -> patch review
versions: +Python 3.5 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23726>
_______________________________________

From report at bugs.python.org  Fri Mar 20 21:49:46 2015
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 20 Mar 2015 20:49:46 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module
In-Reply-To: <1426842565.43.0.90937176009.issue23618@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM08QBArNeqUvU9PG7wtE7TPWnVn1vTCTEU14CguCiOnmg@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Could you regenerate your latest patch?
It doesn't show properly in the review tool.

Also, what's with the assert?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Fri Mar 20 21:51:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 20:51:00 +0000
Subject: [issue23726] Don't enable GC for classes that don't add new fields
In-Reply-To: <1426883157.79.0.718081112041.issue23726@psf.upfronthosting.co.za>
Message-ID: <1426884660.4.0.546594682058.issue23726@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

>>> class UserIntSlots(int):
...     __slots__ = ()
...     def __repr__(s): return '5'
... 
>>> (4).__class__ = UserIntSlots
>>> 2+2
5
>>> type(2+2)
<class '__main__.UserIntSlots'>

It looks weird.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23726>
_______________________________________

From report at bugs.python.org  Fri Mar 20 21:52:43 2015
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Fri, 20 Mar 2015 20:52:43 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426853419.62.0.629301425726.issue23648@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM0gaCEQVP1=wx3DVt8=P_iB7QRxfyMZZD3OziefWGdpyA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

Well, all the syscalls which can blocki can fail with EINTR, so all
I:O related one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Fri Mar 20 22:07:32 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 20 Mar 2015 21:07:32 +0000
Subject: [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1426885652.75.0.483005832185.issue22341@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I do not object to the removal of the & 0xfffffff from the stdlib library code if these functions have actually been fixed to always return unsigned now.  (double check the behavior, and if good, just do it!)

But I think the docs should still mention that the & 0xffffffff is a good practice if code needs to be compatible with Python versions prior to X.Y (list the last release before the behavior was corrected).  Possibly within a .. versionchanged: section.

People often use the latest docs when writing code in any version of Python as we continually improve docs and are pretty good about noting old behaviors and when behaviors changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22341>
_______________________________________

From report at bugs.python.org  Fri Mar 20 22:22:42 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 20 Mar 2015 21:22:42 +0000
Subject: [issue23723] Provide a way to disable bytecode staleness checks
In-Reply-To: <1426875282.27.0.254210392532.issue23723@psf.upfronthosting.co.za>
Message-ID: <1426886562.28.0.0443194540811.issue23723@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

This would avoid the need to modify an interpreter to have this optimization.  In this mode the potentially expensive stat() call is avoided.  No need to ensure that the pyc file's embedded timestamp matches the py file's timestamp.  The only use of this mode would be when that is guaranteed by a build system so loading modules continues to be fast without reverting to loading the py when the pyc is already known good.

Our specific example is a build system that generates pyc's for some py files at build time but timestamps of files are not maintained at all through the build/packaging/distribution process because they are seen an irrelevant detail and not even kept track of by the build.  Python is fairly unique in wanting to depend upon file timestamp metadata as a form of input data going from py -> pyc.

Right now we work around the problem by not having py files available at all in this situation.  Using .pycs greatly speeds up the program's load time, but not having source code around makes for worse tracebacks and causes problems with other tools which need to use the source.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23723>
_______________________________________

From report at bugs.python.org  Fri Mar 20 22:38:06 2015
From: report at bugs.python.org (Brian Peterson)
Date: Fri, 20 Mar 2015 21:38:06 +0000
Subject: [issue23727] rfc2231 line continuations result in an additional
 newline
Message-ID: <1426887486.58.0.0728817977831.issue23727@psf.upfronthosting.co.za>


New submission from Brian Peterson:

Hey, 

So here we go:

When an email header goes over a line break, rfc2231 (https://tools.ietf.org/html/rfc2231) specifies that it get formatted in such a way that the line break is stripped out. This formatting looks like, for example:

> filename*0="my long attachment"
> filename*1="name.txt"

... which should then get interpreted so that is "semantically identical" to:

> filename="my long attachment name.txt"

Here's a link to an example github repo where I see this not occurring: https://github.com/bepetersn/special-repo

More specifically, the behavior I AM seeing is that the formatting is handled just fine, but that a newline character gets added in.

(I originally thought this had to do with the requests library, so that's why my example repo has some stuff related to that in there too, which you can safely ignore.)

Also, if I am off-base, possibly if my input email's formatting is to blame, sorry for the trouble. :-)

Thanks for reading!

----------
components: Windows
messages: 238725
nosy: Brian Peterson, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: rfc2231 line continuations result in an additional newline
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23727>
_______________________________________

From report at bugs.python.org  Fri Mar 20 22:44:00 2015
From: report at bugs.python.org (Ned Deily)
Date: Fri, 20 Mar 2015 21:44:00 +0000
Subject: [issue23725] [PATCH] update tempfile docs to say that TemporaryFile
 is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1426887840.33.0.775758985114.issue23725@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23725>
_______________________________________

From report at bugs.python.org  Fri Mar 20 22:52:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 21:52:50 +0000
Subject: [issue23728] binascii.crc_hqx() can return negative integer
Message-ID: <1426888370.18.0.244841446134.issue23728@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

zlib.adler32(), zlib.crc32(), and binascii.crc32() always return 32-bit unsigned integer in Python 3. binascii.crc_hqx() almost always returns 16-bit unsigned integer. But there is an exception. The result can negative only when arguments of binascii.crc_hqx() are empty bytes and negative integer. This looks as a bug and should be fixed. But may be no need to apply changes to maintained releases.

----------
components: Extension Modules
keywords: easy
messages: 238726
nosy: gregory.p.smith, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: binascii.crc_hqx() can return negative integer
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23728>
_______________________________________

From report at bugs.python.org  Fri Mar 20 23:00:14 2015
From: report at bugs.python.org (Eugene Toder)
Date: Fri, 20 Mar 2015 22:00:14 +0000
Subject: [issue23726] Don't enable GC for classes that don't add new fields
In-Reply-To: <1426883157.79.0.718081112041.issue23726@psf.upfronthosting.co.za>
Message-ID: <1426888814.78.0.88443470005.issue23726@psf.upfronthosting.co.za>


Eugene Toder added the comment:

Agreed, but this is not new. This works without my change:

>>> class Tuple(tuple):
...   __slots__ = ()
...   def __repr__(self): return 'Imma tuple!'                                                    
... 
>>> ().__class__ = Tuple
>>> ()
Imma tuple!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23726>
_______________________________________

From report at bugs.python.org  Fri Mar 20 23:03:37 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Mar 2015 22:03:37 +0000
Subject: [issue23665] Provide IDLE menu option to set command-line arguments
In-Reply-To: <1426376024.32.0.301061562538.issue23665@psf.upfronthosting.co.za>
Message-ID: <1426889017.71.0.190024022737.issue23665@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

#5680 has 3 different patches. I have not reviewed them yet.  I will link to Raymond's message there.

----------
nosy: +terry.reedy
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Command-line arguments when running in IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23665>
_______________________________________

From report at bugs.python.org  Fri Mar 20 23:04:35 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Mar 2015 22:04:35 +0000
Subject: [issue5680] Command-line arguments when running in IDLE
In-Reply-To: <1238798556.38.0.28468201552.issue5680@psf.upfronthosting.co.za>
Message-ID: <1426889075.16.0.103813313654.issue5680@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I closed #23665 in favor of this one.  Raymond's take: msg238108

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5680>
_______________________________________

From report at bugs.python.org  Fri Mar 20 23:10:10 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 20 Mar 2015 22:10:10 +0000
Subject: [issue23726] Don't enable GC for classes that don't add new fields
In-Reply-To: <1426883157.79.0.718081112041.issue23726@psf.upfronthosting.co.za>
Message-ID: <1426889410.63.0.253913559885.issue23726@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I wasn't aware of that :-o

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23726>
_______________________________________

From report at bugs.python.org  Fri Mar 20 23:19:41 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 20 Mar 2015 22:19:41 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426889981.24.0.98375691424.issue22516@psf.upfronthosting.co.za>


Steve Dower added the comment:

> my guess (conceded, this is based on no actual metrics) would be that 99% of Windows users use the python.org installers, certainly not the other way around.

Based on numbers I've heard it's certainly a majority currently using the python.org installers, but that doesn't mean they should be.

I see three main use cases for the installers:

* people who need Python for themselves
* people who need to bundle Python inside their app
* admins who want to pretend/make-as-if Windows was shipped with Python

Currently, the python.org installer is partway between 1 and 3, and somewhat closer to 3. I've heard a lot of complaints from people in #1, who are mostly helped by one of the distros, and #2 who don't have a real good option right now. (99% in category #1 is an exaggeration, but they're still a majority.)

Being somewhere between these points is not good. Personally, I think #2 (which I think about as "Python-as-a-library") is something that it's really our responsibility to support. #3 is also something that only we [pydev] can do (unless MSFT starts doing it, but I'd expect a lot of the burden would be pushed back onto pydev in this case), while #1 is a fairly straightforward for anyone to do once #2 is supported.

Certainly if #2 became official, we [MSFT] would be more aggressively helping people get set up with the same version of Python as we install on our PaaS servers on Azure. Currently, we can't reliably install the python.org installers automatically in case it conflicts with the user's existing configuration.

Most of your examples use the python.org installers because they are in category #2 and don't have a better option. When/if we decide what category the python.org installer should focus on, it will make it easier to explain which option people should use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Fri Mar 20 23:21:35 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 20 Mar 2015 22:21:35 +0000
Subject: [issue23727] rfc2231 line continuations result in an additional
 newline
In-Reply-To: <1426887486.58.0.0728817977831.issue23727@psf.upfronthosting.co.za>
Message-ID: <1426890095.0.0.733178507056.issue23727@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
components: +email -Windows
nosy: +barry, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23727>
_______________________________________

From report at bugs.python.org  Fri Mar 20 23:26:34 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 22:26:34 +0000
Subject: [issue23726] Don't enable GC for classes that don't add new fields
In-Reply-To: <1426889410.63.0.253913559885.issue23726@psf.upfronthosting.co.za>
Message-ID: <2564986.cMqX4Z4kWA@raxxla>


Serhiy Storchaka added the comment:

May be we should forbid assigning the __class__ attribute of basic builtin 
types (especially internable, such as int, str, bytes, tuple, bool, NoneType).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23726>
_______________________________________

From report at bugs.python.org  Fri Mar 20 23:32:53 2015
From: report at bugs.python.org (Eugene Toder)
Date: Fri, 20 Mar 2015 22:32:53 +0000
Subject: [issue23726] Don't enable GC for classes that don't add new fields
In-Reply-To: <1426883157.79.0.718081112041.issue23726@psf.upfronthosting.co.za>
Message-ID: <1426890773.16.0.806567287958.issue23726@psf.upfronthosting.co.za>


Eugene Toder added the comment:

Actually, this is rather new -- new in 3.5. The check was relaxed in #22986: https://hg.python.org/cpython/rev/c0d25de5919e
Previously only heap types allowed re-assigning __class__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23726>
_______________________________________

From report at bugs.python.org  Fri Mar 20 23:35:18 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 20 Mar 2015 22:35:18 +0000
Subject: [issue5680] Command-line arguments when running in IDLE
In-Reply-To: <1238798556.38.0.28468201552.issue5680@psf.upfronthosting.co.za>
Message-ID: <1426890918.9.0.717313370604.issue5680@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Here's my comment from the duplicate tracker item:
--------------------------------------------------

A number of IDEs support menu options to set the execution environment for programs under development and testing.  In particular, it would be nice if IDLE let the user set command line arguments to be passed into sys.argv when running a script by pressing F5.

Here are some existing implementations for reference:
* Wing-IDE: https://wingware.com/doc/intro/tutorial-debugging-launch
* Visual Studio: https://www.youtube.com/watch?v=IgbQCRHKV-Y
* PyCharm: https://www.jetbrains.com/pycharm/help/run-debug-configuration-python.html

This feature will help users interactively develop and test command-line tools while retaining all the nice features of the IDE.   I would personally find it useful when teaching students about how sys.argv works.

I suggest adding an option under the Run menu for Set Command Line arguments.  It would trigger a dialog box that lets a user set a string such as "somefile.txt -r 10".  The user string would be run through shlex to break it into separate fields.  When F5 is pressed, the sys.argv list would be repopulated to include the script name and the lexed arguments.

A little more elaborate option is to add a Run menu entry for Set Execution Enviroment that let's the user 1) set the command-line  2) specify the start-up directory (using os.chdir), 3) and edit the environment variables (from os.environ) or at least be able to set PYTHONPATH.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5680>
_______________________________________

From report at bugs.python.org  Fri Mar 20 23:36:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 22:36:11 +0000
Subject: [issue23726] Don't enable GC for classes that don't add new fields
In-Reply-To: <1426883157.79.0.718081112041.issue23726@psf.upfronthosting.co.za>
Message-ID: <1426890971.74.0.491301431956.issue23726@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23726>
_______________________________________

From report at bugs.python.org  Fri Mar 20 23:52:10 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Mar 2015 22:52:10 +0000
Subject: [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1426891930.16.0.787380379608.issue22341@psf.upfronthosting.co.za>


Martin Panter added the comment:

Hi Gregory, I think the three functions have been fixed since Python 3.0. It looks like you changed them in revisions 6a7fa8421902 (zlib module) and 132cf3a79126 (crc32 functions). Looking at the 3.0 branch, all three functions use PyLong_FromUnsignedLong(), but in the 2.7 branch, they use PyInt_FromLong(). This is tested in test_zlib.ChecksumTestCase.test_crc32_adler32_unsigned(). See also my changes to test_penguins() in the patch here for further testing. There is no explicit testing of binascii.crc32() unsignedness, but it is implicitly tested by test_same_as_binascii_crc32(), because the expected CRC is beyond the positive 32 bit signed limit.

I am happy to put back the suggestion of masking for backwards compatibility if you really think it is necessary. But since it only involves Python < 3.0 compatibility, I thought it would be okay to remove it; see my original post. The documentation is often pretty good about noting when Python 3 behaviours changed, but you usually have to look elsewhere to see the differences from Python 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22341>
_______________________________________

From report at bugs.python.org  Sat Mar 21 00:01:32 2015
From: report at bugs.python.org (Nicholas Chammas)
Date: Fri, 20 Mar 2015 23:01:32 +0000
Subject: [issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor
 should accept an initializer argument
In-Reply-To: <1399160288.58.0.274862722075.issue21423@psf.upfronthosting.co.za>
Message-ID: <1426892492.2.0.610672512594.issue21423@psf.upfronthosting.co.za>


Changes by Nicholas Chammas <nicholas.chammas at gmail.com>:


----------
nosy: +Nicholas Chammas

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21423>
_______________________________________

From report at bugs.python.org  Sat Mar 21 00:30:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Mar 2015 23:30:39 +0000
Subject: [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1426894239.4.0.40636070893.issue22832@psf.upfronthosting.co.za>


Martin Panter added the comment:

I object to dropping the brackets from the function signatures. Now it gives the impression that the functions accept keyword arguments:

ioctl(fd, request, arg=0, mutate_flag=True)

but:

>>> ioctl(0, 0, bytearray(), mutate_flag=False)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: ioctl() takes no keyword arguments

There is already a little bit of precedent for this, e.g. the built-in eval() function, but I would prefer using square brackets, or some other non-Python syntax indicator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22832>
_______________________________________

From report at bugs.python.org  Sat Mar 21 00:39:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 23:39:18 +0000
Subject: [issue23705] Speed-up deque.__contains__
In-Reply-To: <1426749915.16.0.735258813195.issue23705@psf.upfronthosting.co.za>
Message-ID: <20150320233915.30716.37923@psf.io>


Roundup Robot added the comment:

New changeset 99eb196fb345 by Raymond Hettinger in branch 'default':
Issue 23705:  Improve the performance of __contains__ checks for deques.
https://hg.python.org/cpython/rev/99eb196fb345

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23705>
_______________________________________

From report at bugs.python.org  Sat Mar 21 00:39:51 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 20 Mar 2015 23:39:51 +0000
Subject: [issue23705] Speed-up deque.__contains__
In-Reply-To: <1426749915.16.0.735258813195.issue23705@psf.upfronthosting.co.za>
Message-ID: <1426894791.74.0.330435886623.issue23705@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks guys.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23705>
_______________________________________

From report at bugs.python.org  Sat Mar 21 00:41:33 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Mar 2015 23:41:33 +0000
Subject: [issue21152] Idle: timed autosave for shell (and maybe editor) window
In-Reply-To: <1396599186.38.0.494576293163.issue21152@psf.upfronthosting.co.za>
Message-ID: <1426894893.29.0.187285788496.issue21152@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

For Shell, autoappend would do the same, and saving on each >>> rather than by time might be more appropriate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21152>
_______________________________________

From report at bugs.python.org  Sat Mar 21 00:42:45 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Mar 2015 23:42:45 +0000
Subject: [issue23666] Add shell session logging option to IDLE
In-Reply-To: <1426376285.32.0.372835851361.issue23666@psf.upfronthosting.co.za>
Message-ID: <1426894965.86.0.666105567843.issue23666@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I do not see how Restart (as opposed to a proposed Clear option) loses anything.  However, closing without saving definitely anything since a save.  Moreover, even after saving Shell once, there is no Save on Close box displayed (as for editor windows) when closing Shell without saving.  This has been discussed somewhere (maybe StackOverflow) but I do not find an issue.

Raymond, would it be sufficient if saving once would mean that one could not close (or clear the window) without being prompted to save again?  What if we add timed autosaves #21152 (based on your comment on #21140, msg215485), or autosave (or autoappend) with each prompt?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23666>
_______________________________________

From report at bugs.python.org  Sat Mar 21 01:00:48 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 21 Mar 2015 00:00:48 +0000
Subject: [issue23667] IDLE to provide option for making trailing whitespace
 visible
In-Reply-To: <1426376584.28.0.267295855034.issue23667@psf.upfronthosting.co.za>
Message-ID: <1426896048.84.0.136947690454.issue23667@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree that this area needs improvement.  'Strip trailing whitespace' should strip trailing blank lines at the end of a file, as well as trailing blank spaces at the end of each line.  Both are required to commit to our repository.

I would like to have a configuration option to always strip trailing blanks, at least for .py files.

I believe the cursor moving from one line to another is an event that is or could be caugth and acted on. If so, trailing spaces could be removed immediately from the line left, and Save would only have to check the current line and the end of the file.  I would rather remove blanks than mark them for later removal.

----------
nosy: +terry.reedy
stage:  -> needs patch
versions: +Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23667>
_______________________________________

From report at bugs.python.org  Sat Mar 21 01:02:06 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 21 Mar 2015 00:02:06 +0000
Subject: [issue23529] Limit decompressed data when reading from LZMAFile and
 BZ2File
In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za>
Message-ID: <1426896126.98.0.334442345309.issue23529@psf.upfronthosting.co.za>


Martin Panter added the comment:

Wolfgang: Unfortunately, I think that block of changes is largely unavoidable. The write() method should not have changed in reality, but all the init and read methods around it have been split into two classes, and the diff has decided to compare the old GzipFile methods to the new _DecompressReader methods. If you like I could try preparing a pseudo diff files that forces it to compare old GzipFile to new GzipFile to highlight the changes there.

Nikolaus: I will try to split my buffer_size parameter changes out and post them in a separate issue that can be enhanced further.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23529>
_______________________________________

From report at bugs.python.org  Sat Mar 21 01:04:10 2015
From: report at bugs.python.org (Neil Girdhar)
Date: Sat, 21 Mar 2015 00:04:10 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1426896250.56.0.413043593018.issue2292@psf.upfronthosting.co.za>


Changes by Neil Girdhar <mistersheik at gmail.com>:


Added file: http://bugs.python.org/file38611/starunpack38.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Sat Mar 21 01:26:41 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Mar 2015 00:26:41 +0000
Subject: [issue23666] Add shell session logging option to IDLE
In-Reply-To: <1426376285.32.0.372835851361.issue23666@psf.upfronthosting.co.za>
Message-ID: <1426897601.24.0.731113535327.issue23666@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Autosave would suffice.  :-)

The "restart" issue wasn't the usual restart you get by pressing F5.  What is happening is that someone does an action that kills or hangs the IDLE app, then they have to force close and restart IDLE itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23666>
_______________________________________

From report at bugs.python.org  Sat Mar 21 01:36:48 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 21 Mar 2015 00:36:48 +0000
Subject: [issue23698] Multiprocessing.Manager: fix behavior and doc
 inconsistencies
In-Reply-To: <1426660385.12.0.0389729473261.issue23698@psf.upfronthosting.co.za>
Message-ID: <1426898208.53.0.947388620348.issue23698@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Fix inconsistencies in behaviour and document it correctly for multiprocessing.Manager facade -> Multiprocessing.Manager: fix behavior and doc inconsistencies

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23698>
_______________________________________

From report at bugs.python.org  Sat Mar 21 01:44:34 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Sat, 21 Mar 2015 00:44:34 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1426898674.47.0.168131361523.issue23496@psf.upfronthosting.co.za>


Ryan Gonzalez added the comment:

...except for the pyconfig.h changes. Need to do something with autoconf for that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Sat Mar 21 02:13:36 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 21 Mar 2015 01:13:36 +0000
Subject: [issue23666] Add shell session logging option to IDLE
In-Reply-To: <1426376285.32.0.372835851361.issue23666@psf.upfronthosting.co.za>
Message-ID: <1426900416.97.0.537118028501.issue23666@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Do you know if, when a process is killed, date written to open files gets flushed to disk?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23666>
_______________________________________

From report at bugs.python.org  Sat Mar 21 02:57:09 2015
From: report at bugs.python.org (SMRUTI RANJAN SAHOO)
Date: Sat, 21 Mar 2015 01:57:09 +0000
Subject: [issue23687] Stacktrace identifies wrong line in multiline list
 comprehension
In-Reply-To: <1426599885.89.0.0578302709073.issue23687@psf.upfronthosting.co.za>
Message-ID: <1426903029.53.0.82668015807.issue23687@psf.upfronthosting.co.za>


SMRUTI RANJAN SAHOO added the comment:

the "y" should be replaced by "none". so that will not show any error.
i attached the image of my shell.

----------
nosy: +SMRUTI RANJAN SAHOO
Added file: http://bugs.python.org/file38612/py2.JPG

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23687>
_______________________________________

From report at bugs.python.org  Sat Mar 21 02:59:13 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 21 Mar 2015 01:59:13 +0000
Subject: [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1426903153.35.0.668129262124.issue22832@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> I object to dropping the brackets from the function signatures. Now it gives the impression that the functions accept keyword arguments:

See issue 21488 for a similar confusion.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22832>
_______________________________________

From report at bugs.python.org  Sat Mar 21 03:00:11 2015
From: report at bugs.python.org (koobs)
Date: Sat, 21 Mar 2015 02:00:11 +0000
Subject: [issue23042] ctypes module doesn't build on FreeBSD,
 RHEL (x86) - Undefined symbol "ffi_call_win32"
In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za>
Message-ID: <1426903211.08.0.294628081133.issue23042@psf.upfronthosting.co.za>


koobs added the comment:

@Marc, if upstream 3.2.1 also has the issue, then that would mean the current FreeBSD Python ports, which use --use-system-ffi and the security/libffi port, currently at version 3.2.1 [1], can reproduce the issue. 

I'm not aware of reports that they fail in this manner though.

[1] http://www.freshports.org/devel/libffi/

----------
title: ctypes module doesn't build on FreeBSD x86 -> ctypes module doesn't build on FreeBSD, RHEL (x86) - Undefined symbol "ffi_call_win32"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23042>
_______________________________________

From report at bugs.python.org  Sat Mar 21 03:07:17 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 21 Mar 2015 02:07:17 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1426903637.17.0.749122265922.issue23571@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Can we add a note (probably with an example) to the Porting to Python 3.5 section of https://docs.python.org/3.5/whatsnew/3.5.html#porting-to-python-3-5

I believe that this patch exposes some subtle bugs in Django (see https://gist.github.com/berkerpeksag/8b8dbe594eb1a1c51275) and it would be great to add a note for third party libraries.

----------
nosy: +berker.peksag
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Sat Mar 21 03:34:03 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 21 Mar 2015 02:34:03 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1426905243.0.0.886283825287.issue23725@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Zbyszek. For future reference, please send patches from the Mercurial repository. It will make the patch review process easier. See also devguide.

+:func:`TemporaryDirectory`, :func:`SpooledTemporaryFile`, which can be

Both TemporaryDirectory and SpooledTemporaryFile are actually a class. See https://hg.python.org/cpython/file/3.4/Lib/tempfile.py#l510

+   :ref:`context-managers`).  On completion of the context or

:ref:`context-managers` link is unnecessary in my opinion. It would be better to link https://docs.python.org/3/library/tempfile.html#examples

(Please update tempfile.TemporaryDirectory docs too.)

----------
nosy: +berker.peksag
title: [PATCH] update tempfile docs to say that TemporaryFile is secure -> update tempfile docs to say that TemporaryFile is secure
type:  -> enhancement
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23725>
_______________________________________

From report at bugs.python.org  Sat Mar 21 03:50:50 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 21 Mar 2015 02:50:50 +0000
Subject: [issue23674] super() documentation isn't very clear
In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za>
Message-ID: <1426906250.96.0.560371165576.issue23674@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23674>
_______________________________________

From report at bugs.python.org  Sat Mar 21 03:57:02 2015
From: report at bugs.python.org (Neil Girdhar)
Date: Sat, 21 Mar 2015 02:57:02 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1426906622.26.0.234664423079.issue2292@psf.upfronthosting.co.za>


Neil Girdhar added the comment:

Removed a confusing and outdated comment in Lib/importlib/_bootstrap.py

----------
Added file: http://bugs.python.org/file38613/starunpack39.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
_______________________________________

From report at bugs.python.org  Sat Mar 21 04:26:48 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 21 Mar 2015 03:26:48 +0000
Subject: [issue23668] Support os.[f]truncate on Windows
In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za>
Message-ID: <1426908408.12.0.325845610332.issue23668@psf.upfronthosting.co.za>


Steve Dower added the comment:

Updated the patch, since there's been a lot of checkins.

I also removed the pyconfig.h changes and updated the #ifdef in posixmodule.c to enable truncate/ftruncate and define PATH_HAVE_FTRUNCATE.

And I know in the last review I said I'd switch to _Py_wopen(), but if I do that there's no way to avoid passing _O_CREAT, so I opted to stick with _wopen() and pass _O_NOINHERIT instead.

Hopefully Reitveld handles this patch file. I'm sure I'm not doing anything differently from normal...

----------
Added file: http://bugs.python.org/file38614/23668_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23668>
_______________________________________

From report at bugs.python.org  Sat Mar 21 04:30:13 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 21 Mar 2015 03:30:13 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1426908613.14.0.803068401365.issue23524@psf.upfronthosting.co.za>


Steve Dower added the comment:

Updated the patch, mainly because of the changes that have gone in over the last week (especially _Py_read and _Py_write).

----------
Added file: http://bugs.python.org/file38615/23524_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23524>
_______________________________________

From report at bugs.python.org  Sat Mar 21 04:38:10 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 21 Mar 2015 03:38:10 +0000
Subject: [issue15011] Change Scripts to bin on Windows
In-Reply-To: <1338952995.87.0.980800482386.issue15011@psf.upfronthosting.co.za>
Message-ID: <1426909090.8.0.32345789749.issue15011@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Should we try to implement this in 3.5, hold it until 3.6, reject it completely or what?

----------
nosy: +BreamoreBoy, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15011>
_______________________________________

From report at bugs.python.org  Sat Mar 21 04:41:54 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 21 Mar 2015 03:41:54 +0000
Subject: [issue9445] Fix undefined symbol errors on VS8.0 build
In-Reply-To: <1280627576.04.0.298775706484.issue9445@psf.upfronthosting.co.za>
Message-ID: <1426909314.35.0.968598693806.issue9445@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I believe that this can be closed as fixed, would someone like to do the honours please.

----------
nosy: +steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9445>
_______________________________________

From report at bugs.python.org  Sat Mar 21 04:57:40 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 21 Mar 2015 03:57:40 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za>
Message-ID: <1426910260.04.0.848728652838.issue23524@psf.upfronthosting.co.za>


Steve Dower added the comment:

I think my patch queue went bad somewhere - a few lines disappeared. New patch.

----------
Added file: http://bugs.python.org/file38616/23524_5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23524>
_______________________________________

From report at bugs.python.org  Sat Mar 21 05:12:59 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Mar 2015 04:12:59 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1426911179.35.0.818195601162.issue23700@psf.upfronthosting.co.za>


R. David Murray added the comment:

There's actually an issue about exactly that broken-per-docs issue for io.  IMO if the goal of calling close is to close only things that are generator objects or pretending to be one, the method should have been named close_generator or something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Sat Mar 21 05:16:33 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Mar 2015 04:16:33 +0000
Subject: [issue23724] Stack Trace should show argument value passed into a
 function, not just the keyword
In-Reply-To: <1426877408.78.0.379022955074.issue23724@psf.upfronthosting.co.za>
Message-ID: <1426911393.08.0.0291933344838.issue23724@psf.upfronthosting.co.za>


R. David Murray added the comment:

Duplicate of issue 22936.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> traceback module has no way to show locals
versions:  -Python 2.7, Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23724>
_______________________________________

From report at bugs.python.org  Sat Mar 21 05:16:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Mar 2015 04:16:48 +0000
Subject: [issue22936] traceback module has no way to show locals
In-Reply-To: <1416881127.83.0.815944275743.issue22936@psf.upfronthosting.co.za>
Message-ID: <1426911408.89.0.845375317263.issue22936@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +n

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22936>
_______________________________________

From report at bugs.python.org  Sat Mar 21 05:19:28 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Mar 2015 04:19:28 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1426911568.27.0.23561627944.issue23725@psf.upfronthosting.co.za>


R. David Murray added the comment:

It would also be helpful to have a patch with minimum changes (that is, do not reflow the lines).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23725>
_______________________________________

From report at bugs.python.org  Sat Mar 21 05:27:12 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Mar 2015 04:27:12 +0000
Subject: [issue23727] rfc2231 line continuations result in an additional
 newline
In-Reply-To: <1426887486.58.0.0728817977831.issue23727@psf.upfronthosting.co.za>
Message-ID: <1426912032.95.0.401367346068.issue23727@psf.upfronthosting.co.za>


R. David Murray added the comment:

Can you provide an example email in a simple reproducer script?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23727>
_______________________________________

From report at bugs.python.org  Sat Mar 21 05:31:32 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Mar 2015 04:31:32 +0000
Subject: [issue23687] Stacktrace identifies wrong line in multiline list
 comprehension
In-Reply-To: <1426599885.89.0.0578302709073.issue23687@psf.upfronthosting.co.za>
Message-ID: <1426912292.8.0.73630431222.issue23687@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file38612/py2.JPG

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23687>
_______________________________________

From report at bugs.python.org  Sat Mar 21 05:31:47 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Mar 2015 04:31:47 +0000
Subject: [issue23687] Stacktrace identifies wrong line in multiline list
 comprehension
In-Reply-To: <1426599885.89.0.0578302709073.issue23687@psf.upfronthosting.co.za>
Message-ID: <1426912307.43.0.106810605938.issue23687@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
Removed message: http://bugs.python.org/msg238746

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23687>
_______________________________________

From report at bugs.python.org  Sat Mar 21 05:39:49 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 21 Mar 2015 04:39:49 +0000
Subject: [issue23727] rfc2231 line continuations result in an additional
 newline
In-Reply-To: <1426887486.58.0.0728817977831.issue23727@psf.upfronthosting.co.za>
Message-ID: <1426912789.52.0.586557816144.issue23727@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at microsoft.com>:


----------
nosy:  -steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23727>
_______________________________________

From report at bugs.python.org  Sat Mar 21 05:40:10 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Mar 2015 04:40:10 +0000
Subject: [issue23704] Make deques a full MutableSequence by adding index(),
 insert(), and copy()
Message-ID: <1426912810.32.0.615097560986.issue23704@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Attaching an updated patch with documentation updates and tests.

----------
Added file: http://bugs.python.org/file38617/deque_insert_index_copy4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23704>
_______________________________________

From report at bugs.python.org  Sat Mar 21 05:44:38 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 04:44:38 +0000
Subject: [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1426913078.69.0.929774675979.issue22832@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is worth a discussion on Python-Dev.
http://comments.gmane.org/gmane.comp.python.devel/152025

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22832>
_______________________________________

From report at bugs.python.org  Sat Mar 21 05:52:18 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 21 Mar 2015 04:52:18 +0000
Subject: [issue9445] Fix undefined symbol errors on VS8.0 build
In-Reply-To: <1280627576.04.0.298775706484.issue9445@psf.upfronthosting.co.za>
Message-ID: <1426913538.43.0.183688882792.issue9445@psf.upfronthosting.co.za>


Steve Dower added the comment:

The patch is obsolete, but Martin is correct - we can drop the detection completely. Any concerns?

(Reading through the issue, there may be some value in a more general GetFinalPathNameByHandle wrapper that can get VOLUME_NAME_DOS if available and VOLUME_NAME_NT as a fallback, but presumably we'd have heard someone ask in the last five years if this was really needed.)

----------
Added file: http://bugs.python.org/file38618/9445.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9445>
_______________________________________

From report at bugs.python.org  Sat Mar 21 06:02:11 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 21 Mar 2015 05:02:11 +0000
Subject: [issue15011] Change Scripts to bin on Windows
In-Reply-To: <1338952995.87.0.980800482386.issue15011@psf.upfronthosting.co.za>
Message-ID: <1426914131.33.0.526546369351.issue15011@psf.upfronthosting.co.za>


Steve Dower added the comment:

Right now I'm inclined to reject it completely, if only for backwards compatibility (there was certainly strong opposition on python-dev recently).

That said, there's some ongoing discussion about what a python.org installation is meant to look like, which may lead to an opportunity to change this as part of wider changes. If something comes of that, the install location may be able to (or need to) change, but until then this seems like a change for change's sake and is not compelling.

If that means we should close this now and reopen later, happy to do that. But without a plan to implement it, we should definitely close this rather than reassign it to 3.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15011>
_______________________________________

From report at bugs.python.org  Sat Mar 21 06:26:49 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 05:26:49 +0000
Subject: [issue23704] Make deques a full MutableSequence by adding index(),
 insert(), and copy()
In-Reply-To: <1426912810.32.0.615097560986.issue23704@psf.upfronthosting.co.za>
Message-ID: <1426915609.67.0.153035902714.issue23704@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

When appending fails, the deque is left in changed state. I would do it in different way. First append new item (can fail), and then make circular shift (never fail). This also should be faster (up to 2 times). Most code can be shared between rotate() and circular shift operation.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23704>
_______________________________________

From report at bugs.python.org  Sat Mar 21 06:42:33 2015
From: report at bugs.python.org (Paddy McCarthy)
Date: Sat, 21 Mar 2015 05:42:33 +0000
Subject: [issue10395] new os.path function to extract common prefix based on
 path components
In-Reply-To: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>
Message-ID: <1426916553.05.0.748700860999.issue10395@psf.upfronthosting.co.za>


Paddy McCarthy added the comment:

Can we now:
 1. Move os.path.commonprefix to str.commonprefix or string.commonprefix
 2. Deprecate the use of os.path.commonprefix
 3. Add os.path.commonpath
 4. Update the documentation.

This seems to have lingered for too long and yet people have been willing to do the work it seems (from 1999).

----------
nosy: +Paddy McCarthy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10395>
_______________________________________

From report at bugs.python.org  Sat Mar 21 08:29:54 2015
From: report at bugs.python.org (koobs)
Date: Sat, 21 Mar 2015 07:29:54 +0000
Subject: [issue23042] ctypes module doesn't build on FreeBSD,
 RHEL (x86) - Undefined symbol "ffi_call_win32"
In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za>
Message-ID: <1426922994.4.0.831186446771.issue23042@psf.upfronthosting.co.za>


koobs added the comment:

See also: 

Issue: https://github.com/atgreen/libffi/issues/180
Title: OSX/i386 build is broken in v3.2.1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23042>
_______________________________________

From report at bugs.python.org  Sat Mar 21 08:37:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 07:37:09 +0000
Subject: [issue22351] NNTP constructor exception leaves socket for garbage
 collector
In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za>
Message-ID: <1426923429.8.0.870575307708.issue22351@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Martin. The patch LGTM.

----------
stage: test needed -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22351>
_______________________________________

From report at bugs.python.org  Sat Mar 21 08:41:12 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Mar 2015 07:41:12 +0000
Subject: [issue23704] Make deques a full MutableSequence by adding index(),
 insert(), and copy()
In-Reply-To: <1426912810.32.0.615097560986.issue23704@psf.upfronthosting.co.za>
Message-ID: <1426923672.94.0.173328044923.issue23704@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

For now, I prefer to continue using rotate() as a primitive and am saving circular shifts for another day (likely when I start working on slices).

FWIW, the only way for append() to fail is a memory error; in which case, I would ilke to stop doing any work at alll and return a soon as possible, even if it means leaving the deque in a reordered state.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23704>
_______________________________________

From report at bugs.python.org  Sat Mar 21 08:42:05 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Mar 2015 07:42:05 +0000
Subject: [issue22351] NNTP constructor exception leaves socket for garbage
 collector
In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za>
Message-ID: <20150321074202.7239.29416@psf.io>


Roundup Robot added the comment:

New changeset e8878579eb68 by Serhiy Storchaka in branch '3.4':
Issue #22351: The nntplib.NNTP constructor no longer leaves the connection
https://hg.python.org/cpython/rev/e8878579eb68

New changeset 6622f68b064b by Serhiy Storchaka in branch 'default':
Issue #22351: The nntplib.NNTP constructor no longer leaves the connection
https://hg.python.org/cpython/rev/6622f68b064b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22351>
_______________________________________

From report at bugs.python.org  Sat Mar 21 08:45:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 07:45:17 +0000
Subject: [issue23704] Make deques a full MutableSequence by adding index(),
 insert(), and copy()
In-Reply-To: <1426912810.32.0.615097560986.issue23704@psf.upfronthosting.co.za>
Message-ID: <1426923917.42.0.860343571458.issue23704@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Then the patch LGTM except few nitpicks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23704>
_______________________________________

From report at bugs.python.org  Sat Mar 21 08:46:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 07:46:01 +0000
Subject: [issue22351] NNTP constructor exception leaves socket for garbage
 collector
In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za>
Message-ID: <1426923961.01.0.015912507159.issue22351@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22351>
_______________________________________

From report at bugs.python.org  Sat Mar 21 09:13:35 2015
From: report at bugs.python.org (Daniil Bondarev)
Date: Sat, 21 Mar 2015 08:13:35 +0000
Subject: [issue2786] Names in traceback should have class names,
 if they're methods
In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za>
Message-ID: <1426925615.06.0.224464034161.issue2786@psf.upfronthosting.co.za>


Daniil Bondarev added the comment:

issue17911 was submitted. I pulled latest updates and rechecked that "./python -m test -uall" passing with the same patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2786>
_______________________________________

From report at bugs.python.org  Sat Mar 21 09:17:01 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 21 Mar 2015 08:17:01 +0000
Subject: [issue23529] Limit decompressed data when reading from LZMAFile and
 BZ2File
In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za>
Message-ID: <1426925821.41.0.288888841161.issue23529@psf.upfronthosting.co.za>


Martin Panter added the comment:

I am posting v6, which basically drops the buffer_size parameters. The change is also pushed as a series of revisions to a Bit Bucket repository, see <https://bitbucket.org/vadmium/cpython/branches/compare/compression%0D@>. I thought that might help eliminate the giant blocks of changes in gzip.py, but it did not.

The previous changes for the buffer_size parameters are in the ?buffer_size? bookmark in that repository.

----------
hgrepos: +301
Added file: http://bugs.python.org/file38619/LZMAFile-etc.v6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23529>
_______________________________________

From report at bugs.python.org  Sat Mar 21 09:29:32 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Mar 2015 08:29:32 +0000
Subject: [issue23729] Import ElementTree documentation for namespaces and XPath
Message-ID: <1426926572.78.0.5131365949.issue23729@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Show examples of how to search XML that contains namespaces.

Also indicate the ElementTree subset of XPath supports filters in the form [tag=text].

----------
assignee: rhettinger
components: Documentation
files: elementtree_doc.diff
keywords: patch
messages: 238774
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Import ElementTree documentation for namespaces and XPath
versions: Python 3.5
Added file: http://bugs.python.org/file38620/elementtree_doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23729>
_______________________________________

From report at bugs.python.org  Sat Mar 21 09:33:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 08:33:35 +0000
Subject: [issue23411] Update urllib.parse.__all__
In-Reply-To: <1423395526.83.0.535584531827.issue23411@psf.upfronthosting.co.za>
Message-ID: <1426926815.4.0.673255039359.issue23411@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

These classes were introduced by Fred in issue624325. Is it intentional that they were not added to __all__ Fred?

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23411>
_______________________________________

From report at bugs.python.org  Sat Mar 21 09:37:48 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Mar 2015 08:37:48 +0000
Subject: [issue23704] Make deques a full MutableSequence by adding index(),
 insert(), and copy()
In-Reply-To: <1426912810.32.0.615097560986.issue23704@psf.upfronthosting.co.za>
Message-ID: <20150321083745.63564.88717@psf.io>


Roundup Robot added the comment:

New changeset 3d33be07c5a2 by Raymond Hettinger in branch 'default':
Issue 23704:  Add index(), copy(), and insert() to deques.  Register deques as a MutableSequence.
https://hg.python.org/cpython/rev/3d33be07c5a2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23704>
_______________________________________

From report at bugs.python.org  Sat Mar 21 09:39:04 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Mar 2015 08:39:04 +0000
Subject: [issue23704] Make deques a full MutableSequence by adding index(),
 insert(), and copy()
In-Reply-To: <1426912810.32.0.615097560986.issue23704@psf.upfronthosting.co.za>
Message-ID: <1426927144.42.0.355007657558.issue23704@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thank you for looking it over.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23704>
_______________________________________

From report at bugs.python.org  Sat Mar 21 10:11:29 2015
From: report at bugs.python.org (Martijn Pieters)
Date: Sat, 21 Mar 2015 09:11:29 +0000
Subject: [issue23730] Document return value for ZipFile.extract()
Message-ID: <1426929089.45.0.62065226759.issue23730@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

The documentation for zipfile.ZipFile.extract() doesn't mention at all that it returns the local path created, either for the directory that the member represents, or the new file created from the zipped data.

*Returns the full local path created (a directory or new file)* or similar.

----------
assignee: docs at python
components: Documentation
messages: 238778
nosy: docs at python, mjpieters
priority: normal
severity: normal
status: open
title: Document return value for ZipFile.extract()
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23730>
_______________________________________

From report at bugs.python.org  Sat Mar 21 10:28:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 09:28:50 +0000
Subject: [issue23704] Make deques a full MutableSequence by adding index(),
 insert(), and copy()
In-Reply-To: <1426912810.32.0.615097560986.issue23704@psf.upfronthosting.co.za>
Message-ID: <1426930130.31.0.870491974897.issue23704@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Did you noticed my comments on Rietveld? You can found Rietveld messages in the Spam folder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23704>
_______________________________________

From report at bugs.python.org  Sat Mar 21 10:32:31 2015
From: report at bugs.python.org (Dmitry Kazakov)
Date: Sat, 21 Mar 2015 09:32:31 +0000
Subject: [issue22619] Possible implementation of negative limit for traceback
 functions
In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za>
Message-ID: <1426930351.73.0.449456499037.issue22619@psf.upfronthosting.co.za>


Dmitry Kazakov added the comment:

Again, I'm honestly sorry if I'm being annoying, but is there anything else that needs to be done in order to make this issue "resolved"? The stage is set to "patch review", although there were no messages posted since the latest patch was submitted and there're no comments to the Patch set 6 in Rietveld.

> If your patch has not received any notice from reviewers (i.e., no comment made) after one month, first ?ping? the issue on the?issue tracker?to remind the nosy list that the patch needs a review. 

Is this true for the "patch review" stage? I pinged this issue about a month ago, but haven't got any response; should I have emailed python-dev at python.org even if the patch is not mine?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22619>
_______________________________________

From report at bugs.python.org  Sat Mar 21 10:37:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 09:37:04 +0000
Subject: [issue23391] Documentation of EnvironmentError (OSError) arguments
 disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1426930624.82.0.77255289404.issue23391@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Current behavior is more complicated.

>>> OSError(1, 2, 3, 4).args
(1, 2)
>>> OSError(1, 2, 3, 4, 5).args
(1, 2)
>>> OSError(1, 2, 3, 4, 5, 6).args
(1, 2, 3, 4, 5, 6)

If I remember correctly:

1 -- errno
2 -- strerror
3 -- filename
4 -- winerror (?)
5 -- filename2

Isn't it documented anywhere?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23391>
_______________________________________

From report at bugs.python.org  Sat Mar 21 10:45:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 09:45:50 +0000
Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?=
 =?utf-8?q?=E2=80=9D_exception_message_on_Wine?=
In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za>
Message-ID: <1426931150.39.0.573219862045.issue22977@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22977>
_______________________________________

From report at bugs.python.org  Sat Mar 21 10:46:17 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 21 Mar 2015 09:46:17 +0000
Subject: [issue23411] Update urllib.parse.__all__
In-Reply-To: <1423395526.83.0.535584531827.issue23411@psf.upfronthosting.co.za>
Message-ID: <1426931177.66.0.0637894840859.issue23411@psf.upfronthosting.co.za>


Berker Peksag added the comment:

*Result and *ResultBytes classes are documented at https://docs.python.org/3/library/urllib.parse.html#urllib.parse.DefragResult

+1 for adding them to __all__.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23411>
_______________________________________

From report at bugs.python.org  Sat Mar 21 11:23:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 10:23:02 +0000
Subject: [issue19176] DeprecationWarning for doctype() method when subclassing
 _elementtree.XMLParser
In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za>
Message-ID: <1426933382.34.0.277074984001.issue19176@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Looks as there is yet one difference in the behavior of Python and C implementations. In Python implementation either self.target.doctype or self.doctype are called. But in C implementation both are called.

----------
nosy: +serhiy.storchaka
stage:  -> patch review
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19176>
_______________________________________

From report at bugs.python.org  Sat Mar 21 11:28:37 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 10:28:37 +0000
Subject: =?utf-8?q?=5Bissue20132=5D_Many_incremental_codecs_don=E2=80=99t_handle_f?=
 =?utf-8?q?ragmented_data?=
In-Reply-To: <1388929738.44.0.851837204966.issue20132@psf.upfronthosting.co.za>
Message-ID: <1426933717.65.0.236666762253.issue20132@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka
stage:  -> patch review
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20132>
_______________________________________

From report at bugs.python.org  Sat Mar 21 11:55:09 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Mar 2015 10:55:09 +0000
Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in
 posixmodule
In-Reply-To: <1426910260.04.0.848728652838.issue23524@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZXQJHm+ZH03gOQ5Ob=0=cjkdgUqkJL7vBTbTmKth80sw@mail.gmail.com>


STINNER Victor added the comment:

I will try to take a look next week. If not, ping me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23524>
_______________________________________

From report at bugs.python.org  Sat Mar 21 11:56:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 10:56:20 +0000
Subject: [issue22619] Possible implementation of negative limit for traceback
 functions
In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za>
Message-ID: <1426935380.83.0.130779935988.issue22619@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I proposed changed patch. It needs a review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22619>
_______________________________________

From report at bugs.python.org  Sat Mar 21 12:00:07 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Mar 2015 11:00:07 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1426903637.17.0.749122265922.issue23571@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbB_G68GU0cm2k7E6mDTLXLDzbbfV=VeugNc7qzhfetow@mail.gmail.com>


STINNER Victor added the comment:

Serhiy was right: we should mention the name of the function in the
exception. In the Django traceback, it's not easy to guess what raised the
SystemError.

Ok to mention the change in What's New in Python 3.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Sat Mar 21 12:06:08 2015
From: report at bugs.python.org (Alexey Kazantsev)
Date: Sat, 21 Mar 2015 11:06:08 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
In-Reply-To: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>
Message-ID: <1426935968.17.0.641164771301.issue23720@psf.upfronthosting.co.za>


Alexey Kazantsev added the comment:

Ok, even assuming that all module globals are in circular reference starting with python 3.4, here is another example without using the globals:

Brief description:
v holds reference to d
a.v = v
b.d = d
Now when we form a circular reference a <-> b, the destructor order becomes wrong for v and d.

----------
resolution: rejected -> 
status: closed -> open
Added file: http://bugs.python.org/file38621/bug2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Sat Mar 21 12:21:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 11:21:17 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
In-Reply-To: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>
Message-ID: <1426936877.41.0.171294588015.issue23720@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is a cycle for every class with a method.

>>> class A:
...     def __del__(self): pass
... 
>>> A.__del__.__globals__['A']
<class '__main__.A'>

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Sat Mar 21 12:32:39 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Mar 2015 11:32:39 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1426937559.7.0.287217929024.issue23571@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Instead of an assert(), you could use Py_FatalError() at the end of _Py_CheckFunctionResult().

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Sat Mar 21 12:38:04 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 21 Mar 2015 11:38:04 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
In-Reply-To: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>
Message-ID: <1426937884.33.0.147659895025.issue23720@psf.upfronthosting.co.za>


Martin Panter added the comment:

There is a cycle involving the class object, but I don?t think there is a cycle involving the instance objects this time.

However, I wonder if __del__() is meant to be called in any particular order anyway. What?s to stop the garbage collector itself from creating a temporary reference to the Device instance, destroying the Vector instance, which invokes Vector.__del__(), and finally destroying the temporary reference to the Device instance?

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Sat Mar 21 12:41:09 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Mar 2015 11:41:09 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
In-Reply-To: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>
Message-ID: <1426938069.12.0.121481760982.issue23720@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Alexey, you're right that in this case (bug2.py) the cyclic GC is a bit less friendly than it was. It's not obvious there's a way to change that without introduce a lot of complexity. I'll try to take a look some day, although others may help too :-)

That said, my advice in msg238680 still holds. When you're writing a Python wrapper around a C or C++ library with well-defined ownership relationships, I think you should enforce those in the Python wrapper as well (that's my experience with llvmlite, anyway).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Sat Mar 21 12:41:23 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Mar 2015 11:41:23 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
In-Reply-To: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>
Message-ID: <1426938083.83.0.896968459293.issue23720@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Sat Mar 21 12:50:34 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 11:50:34 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
In-Reply-To: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>
Message-ID: <1426938634.48.0.48806962226.issue23720@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> There is a cycle involving the class object, but I don?t think there is a cycle involving the instance objects this time.

It is.

>>> a = A()
>>> a.__class__.__del__.__globals__['a']
<__main__.A object at 0xb702230c>

And all objects referenced from user class or module level instance of user class are in a cycle. This problem can cause issues such as issue17852.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Sat Mar 21 12:55:08 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 21 Mar 2015 11:55:08 +0000
Subject: [issue23042] ctypes module doesn't build on FreeBSD,
 RHEL (x86) - Undefined symbol "ffi_call_win32"
In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za>
Message-ID: <1426938908.43.0.473787731787.issue23042@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

@koobs: I was just looking at the 3.2.1 code where it still looks like ffi_call_win32() gets called even on non-Win32 platforms.

That said, it's possible that ffi_call_win32() is indeed defined on other platforms than Win32 as well in 3.2.1 - after all, it just implements a particular calling method. I haven't checked that or actually tried compiling _ctypes with 3.2.1.

Perhaps we could try switch to 3.2.1 and then check the buildbots for possible issues ?!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23042>
_______________________________________

From report at bugs.python.org  Sat Mar 21 12:55:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 21 Mar 2015 11:55:39 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
In-Reply-To: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>
Message-ID: <1426938939.47.0.439017446185.issue23720@psf.upfronthosting.co.za>


Martin Panter added the comment:

But in the case of bug2.py, ?a? is a variable inside main(), not a global variable.

BTW I take back my second paragraph questioning the whole order thing; I clearly didn?t think that one through.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Sat Mar 21 13:07:20 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 21 Mar 2015 12:07:20 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1426939640.3.0.018729780385.issue23722@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I like the change, but even though the current behaviour is arguably buggy (and certainly undesirable) the fix does introduce a new class level attribute that is visible during execution of Python level code.

Perhaps it would be worth rolling this change into PEP 487 and documenting the new transient namespace entry as __classcell__?

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23722>
_______________________________________

From report at bugs.python.org  Sat Mar 21 13:39:25 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 12:39:25 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
In-Reply-To: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>
Message-ID: <1426941565.36.0.00297729026688.issue23720@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, in bug2.py we have different cycle.

a ? b
?   ?
v ? d

a and b are in a cycle, and therefore v and d are in cycle. I think that in such case v always should be destroyed before d, independently of a cycle that refers them. And this is the same situation, as for io classes. A TextIOWrapper object refers a BufferedWriter object, a BufferedWriter object refers a FileIO object. and some cycle refers a TextIOWrapper object. As a result a FileIO object can be closed before a TextIOWrapper object or a BufferedWriter object flush its buffer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Sat Mar 21 13:50:40 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 21 Mar 2015 12:50:40 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426942240.14.0.456640812252.issue22516@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

>From a general philosophical perspective, I share Steve's view - the vast majority of potential CPython users don't want to be consuming upstream Python themselves, they want to be getting it from a redistributor.

This has nothing to do with the quality of the software itself, and everything to do with the fact that the open source meta-experience is tailored towards DIY co-collaboration, rather than producing a streamlined and completely hassle free customer experience for a given problem domain. For education, the Raspberry Pi foundation will be a better supplier than us, for data analysis, Enthought or Continuum Analytics, for Linux system management, the relevant Linux distributor.

For Windows at the moment the default supported redistribution choice is going to be ActiveState (that's certainly the one we used when I used to do professional Windows based Python development), but our upstream relationship there isn't as good as the ones we have the Linux distributors or the data analysis focused redistributors.

As Steve says, that leaves the upstream Windows installers trying to fulfil two different roles - both being something which users can install purely for their own use *and* being suitable for a corporate IT department to incorporate into a Standard Operating Environment. At the moment it's more the latter, which is also fine for users with full administrative control over their own system, but no good for restricted corporate systems.

The immediate workaround is to use the Anaconda distribution from Continuum Analytics in such cases, even if you don't need the data analysis components.

In terms of consistency with what we do on the POSIX side, the case can definitely be made that "System Python" is the right default behaviour for upstream.

The "Python-as-a-library" use case is currently a problem on both POSIX and Windows, and PEP 432 goes into several of the reasons why. There are also a host of additional issues at least on POSIX related to building extension modules, and this is one of the big reasons Continuum Analytics don't use pip natively and use conda instead - getting extension module builds to work reliably cross-platform when running from a user directory is a genuinely hard problem even if you're just linking to C libraries, let alone if you might be linking to C++ and FORTRAN libraries as well. That's a large part of why conda is on my short list of possible language independent user level package management tools to consider proposing for use in Fedora: https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement (and it's the *only* platform independent one, since Nix doesn't work on Windows)

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sat Mar 21 13:59:14 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 21 Mar 2015 12:59:14 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426942754.16.0.00143041999091.issue22516@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Short version of the above: I personally think we should be focusing on addressing the "system Python" and "Python as a library" cases upstream, as we're the only ones that can do that.

Solving the latter problem well then also sets the baseline for user focused installations, as those are then just a case of installing upstream CPython as if you were going to embed it in a larger application, and then just using it instead of embedding it.

For user focused cases, a good end user oriented solution will often bring in additional libraries targeted towards relevant problem domains. ActiveState does do that for Windows by bringing in additional modules like pywin32 and various others, but (as far as I am aware) we don't have anyone from there active on distutils-sig the way we do with Enthought, Continuum Analytics & the Linux distros. Assuming they have a booth at PyCon next month, I should probably swing by and ask the Komodo IDE folks about that...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sat Mar 21 14:33:51 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 21 Mar 2015 13:33:51 +0000
Subject: [issue23731] Implement PEP 488
Message-ID: <1426944831.0.0.593089874415.issue23731@psf.upfronthosting.co.za>


New submission from Brett Cannon:

https://www.python.org/dev/peps/pep-0488/

----------
assignee: brett.cannon
components: Interpreter Core
messages: 238799
nosy: brett.cannon
priority: release blocker
severity: normal
stage: test needed
status: open
title: Implement PEP 488
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23731>
_______________________________________

From report at bugs.python.org  Sat Mar 21 14:43:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 13:43:42 +0000
Subject: [issue22619] Possible implementation of negative limit for traceback
 functions
In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za>
Message-ID: <1426945422.57.0.744675987118.issue22619@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Due to changes in issue17911 the patch no longer applied cleanly an should be rewritten. But changes in issue17911 are close to my patch. _tb_frame_lineno_iter matches walk_tb and _stack_frame_lineno_iter matches walk_stack. So new patch is simpler.

----------
nosy: +rbcollins
Added file: http://bugs.python.org/file38622/traceback_negative_limit_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22619>
_______________________________________

From report at bugs.python.org  Sat Mar 21 14:55:28 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 21 Mar 2015 13:55:28 +0000
Subject: [issue23723] Provide a way to disable bytecode staleness checks
In-Reply-To: <1426875282.27.0.254210392532.issue23723@psf.upfronthosting.co.za>
Message-ID: <1426946128.1.0.594059697689.issue23723@psf.upfronthosting.co.za>


Brett Cannon added the comment:

What Greg said. =) Basically it would allow those who know what they are doing to cut out a stat call per load. I suspect anyone deploying to a server is in a similar situation where they are not actively editing the code once deployed, and so saving on the startup of a new process (probably most beneficial in a CI situation).

I might also simply refactor the importlib loader code to make this at least possible for someone to implement without doing the work for them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23723>
_______________________________________

From report at bugs.python.org  Sat Mar 21 14:56:04 2015
From: report at bugs.python.org (koobs)
Date: Sat, 21 Mar 2015 13:56:04 +0000
Subject: [issue23042] ctypes module doesn't build on FreeBSD,
 RHEL (x86) - Undefined symbol "ffi_call_win32"
In-Reply-To: <1418416859.8.0.212660740366.issue23042@psf.upfronthosting.co.za>
Message-ID: <1426946164.94.0.723037039966.issue23042@psf.upfronthosting.co.za>


koobs added the comment:

@marc I took a look at the code upstream and it does indeed appear to be the same. It was introduced in 3.1 [1].

I cant explain however how or why our Python ports work with libffi 3.2.1.

See msg238767 for a link to another similar (same?) issue, with failure of OSX on 3.2.1 (building libffi, not python)

[1] https://github.com/atgreen/libffi/commit/e1911f78df113ca58738b66089a070d4cf747de7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23042>
_______________________________________

From report at bugs.python.org  Sat Mar 21 14:58:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 13:58:04 +0000
Subject: [issue23360] Content-Type when sending data with urlopen()
In-Reply-To: <1422794612.5.0.505084736818.issue23360@psf.upfronthosting.co.za>
Message-ID: <1426946284.3.0.165774455366.issue23360@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23360>
_______________________________________

From report at bugs.python.org  Sat Mar 21 15:02:55 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 21 Mar 2015 14:02:55 +0000
Subject: [issue23732] Update porting HOWTO about new -b semantics
Message-ID: <1426946575.09.0.666027898536.issue23732@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Thanks to http://bugs.python.org/issue23681 we now have a better story about helping people find int/bytes comparison issues. The docs for Python 3.5 -- but not Python 3.4! -- should get updated to point out this change.

----------
assignee: brett.cannon
components: Documentation
messages: 238803
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Update porting HOWTO about new -b semantics
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23732>
_______________________________________

From report at bugs.python.org  Sat Mar 21 15:03:47 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 21 Mar 2015 14:03:47 +0000
Subject: [issue23733] Update porting HOWTO for bytes interpolation
Message-ID: <1426946627.25.0.962328562695.issue23733@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The porting HOWTO for Python 3.5 doesn't mention that bytes interpolation will exist.

----------
assignee: brett.cannon
components: Documentation
messages: 238804
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Update porting HOWTO for bytes interpolation
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23733>
_______________________________________

From report at bugs.python.org  Sat Mar 21 15:06:40 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Mar 2015 14:06:40 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <20150321140637.11908.45119@psf.io>


Roundup Robot added the comment:

New changeset f30a5f6a665c by Victor Stinner in branch 'default':
Issue #23571: _Py_CheckFunctionResult() now gives the name of the function
https://hg.python.org/cpython/rev/f30a5f6a665c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Sat Mar 21 15:08:15 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Mar 2015 14:08:15 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1426946895.33.0.525443941524.issue23571@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I believe that this patch exposes some subtle bugs in Django (see https://gist.github.com/berkerpeksag/8b8dbe594eb1a1c51275) and it would be great to add a note for third party libraries.

Berker, can you please rerun your test with my new commit to check if you see the function error in the error?

(I didn't update the doc yet, not investigated Antoine's suggestion, I will do that later.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Sat Mar 21 15:12:02 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Mar 2015 14:12:02 +0000
Subject: [issue23723] Provide a way to disable bytecode staleness checks
In-Reply-To: <1426875282.27.0.254210392532.issue23723@psf.upfronthosting.co.za>
Message-ID: <1426947122.06.0.600831939041.issue23723@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Can you please provide timing numbers?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23723>
_______________________________________

From report at bugs.python.org  Sat Mar 21 15:16:52 2015
From: report at bugs.python.org (Paul Moore)
Date: Sat, 21 Mar 2015 14:16:52 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426947412.03.0.407035504041.issue22516@psf.upfronthosting.co.za>


Paul Moore added the comment:

One implication of Nick's (and Steve's) position seems to me that we don't view per-user installs as a key aspect of the python.org installers. And yet the impression I get of the direction that the 3.5 installers is taking seems to contradict that - there's a definite feel that we're expecting per-user installs to be more the norm.

I think that until viable distribution channels exist, we have to accept that almost all Windows users *need* the python.org installers, regardless of their intended usage.

On Windows, at the moment, conda/enthought are entirely viable distributions, but focused on data analysis. This does have downsides for other types of user - the conda package manager largely only covers data analysis tools, and while mixing pip and conda works, it's not a core use case for the distribution and there are rough edges. I've tried using Anaconda briefly for non-data science uses, and it's a somewhat frustrating experience - not one I'd be comfortable directing new non-scientific users at.

>From checking the website, ActiveState free edition is for non-commercial use only, which likely precludes use by most of the people who want to use the python.org installer in their locked-down environments (if they can't get admin rights, they almost certainly won't be able to get an ActivePython license).

So, like it or not, until more generic free-for-commercual-use distributions of Python exist, I think we need to consider Windows users without admin rights as part of the core audience for the python.org installers.

Steve's changes to the 3.5 installer make this an entirely reasonable position. I see no need to provide backported solutions - it *is* reasonable for python.org to say "if you want improvements like this, you should choose the latest release".

Regarding the OP's issue, I think "fixed in Python 3.5" remains a fair answer. It's not a case of closing the issue without addressing the basic problem. It's more that it's fixed in the only version we'd ever fix it in (3.5). AIUI, the only thing that may still need admin rights is installing the required C runtime, which as a system component *has* to be done by an admin. That's a Windows issue, though, not a Python one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sat Mar 21 15:34:06 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 14:34:06 +0000
Subject: [issue23723] Provide a way to disable bytecode staleness checks
In-Reply-To: <1426875282.27.0.254210392532.issue23723@psf.upfronthosting.co.za>
Message-ID: <1426948446.06.0.69223622634.issue23723@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Wouldn't zipimport provide better performance? If bytecode generation is thoroughly controlled, could you collect your .pyc files in a ZIP file?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23723>
_______________________________________

From report at bugs.python.org  Sat Mar 21 15:47:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 14:47:02 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1426949222.36.0.0603405214116.issue23571@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Non-Linux buildbots failed.

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/2798/steps/test/logs/stdio
======================================================================
FAIL: test_return_result_with_error (test.test_capi.CAPITest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_capi.py", line 206, in test_return_result_with_error
    self.assertIn(b'_Py_CheckFunctionResult: Assertion', err)
AssertionError: b'_Py_CheckFunctionResult: Assertion' not found in b'2015-03-21 10:28:29.114 defaults[68384:903] \nThe domain/default pair of (com.apple.CrashReporter, DialogType) does not exist\nAssertion failed: (!err_occurred), function _Py_CheckFunctionResult, file Objects/abstract.c, line 2088.\nFatal Python error: Aborted\n\nCurrent thread 0x00007fff71296cc0 (most recent call first):\n  File "<string>", line 6 in <module>'

----------------------------------------------------------------------
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/5906/steps/test/logs/stdio
======================================================================
FAIL: test_return_result_with_error (test.test_capi.CAPITest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_capi.py", line 206, in test_return_result_with_error
    self.assertIn(b'_Py_CheckFunctionResult: Assertion', err)
AssertionError: b'_Py_CheckFunctionResult: Assertion' not found in b'2015-03-21 10:28:29.114 defaults[68384:903] \nThe domain/default pair of (com.apple.CrashReporter, DialogType) does not exist\nAssertion failed: (!err_occurred), function _Py_CheckFunctionResult, file Objects/abstract.c, line 2088.\nFatal Python error: Aborted\n\nCurrent thread 0x00007fff71296cc0 (most recent call first):\n  File "<string>", line 6 in <module>'

----------------------------------------------------------------------

Why this assert is needed? Why not always raise SystemError?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Sat Mar 21 16:53:45 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 15:53:45 +0000
Subject: [issue23360] Content-Type when sending data with urlopen()
In-Reply-To: <1422794612.5.0.505084736818.issue23360@psf.upfronthosting.co.za>
Message-ID: <1426953225.8.0.253757472352.issue23360@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The documentation looks contradictory. "The *data* argument must be", but "The *data* argument may also be". "must be a bytes object", but "If *data* is a buffer".

Why not write just "The data argument must be a bytes-like object, an iterable of bytes-like objects, or None"? It doesn't depend if url is a string or a Request object.

AFAIK the data argument of Request can be an iterable of bytes-like objects in additional to a bytes-like object or None.

The note about the application/x-www-form-urlencoded format is applied not only to a bytes object, but to an iterable of bytes-like objects too. I.e. to any acceptable value except None.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23360>
_______________________________________

From report at bugs.python.org  Sat Mar 21 17:25:11 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Mar 2015 16:25:11 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <20150321162508.30734.61550@psf.io>


Roundup Robot added the comment:

New changeset 970f33dff5ca by Victor Stinner in branch 'default':
Issue #23571: Fix test_capi
https://hg.python.org/cpython/rev/970f33dff5ca

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Sat Mar 21 17:27:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 16:27:02 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1426955222.71.0.163947594953.issue23602@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

>>> from fractions import Fraction as F
>>> format(F(4, 27), 'f')
'0.1481481'
>>> format(F(4, 27), '.1f')
'0.2'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Sat Mar 21 17:29:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Mar 2015 16:29:57 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1426949222.36.0.0603405214116.issue23571@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYf2aH93fxH+qACdFg7Kork+27iwQg4Wbc0AqY7DKQGBg@mail.gmail.com>


STINNER Victor added the comment:

Serhiy Storchaka added the comment:
> Why this assert is needed? Why not always raise SystemError?

A SystemError exception may be ignored by a generic "except Exception:
pass" or logged at debug level at then ignored.

I consider that the bug is important, and that you must fix it. The
debug mode is to detect bugs earlier, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Sat Mar 21 17:46:53 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 21 Mar 2015 16:46:53 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426956413.91.0.162902074408.issue22516@psf.upfronthosting.co.za>


Steve Dower added the comment:

Paul has basically summed up the pragmatism beats purity side of the argument. Whether we like it or not, users are mostly coming to python.org for their installer, and we need to support that.

That said, we can do some things to support all three cases once we acknowledge that they exist and identify who they're for. For example, an all users install could become an advanced option, which will move most users into per-user installs. We could also release a plain zip file of the installed layout and clearly mark it as being for app bundles and not a portable install for users. There are changes to getpath and the registry lookup that will better serve non-system installs, though we really need PEP 432 for that to be feasible.

Some bigger changes I wouldn't mind would be renaming python.exe to python35.exe and then py.exe to python.exe, which would let users have a system Python that interacts well with registered per-user versions and shebang lines. These largely depend on whether we've got the stomach to be so dramatic :) With 3.5 beta coming up so soon, we may be better to avoid rocking the boat now and look towards 3.6, but maybe this is more urgent than that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sat Mar 21 18:05:49 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 17:05:49 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1426957549.28.0.411172634494.issue23571@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This exception or assertion is triggered by the bug in CPython or in an extension. CPython developer uses release and debug builds of CPython and can get both exception or assertion. An extension developer usually uses release build of CPython with release and debug builds of an extension and can't get an assertion in CPython. Common Python user uses release builds of CPython and extensions and can only report about an exception. So this assertion can be used only in CPython developing and doesn't help to catch a bug in extensions. But an assertion itself provides less information than an exception. Debug build is less informative than release build.

May be add a runtime flag to control the reaction on system errors? If it set, all raised SystemError will be converted to fatal errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Sat Mar 21 18:07:33 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 21 Mar 2015 17:07:33 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426957653.78.0.00746979942714.issue22516@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

python35.exe follows things like pip so +1.  py.exe to python.exe -1 from me, how about pylaunch.exe as it's explicit?  As for urgency in the Python world Windows is and always has been the poor relation compared to *nix, so I say let's bite the bullet and get on with it.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sat Mar 21 18:10:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 17:10:00 +0000
Subject: [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1426957800.13.0.862016399703.issue17232@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage: patch review -> needs patch
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17232>
_______________________________________

From report at bugs.python.org  Sat Mar 21 18:13:36 2015
From: report at bugs.python.org (Paul Moore)
Date: Sat, 21 Mar 2015 17:13:36 +0000
Subject: [issue23657] Don't do isinstance checks in zipapp
In-Reply-To: <1426258210.85.0.503105299924.issue23657@psf.upfronthosting.co.za>
Message-ID: <1426958016.64.0.974239668251.issue23657@psf.upfronthosting.co.za>


Paul Moore added the comment:

Updated patch with fixes for review comments. I did remove the tests for the exact error messages, as testing for a non-zero exit code was actually what I was trying to do, and I found a better way of doing that.

----------
Added file: http://bugs.python.org/file38623/duck_typed_zipapp.v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23657>
_______________________________________

From report at bugs.python.org  Sat Mar 21 18:20:04 2015
From: report at bugs.python.org (Paul Moore)
Date: Sat, 21 Mar 2015 17:20:04 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426958404.51.0.84524358598.issue22516@psf.upfronthosting.co.za>


Paul Moore added the comment:

Personally, I'd like to have 3.5 be the release that changes to using "Program Files" as the default install, and offers a per-user install to Appdata. I suspect there will be enough fallout from that change to keep us busy. Let's look to 3.6 for major renamings of the executables (if ever).

It should be noted that making python.exe be the launcher could potentially break a lot of things pretty horribly - virtualenv and the launcher itself are the ones that immediately come to mind.

Having said that, I have no objection to having both python35.exe and python.exe, but for 3.5 they should both be the same actual executable. In practice I doubt Windows users will use python35.exe, as there's no tradition of versioned executables there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sat Mar 21 18:21:22 2015
From: report at bugs.python.org (Paul Moore)
Date: Sat, 21 Mar 2015 17:21:22 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426958482.86.0.543484292572.issue22516@psf.upfronthosting.co.za>


Paul Moore added the comment:

Regarding the "poor relation" argument, I'd see that as the other way round. We don't have the resources to deal with major breakages, so we should be relatively cautious.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sat Mar 21 18:40:16 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 21 Mar 2015 17:40:16 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426959616.94.0.795467262667.issue22516@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I'm concerned about being overcautious so that nothing ever happens.  Do something, break it, fix it.  If you delay all you do is put off the fix.  Plus I've every confidence in our Windows developers to just do the right thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sat Mar 21 18:53:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 17:53:35 +0000
Subject: [issue15836] unittest assertRaises should verify excClass is actually
 a BaseException class
In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za>
Message-ID: <1426960415.31.0.246059329992.issue15836@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm +0.5 for the variant suggested by Berker and Ezio.

Do you have time to look at the patch Michael? I could commit modified patch (there is one defect in tests).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15836>
_______________________________________

From report at bugs.python.org  Sat Mar 21 19:03:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 18:03:22 +0000
Subject: [issue17840] base64_codec uses assert for runtime validity checks
In-Reply-To: <1366875650.57.0.151905786577.issue17840@psf.upfronthosting.co.za>
Message-ID: <1426961002.91.0.471123594394.issue17840@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17840>
_______________________________________

From report at bugs.python.org  Sat Mar 21 19:47:31 2015
From: report at bugs.python.org (Eugene Toder)
Date: Sat, 21 Mar 2015 18:47:31 +0000
Subject: [issue23726] Don't enable GC for classes that don't add new fields
In-Reply-To: <1426883157.79.0.718081112041.issue23726@psf.upfronthosting.co.za>
Message-ID: <1426963651.96.0.00465732149909.issue23726@psf.upfronthosting.co.za>


Changes by Eugene Toder <eltoder at gmail.com>:


Added file: http://bugs.python.org/file38624/class_gc2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23726>
_______________________________________

From report at bugs.python.org  Sat Mar 21 19:51:48 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 21 Mar 2015 18:51:48 +0000
Subject: [issue23731] Implement PEP 488
In-Reply-To: <1426944831.0.0.593089874415.issue23731@psf.upfronthosting.co.za>
Message-ID: <1426963908.73.0.00517153452076.issue23731@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23731>
_______________________________________

From report at bugs.python.org  Sat Mar 21 19:55:59 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 21 Mar 2015 18:55:59 +0000
Subject: [issue23723] Provide a way to disable bytecode staleness checks
In-Reply-To: <1426875282.27.0.254210392532.issue23723@psf.upfronthosting.co.za>
Message-ID: <1426964159.98.0.850945140024.issue23723@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

We already use zipimport for most production deployments.  It works well.  We've modified our own zipimport to ignore timestamps as keeping them in sync between pyc and py files in the zip files own timestamps is painful.  Unfortunately the stdlib zipimport actually checks pyc timestamps against py files in the .zip file in 3.4 and 2.7 (https://hg.python.org/cpython/file/e8878579eb68/Modules/zipimport.c#l1187 mtime is checked, despite a comment in there in 3.4 suggesting it is probably pointless).  Changing that is a separate issue (I'll go open one).

Where this hurts us the most is in our build system when not building a final production zipped up binary (which would take as long as loading all of the py and pyc files would and would prevent iterative development).  Our py files and pyc files are located on a read only build artifact object store.  As a mounted filesystem it does not have a POSIX concept of file mtime at all (and never will).

When you're using a readonly filesystem of build time generated .py code without the concept of an mtime you really really want to tell Python to trust the build system and assume pyc files it finds match the corresponding py files.  Or your large application/test start up time really suffers.

In our use case, it is on the order of a 30% startup time improvement to use precompiled pyc files for our generated code py files (a ton of protobuf python modules) on a large application.

Most people are likely not in this situation because they are just lowly individuals operating on a simple writable posix filesystem in front of them. But when it matters, it really matters. People should be able to tell Python "trust me, i know what I'm doing" when it comes to compiled code loading.  It is easy enough to modify compile to write a "never verify this" magic timestamp into a pyc.  (I'd get more creative and use a value other than all 0s or 1s; pick the release date of the first version Python as your magic timestamp for example; nothing is likely to accidentally end up with that date in it)

That's all this issue is asking for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23723>
_______________________________________

From report at bugs.python.org  Sat Mar 21 19:59:07 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 21 Mar 2015 18:59:07 +0000
Subject: [issue23734] zipimport should not check pyc timestamps against zipped
 py files
Message-ID: <1426964347.09.0.21067648462.issue23734@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

The zipimport module checks the timestamp of a pyc file loaded from the zip file against the timestamp of a corresponding py file in the zip if any.  This seems pointless.  By the time someone has created a zip file for zipimport they should have guaranteed that the pyc's are fresh or not have put them into the zip file at all (wasteful).

https://hg.python.org/cpython/file/e8878579eb68/Modules/zipimport.c#l1187

There is a comment in the code alluding to this, but the mtime check is still done right above.

----------
components: Extension Modules
messages: 238824
nosy: gregory.p.smith
priority: low
severity: normal
status: open
title: zipimport should not check pyc timestamps against zipped py files
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23734>
_______________________________________

From report at bugs.python.org  Sat Mar 21 20:02:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 19:02:35 +0000
Subject: [issue23350] Content-length is incorrect when request body is a list
 or tuple
In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za>
Message-ID: <1426964555.31.0.69348530943.issue23350@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are two issues. The one is that calculated Content-Length is not correct for lists, tuples, and other types (such as deque or array.array). The right solution is to calculate size using a technique used in urllib. Content-Length shouldn't be calculated for lists, tuples, and other non-bytes-compatible sequences. This is a bug, and the patch should be applied to all maintained releases.

The second issue is feature request. Allow calculating Content-Length for lists and tuples.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23350>
_______________________________________

From report at bugs.python.org  Sat Mar 21 20:12:54 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Mar 2015 19:12:54 +0000
Subject: [issue23723] Provide a way to disable bytecode staleness checks
In-Reply-To: <1426875282.27.0.254210392532.issue23723@psf.upfronthosting.co.za>
Message-ID: <1426965174.41.0.952037372546.issue23723@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

That sounds kind of reasonable, but how are we supposed to document this? Or is this only a "secret backdoor" for people in the know?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23723>
_______________________________________

From report at bugs.python.org  Sat Mar 21 20:24:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Mar 2015 19:24:05 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1426957549.28.0.411172634494.issue23571@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZz2RpjqkJcqiRZjCQk66vRY1qdhoyVFVcnTf_q39FEtQ@mail.gmail.com>


STINNER Victor added the comment:

Le 21 mars 2015 18:05, "Serhiy Storchaka" <report at bugs.python.org> a ?crit :
> But an assertion itself provides less information than an exception.
Debug build is less informative than release build.

I like Antoine's idea to replace the assertion with Py_FatalError() in
debug mode.

I'm more concerned by bugs in Python itself. A fatal error/assertion should
be noticed quickly on buildbots which compile python in debug mode.

It's just fine if other people use the release mode and get an exception.

> May be add a runtime flag to control the reaction on system errors? If it
set, all raised SystemError will be converted to fatal errors.

It's already what I do when running Python test suite with pyfailmalloc. I
modify manually SystemError constructor in the C code. A flag may help, but
you have to know that many tests expect SystemError (I don't remember which
ones).

Victor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Sat Mar 21 20:25:42 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 21 Mar 2015 19:25:42 +0000
Subject: [issue23097] unittest can unnecessarily modify sys.path (and with the
 wrong case)
In-Reply-To: <1419151339.28.0.203745779889.issue23097@psf.upfronthosting.co.za>
Message-ID: <1426965942.3.0.203634528597.issue23097@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23097>
_______________________________________

From report at bugs.python.org  Sat Mar 21 20:39:07 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Mar 2015 19:39:07 +0000
Subject: [issue15836] unittest assertRaises should verify excClass is actually
 a BaseException class
In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za>
Message-ID: <1426966747.58.0.845295367218.issue15836@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15836>
_______________________________________

From report at bugs.python.org  Sat Mar 21 20:40:22 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 21 Mar 2015 19:40:22 +0000
Subject: [issue23126] Add Python hook function to replace NameError
In-Reply-To: <1419784501.24.0.582986414066.issue23126@psf.upfronthosting.co.za>
Message-ID: <1426966822.03.0.395898928643.issue23126@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

See the thread starting here https://mail.python.org/pipermail/python-ideas/2014-December/030521.html

----------
nosy: +BreamoreBoy
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23126>
_______________________________________

From report at bugs.python.org  Sat Mar 21 20:40:36 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Mar 2015 19:40:36 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
In-Reply-To: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>
Message-ID: <1426966836.96.0.902964377074.issue23720@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Can this be closed as not-a-bug.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Sat Mar 21 20:44:58 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 21 Mar 2015 19:44:58 +0000
Subject: [issue23106] Remove smalltable from set objects
In-Reply-To: <1419378045.35.0.931278321867.issue23106@psf.upfronthosting.co.za>
Message-ID: <1426967098.73.0.978456987644.issue23106@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

My feeling is that this is worth doing for the code clarity alone but what do others think about it?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23106>
_______________________________________

From report at bugs.python.org  Sat Mar 21 20:46:57 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Mar 2015 19:46:57 +0000
Subject: [issue23729] Import ElementTree documentation for namespaces and XPath
In-Reply-To: <1426926572.78.0.5131365949.issue23729@psf.upfronthosting.co.za>
Message-ID: <1426967217.28.0.85296470179.issue23729@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Attaching a runnable version of the namespace demo to show that the code works.

----------
versions: +Python 2.7, Python 3.4
Added file: http://bugs.python.org/file38625/xml_namespace_demo.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23729>
_______________________________________

From report at bugs.python.org  Sat Mar 21 20:49:17 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 21 Mar 2015 19:49:17 +0000
Subject: [issue23075] Mock backport in 2.7 relies on implementation defined
 behavior
In-Reply-To: <1418860320.5.0.0748673104985.issue23075@psf.upfronthosting.co.za>
Message-ID: <1426967357.77.0.119396872971.issue23075@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Can we have a commit review please as this is such a simple patch.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23075>
_______________________________________

From report at bugs.python.org  Sat Mar 21 21:04:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 20:04:20 +0000
Subject: [issue23075] Mock backport in 2.7 relies on implementation defined
 behavior
In-Reply-To: <1418860320.5.0.0748673104985.issue23075@psf.upfronthosting.co.za>
Message-ID: <1426968260.1.0.48489834348.issue23075@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23075>
_______________________________________

From report at bugs.python.org  Sat Mar 21 21:05:37 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Mar 2015 20:05:37 +0000
Subject: [issue23075] Mock backport in 2.7 relies on implementation defined
 behavior
In-Reply-To: <1418860320.5.0.0748673104985.issue23075@psf.upfronthosting.co.za>
Message-ID: <20150321200534.70022.86154@psf.io>


Roundup Robot added the comment:

New changeset d0b497c86c60 by Serhiy Storchaka in branch '2.7':
Issue #23075: Whether __builtins__ is a module or a dict is undefined in
https://hg.python.org/cpython/rev/d0b497c86c60

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23075>
_______________________________________

From report at bugs.python.org  Sat Mar 21 21:09:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 20:09:30 +0000
Subject: [issue23075] Mock backport in 2.7 relies on implementation defined
 behavior
In-Reply-To: <1418860320.5.0.0748673104985.issue23075@psf.upfronthosting.co.za>
Message-ID: <1426968570.32.0.397683810013.issue23075@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Done. Thanks for raising it Mark.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23075>
_______________________________________

From report at bugs.python.org  Sat Mar 21 21:11:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 20:11:22 +0000
Subject: [issue23729] Import ElementTree documentation for namespaces and XPath
In-Reply-To: <1426926572.78.0.5131365949.issue23729@psf.upfronthosting.co.za>
Message-ID: <1426968682.98.0.844332890625.issue23729@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +eli.bendersky, scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23729>
_______________________________________

From report at bugs.python.org  Sat Mar 21 21:15:21 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Mar 2015 20:15:21 +0000
Subject: [issue23729] Import ElementTree documentation for namespaces and XPath
In-Reply-To: <1426926572.78.0.5131365949.issue23729@psf.upfronthosting.co.za>
Message-ID: <1426968921.44.0.901380729132.issue23729@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file38626/elementtree_doc2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23729>
_______________________________________

From report at bugs.python.org  Sat Mar 21 21:50:57 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 21 Mar 2015 20:50:57 +0000
Subject: [issue23021] Get rid of references to PyString in Modules/
In-Reply-To: <1418141104.02.0.91056311182.issue23021@psf.upfronthosting.co.za>
Message-ID: <1426971057.68.0.40820560866.issue23021@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

The only PyString that I could find left is in unicodedata.c.  I'm assuming that there is little point is preparing a patch for a one word change, is this correct?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23021>
_______________________________________

From report at bugs.python.org  Sat Mar 21 22:24:55 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 21 Mar 2015 21:24:55 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426973095.81.0.293079004612.issue22516@psf.upfronthosting.co.za>


Steve Dower added the comment:

Yeah, some of those are fairly ambitious, but at the same time, for the SOE use case we probably don't want the Program Files install at all - it would be a mix between System32 and CommonFiles, with the same environment issues you'd see on Linux. Program Files is better than SystemRoot, but doesn't really make sense for any of the three use cases.

When we can describe exactly who our installer is meant for, we'll be able to figure out what changes are needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sat Mar 21 22:29:39 2015
From: report at bugs.python.org (Paul Moore)
Date: Sat, 21 Mar 2015 21:29:39 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426973379.68.0.669054328604.issue22516@psf.upfronthosting.co.za>


Paul Moore added the comment:

Sorry, SOE?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sat Mar 21 22:55:50 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 21 Mar 2015 21:55:50 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426974950.1.0.988527639152.issue22516@psf.upfronthosting.co.za>


Steve Dower added the comment:

Sorry, Standard Operating Environment. I intended it as shorthand for the "as if it were shipped with the OS" case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sat Mar 21 22:59:40 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 21 Mar 2015 21:59:40 +0000
Subject: [issue13224] Change str(x) to return only the (qual)name for some
 types
In-Reply-To: <1319053532.35.0.636674659737.issue13224@psf.upfronthosting.co.za>
Message-ID: <1426975180.65.0.664234981012.issue13224@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13224>
_______________________________________

From report at bugs.python.org  Sat Mar 21 23:13:33 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 21 Mar 2015 22:13:33 +0000
Subject: [issue23729] Import ElementTree documentation for namespaces and XPath
In-Reply-To: <1426926572.78.0.5131365949.issue23729@psf.upfronthosting.co.za>
Message-ID: <1426976013.38.0.99339454508.issue23729@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for this improvement; documenting namespace behaviour is sorely needed.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23729>
_______________________________________

From report at bugs.python.org  Sat Mar 21 23:44:32 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 21 Mar 2015 22:44:32 +0000
Subject: [issue22246] add strptime(s, '%s')
In-Reply-To: <1408664936.57.0.427329646216.issue22246@psf.upfronthosting.co.za>
Message-ID: <1426977872.06.0.123352940994.issue22246@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

It's a comprehensive patch so can we have a formal review please.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22246>
_______________________________________

From report at bugs.python.org  Sat Mar 21 23:48:19 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 Mar 2015 22:48:19 +0000
Subject: [issue23668] Support os.
In-Reply-To: <1426908408.12.0.325845610332.issue23668@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYCHH8shQYPc_gZZ8iux-1yF7rGYupWES3R3bLbxKfxng@mail.gmail.com>


STINNER Victor added the comment:

Is _chsize_s() available on all Windows versions and all Visual Studio
(msvcrt) versions?
Le 21 mars 2015 04:26, "Steve Dower" <report at bugs.python.org> a ?crit :

>
> Steve Dower added the comment:
>
> Updated the patch, since there's been a lot of checkins.
>
> I also removed the pyconfig.h changes and updated the #ifdef in
> posixmodule.c to enable truncate/ftruncate and define PATH_HAVE_FTRUNCATE.
>
> And I know in the last review I said I'd switch to _Py_wopen(), but if I
> do that there's no way to avoid passing _O_CREAT, so I opted to stick with
> _wopen() and pass _O_NOINHERIT instead.
>
> Hopefully Reitveld handles this patch file. I'm sure I'm not doing
> anything differently from normal...
>
> ----------
> Added file: http://bugs.python.org/file38614/23668_3.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue23668>
> _______________________________________
>

----------
title: Support os.[f]truncate on Windows -> Support os.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23668>
_______________________________________

From report at bugs.python.org  Sat Mar 21 23:49:51 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 21 Mar 2015 22:49:51 +0000
Subject: [issue22659] SyntaxError in the configure_ctypes
In-Reply-To: <1413565915.5.0.655058689376.issue22659@psf.upfronthosting.co.za>
Message-ID: <1426978191.64.0.743376779055.issue22659@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Without more detail I very much doubt that anybody can help.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22659>
_______________________________________

From report at bugs.python.org  Sat Mar 21 23:53:12 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 21 Mar 2015 22:53:12 +0000
Subject: [issue23668] Support os.ftruncate on Windows
In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za>
Message-ID: <1426978392.14.0.335371729043.issue23668@psf.upfronthosting.co.za>


Steve Dower added the comment:

Yep, all the way back to VS 2005 and Windows 95. Not sure why it wasn't used previously (_chsize doesn't support 64-bit values, which is a reasonable reason to not use it).

----------
title: Support os. -> Support os.ftruncate on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23668>
_______________________________________

From report at bugs.python.org  Sat Mar 21 23:57:55 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 21 Mar 2015 22:57:55 +0000
Subject: [issue22610] test_ftplib fails with sem_init: Too many open files
In-Reply-To: <1413029908.66.0.757580851096.issue22610@psf.upfronthosting.co.za>
Message-ID: <1426978675.49.0.474589118358.issue22610@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

It's a simple patch so can we have a formal review please.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22610>
_______________________________________

From report at bugs.python.org  Sat Mar 21 23:58:28 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 21 Mar 2015 22:58:28 +0000
Subject: [issue22608] test_socket fails with sem_init: Too many open files
In-Reply-To: <1413026581.56.0.334221063135.issue22608@psf.upfronthosting.co.za>
Message-ID: <1426978708.49.0.0467622111865.issue22608@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

It's a simple patch so can we have a formal review please.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22608>
_______________________________________

From report at bugs.python.org  Sat Mar 21 23:58:50 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 21 Mar 2015 22:58:50 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426978730.99.0.519840233701.issue22516@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I agree the migration to Program Files & a different installer build process is more than ambitious enough for 3.5.

For the embedding case, it's not that it *can't* be done, it's just a PITA.

Perhaps for the per-user no-admin-rights needed case, we could direct folks to the big http://portablepython.com/ bundle as a vendor neutral all inclusive bulk distribution?

To be completely clear, I'm talking "invite Perica Zivkovic to become part of CPython release management and include Portable Python release timelines in the CPython release PEPs" levels of engagement. "Is Portable Python fully operational yet?" could become one of the key gating criteria for leaving the beta phase and entering the release candidate phase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sun Mar 22 00:01:48 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 21 Mar 2015 23:01:48 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426978908.56.0.185425339252.issue22516@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Along those lines, another option to consider would be offering to publish Portable Python from the python.org release pages in addition to publishing the less comprehensive CPython-only installers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sun Mar 22 00:05:46 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 21 Mar 2015 23:05:46 +0000
Subject: [issue23350] Content-length is incorrect when request body is a list
 or tuple
In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za>
Message-ID: <1426979146.24.0.077707886666.issue23350@psf.upfronthosting.co.za>


Martin Panter added the comment:

Technically I don?t think there is a bug. The documentation says [the] ?Content-Length header should be explicitly provided?, so if you don?t set it you could argue that you?re using the library wrong.

For this issue I think Demian was trying to add support (i.e. new feature) for implicit Content-Length with tuples and lists of bytes (or strings). He has also added support for iterables of Latin-1 encodable text strings.

What you are suggesting Serhiy sounds like a separate new feature to support bodies of arbitrary bytes-like objects (or lists or tuples of them). According to the documentation, only byte and Latin-1 text strings, file objects supporting stat(), and iterables are currently supported. It does not say, but before this patch I think the iterables had to be of bytes-like objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23350>
_______________________________________

From report at bugs.python.org  Sun Mar 22 00:08:43 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 21 Mar 2015 23:08:43 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426979323.95.0.94214140046.issue22516@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Larry,

Bringing you into this discussion as CPython 3.5 release manager - we're trying to figure out what role we'd like the CPython Windows installers to play in the Windows distribution ecosystem, and I raised the question of whether or not typical Windows based end users might be better off with a larger, more comprehensive bundle like Portable Python (which they can also run from a USB stick if they want to).

There's no specific urgency here - I just wanted to give you a heads up that the discussion was happening. It's not clear to me yet if this will go anywhere (if nothing else, even if we decided it was a plausible idea, it would still be conditional on someone offering to contact Perica Zivkovic to see if they were amenable to the concept, as well as someone offering to write the suggestion up as a full PEP and work through the necessary changes to PEP 101 release management), but I figured you should at least be aware of the possibility as RM.

----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sun Mar 22 00:13:12 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 21 Mar 2015 23:13:12 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426979592.61.0.25651641903.issue22516@psf.upfronthosting.co.za>


Steve Dower added the comment:

Also, I do have this topic on the language summit agenda, so I don't really want to lock anything down before then anyway, but this discussion has been good to flesh out some of the background and possibilities in advance of that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sun Mar 22 00:24:46 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 21 Mar 2015 23:24:46 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426980286.87.0.697749735167.issue22516@psf.upfronthosting.co.za>


Ned Deily added the comment:

Bringing an umbrella distribution into the CPython release process seems to me like a very big leap and would that requires very careful consideration.  It would introduce a whole load of other dependencies into our release process, i.e. that the third-party packages (e.g. numpy, et al) included in Portable Python would become gating factors and dependencies for CPython releases.  Frankly, I don't thing we want to go there.  I don't have an objection to referring to users to other distributions like Portable Python (or Anaconda or whatever) but actually bringing it into the release process would need a *lot* of careful thought and planning and co-ordination.  Sounds like an interesting discussion for the language summit.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sun Mar 22 00:26:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 21 Mar 2015 23:26:41 +0000
Subject: [issue22608] test_socket fails with sem_init: Too many open files
In-Reply-To: <1413026581.56.0.334221063135.issue22608@psf.upfronthosting.co.za>
Message-ID: <1426980401.17.0.678339928692.issue22608@psf.upfronthosting.co.za>


Martin Panter added the comment:

Maybe these patches work around the problem in these cases, but it sounds like the threading.Event class needs to grow a close() method or support the context manager protocol, rather than relying on the garbage collector to clean it up.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22608>
_______________________________________

From report at bugs.python.org  Sun Mar 22 00:34:59 2015
From: report at bugs.python.org (Mark Mikofski)
Date: Sat, 21 Mar 2015 23:34:59 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426980899.85.0.445748735138.issue22516@psf.upfronthosting.co.za>


Mark Mikofski added the comment:

WinPython and miniconda are more current distros than portable python, and they come in both 32 & 64bit flavors.

Portable python hasn't been updated recently and only offers 32 bit which is IMO worthless except for the bundle as app case, eg meld installer.

I was going to suggest the same - if python.org can't support local installs (sans admin rights) b/c people will always look to it for direction,  python.org should offer links to endorsed windows installer. I don't love it, but it will be familiar to windows users braving the open source world, similar to ruby which recommends winruby. Any endorsed distro **must** be built with msvc, so that all packages with extensions can be built. I don't care to support packages that depend on autotools.

Why can't msvcrt90.dll amd python27.dll be bundled into install directory? Seems to solve case #1 (for personal use) and #2 (bundled as app)? No admin rights required, just unzip. Why would you want to move python to program files? 

Case #3 would be swell, would windows ever do that? If we assume windows distros are akin to *nix them perhaps we need to push the --user or --home=~/.local options and virtualenv. That seems to be the way conda is going. Ruby rvm is more like that as well. Especially if we are going to force users to start using 3.5. What is Microsoft's official position on python. are they officially supporting python on windows? Seems like it with newest April's and vcforpython27.

BTW miniconda does not install all of the sci-data packages, only conda and python 2.7. works with pip and --home=~/.local scheme. Is this the future for windows users? We should reach a consensus I think

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sun Mar 22 00:46:17 2015
From: report at bugs.python.org (Paul Moore)
Date: Sat, 21 Mar 2015 23:46:17 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426981577.02.0.287495424301.issue22516@psf.upfronthosting.co.za>


Paul Moore added the comment:

I agree with Ned, this sounds like a significant change. In particular, Portable Python seems to currently only offer 3.2.5 at the moment. And it's not at all clear to me whether it's a 32-bit or a 64-bit version (but I suspect the former). One thing I'd want to understand would be why 3.4.3 and 64-bit versions weren't available. Is it just manpower (and if so, what manpower commitments would be needed from python-dev) or are there more fundamental issues with the Portable Python stack holding up the move to the latest version?

I'm also concerned that we should ensure that any distribution we bless is compatible with pip and packages installed on PyPI. I would be very concerned, for example, if we were moving towards a situation where wheels for Windows were *not* usable by the average user. (That specifically means that all commonly used distributions used the same CRT as the python.org builds, that distributions we recommend play well with pip, etc).

None of this is intended as a criticism of any of the distributions. I just think that actually *recommending* them in place of the python.org installers implies a certain level of assurance from python-dev - and we don't have any process in place to actually validate the distributions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sun Mar 22 01:03:34 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 22 Mar 2015 00:03:34 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426982614.49.0.212106125622.issue22516@psf.upfronthosting.co.za>


Steve Dower added the comment:

> miniconda does not install all of the sci-data packages, only conda and python 2.7

miniconda is actually a tool that gives you the "conda" command, which can be used to install Python 2.6, 2.7, 3.3 or 3.4, 32 or 64-bit and a huge range of compatible packages. When you install it you also get a usable version of Python, but you don't have to use it. Anaconda is exactly the same thing but with a selection of packages predownloaded and installed - again, you can use the conda command to install more.

> What is Microsoft's official position on python. are they officially supporting python on windows?

Microsoft doesn't distribute Python as part of Windows or provide any support for users, though we do provide some engineering support (i.e. me) and some low-cost efforts (such as the compiler pack, again, mostly me). There's a really high bar for "supporting" a product, and especially for shipping it to users who have not opted into it, as well as legitimate concerns about documentation/support, entry points, threat vectors, updates, patching, and probably more (when does Windows switch to 3.6? Honestly, it can probably never happen...). While it may happen eventually, I think we're better off having an installer that any sysadmin can use to make it as-if it were shipped.

The problem with that is then you can't use that installer for your app, for the same reason that a Linux application can't arbitrarily replace the system Python. You can't even ask your users to install it, since they may not have permissions (ignoring the CRT update issue for now - that will be resolved in time). This is where we need a way for a user to install Python-as-an-app (one install-per version-per-user) and also for an installer to include Python-as-a-library (one install-per app).

It may just be that we need three separate installers:

* EXE launcher for Python-as-an-app installations
* single MSI with no UI for as-if-shipped installations
* Merge module or ZIP file for Python-as-a-library installations
(also note that the third option really needs changes/fixes to pythonXY.dll to work well)

If we went this way, I'd really want the EXE launcher to be the only one with a 'friendly' UI - the other two are specifically for people who know how to read documentation and know why they're getting them (especially since I assume I'd be the one writing it all). The EXE launcher could fairly trivially trigger or acquire either of the other two, so it could still be the main entry point, but I would seriously want to demote anything other than the per-user install.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sun Mar 22 01:07:17 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 22 Mar 2015 00:07:17 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426982837.51.0.824232970559.issue22516@psf.upfronthosting.co.za>


Steve Dower added the comment:

> (when does Windows switch to 3.6? Honestly, it can probably never happen...). 

On re-read, this isn't quite clear:

Hypothetically, if Windows 10 included Python 3.5, when would it be upgraded to Python 3.6? Probably never. Back-compat is problematic on Linux, but are significantly multiplied by the size of and the relative lack of technical competence/interest of the Windows user base.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sun Mar 22 01:42:54 2015
From: report at bugs.python.org (Carlos Pita)
Date: Sun, 22 Mar 2015 00:42:54 +0000
Subject: [issue23735] Readline not adjusting width after resize with 6.3
Message-ID: <1426984974.32.0.405944458303.issue23735@psf.upfronthosting.co.za>


New submission from Carlos Pita:

See here:

https://github.com/ipython/ipython/issues/6974

Chet Ramey confirmed the bug is downstream:

As I recall from looking briefly at the ipython/python source code, it has
to do with python not handling the SIGWINCH and expecting readline to do
it even when readline is not active. In readline-6.3, readline only
installs its signal handlers when rl_callback_read_char is called, which
python does only when it receives a character and its select(2) call
returns. The way readline-6.2 and earlier did things, it could `steal'
signals from an application without being active. I think python doesn't
handle SIGWINCH at all, which means that it expects readline's signal
handler to be active all the time, instead of just when python calls back
into readline to have it read a character.

A possible fix would be to have python's readline module install a signal
handler for SIGWINCH and have it set readline's idea of the screen size.

----------
messages: 238857
nosy: Carlos Pita
priority: normal
severity: normal
status: open
title: Readline not adjusting width after resize with 6.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23735>
_______________________________________

From report at bugs.python.org  Sun Mar 22 01:50:55 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 22 Mar 2015 00:50:55 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multplie installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1426985455.43.0.993792878829.issue23546@psf.upfronthosting.co.za>


Steve Dower added the comment:

Hey Terry, as a first step towards fixing the current 3.5 issue of not having Edit with IDLE at all, is it okay if the "Edit with IDLE" menu launches (approx.) "py -m idlelib.idle %1"? Currently the shortcut menu is part of the launcher - the "Open" item launches "py %1", so they'll be consistent.

An expanded menu like Liam's mockup is possible, but I can't guarantee I'll be able to get to it in time. (It may also be better as something configurable within IDLE anyway - https://msdn.microsoft.com/en-us/library/windows/desktop/hh127424(v=vs.85).aspx describes how it can be done purely through the registry on Win7 and later.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sun Mar 22 01:51:32 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Mar 2015 00:51:32 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426985492.4.0.0447827827859.issue22516@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

As of last month, Microsoft do provide official Python support, but only in the context of the online Azure Machine Learning Environment: http://blogs.technet.com/b/machinelearning/archive/2015/02/18/announcing-the-general-availability-of-azure-machine-learning.aspx

I only discovered that this morning myself when Doug Napoleone tweeted a link to the related post from Continuum Analytics: http://continuum.io/blog/azureml

I was already aware of another Strata "combined solution" announcement, which covered deploying Anaconda Cluster in combination with Red Hat Storage for distributed data access from PySpark analysis nodes: http://redhatstorage.redhat.com/2015/02/17/deploying-pyspark-on-red-hat-storage-glusterfs/

So if we're after a recommendation for end users that has strong multi-vendor backing, then Anaconda from Continuum Analytics would definitely be the way to go. It's also already the preferred choice of the Software Carpentry community: http://software-carpentry.org/v5/setup.html (and the reasons are the same as those being discussed here: unlike the default CPython installers, Anaconda is specifically designed to tolerate being installed without administrative access to your system)

(I'd previously discounted Anaconda as a default upstream recommendation for per-user installs on Windows as I thought it was missing Windows-specific utility libraries like pywin32, but I was simply wrong about that: http://continuum.io/press/anaconda-1-6-released)

As Steve noted, providing Python *in the OS* for third party use poses major upgrade challenges. For Fedora, Python gets rebased in each major release (so every 6 months or so) which is easily fast enough to keep up with the general pace of CPython releases (Ubuntu tend to do the same thing), but also means system administrators and other folks using the system Python need to be prepared to keep pace with that upgrade cycle.

Things get far more difficult with the long term support releases like Debian Stable, Ubuntu LTS, RHEL, CentOS and SLES, or the custom Linux distributions used inside organisations like Google, Facebook and Amazon. *There* the system Python has historically acted as a long term brake on Python's evolution, as third party projects are often reluctant to drop support for older Python versions until newer Python versions are readily available in these long term support releases.

In July, we'll be coming up on 5 years since Python 2.7 was released, yet a great many third party Python projects still require that contributions retain compatibility with Python 2.6.

We see similar patterns occurring if we look back at earlier Python 2.x releases. As part of explaining the limited utility of a Python 2.8 release in facilitating the Python 3 transition (see
http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html#wouldn-t-a-python-2-8-release-help-ease-the-transition for more on that) I pulled together the dates from various Python 2.x releases to when Twisted dropped the preceding release as a compatibility requirement:

* CPython 2.4 released -> 2.3 support dropped in Twisted: ~6 years
* CPython 2.5 released -> 2.4 support dropped in Twisted: ~4 years (Windows), ~6 years (non-Windows)
* CPython 2.6 released -> 2.5 support dropped in Twisted: ~4 years

That's a broken cycle, and one we need to help fix on the distro side by getting people to migrate away from using the stable system Python (which won't be rebased for the entire lifecycle of a major release) and into more regularly updated environments - upstream can't do that for us, we have to offer the appropriate tools downstream and actively encourage users to leave the system Python to the task of running the system, rather than arbitrary third party code.

The 10 year supported lifespan of RHEL & CentOS, together with the 3-4 year gaps between new major releases is one of the worst offenders on that front (not just for Python, but for other language runtimes, database runtimes, web servers etc), hence initiatives like the introduction of Software Collections (both as a commercially supported Red Hat product and as an upstream project hosted at softwarecollections.org). Using an SCL instead of the system Python lets an application developer more easily upgrade at their own pace (whether faster on RHEL/CentOS or slower on Fedora)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sun Mar 22 02:16:25 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Mar 2015 01:16:25 +0000
Subject: [issue23735] Readline not adjusting width after resize with 6.3
In-Reply-To: <1426984974.32.0.405944458303.issue23735@psf.upfronthosting.co.za>
Message-ID: <1426986985.86.0.32810366874.issue23735@psf.upfronthosting.co.za>


R. David Murray added the comment:

Why would this not constitute a bug in readline?  Readline isn't going to be active all of the time in most applications, so why shouldn't it be readline's responsibility to install the signal handler at initialization and handle it?  If the application wants control of that signal, it can then install its own handler after readline initialization completes.  Clearly it used to work that way.  Is there some documentation from readline you can point us to that explains the reasoning behind this change in behavior?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23735>
_______________________________________

From report at bugs.python.org  Sun Mar 22 02:19:59 2015
From: report at bugs.python.org (Tim Graham)
Date: Sun, 22 Mar 2015 01:19:59 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1426987199.48.0.775217197362.issue23571@psf.upfronthosting.co.za>


Tim Graham added the comment:

Here's an exception in Django after the latest patch. The Django code block in the last exception catches ValueError, but this doesn't seem to work any longer since it's "wrapped" in SystemError. As Berker mentioned, some upgrade tips would be great as I'm not sure what adaptions in Django need to be made.

Traceback (most recent call last):
  File "/home/tim/code/django/django/contrib/contenttypes/views.py", line 17, in shortcut
    content_type = ContentType.objects.get(pk=content_type_id)
  File "/home/tim/code/django/django/db/models/manager.py", line 127, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/home/tim/code/django/django/db/models/query.py", line 387, in get
    self.model._meta.object_name
django.contrib.contenttypes.models.DoesNotExist: ContentType matching query does not exist.

...

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
ValueError: could not convert string to float: request_path

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
....
  File "/home/tim/code/django/django/template/base.py", line 792, in __init__
    self.literal = float(var)
SystemError: <class 'ValueError'> returned a result with an error set

----------
nosy: +Tim.Graham

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Sun Mar 22 02:28:59 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Mar 2015 01:28:59 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426987739.77.0.191860610947.issue22516@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Given the expansion of the discussion to more general questions of getting CPython from upstream into the hands of end users, I've added in some more of the distro level folks to the nosy list (Matthias, Barry, Slavek, Robert).

This idea of more actively pursuing well-structured channel based resdistribution for Python as a whole is one I've had on my mind for a while. If you have the time to watch it, my PyCon New Zealand keynote from last year gives a good overview of my own perspective on the topic: https://www.youtube.com/watch?v=H2ybMrFNku0

----------
nosy: +barry, bkabrda, doko, rkuska

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sun Mar 22 02:54:08 2015
From: report at bugs.python.org (Mike Short)
Date: Sun, 22 Mar 2015 01:54:08 +0000
Subject: [issue22933] Misleading sentence in doc for shutil.move
In-Reply-To: <1416849036.72.0.766895523282.issue22933@psf.upfronthosting.co.za>
Message-ID: <1426989248.57.0.431509012385.issue22933@psf.upfronthosting.co.za>


Changes by Mike Short <bmshort at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file38627/shutil_2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22933>
_______________________________________

From report at bugs.python.org  Sun Mar 22 02:54:26 2015
From: report at bugs.python.org (Mike Short)
Date: Sun, 22 Mar 2015 01:54:26 +0000
Subject: [issue22933] Misleading sentence in doc for shutil.move
In-Reply-To: <1416849036.72.0.766895523282.issue22933@psf.upfronthosting.co.za>
Message-ID: <1426989266.94.0.599694357334.issue22933@psf.upfronthosting.co.za>


Changes by Mike Short <bmshort at gmail.com>:


Added file: http://bugs.python.org/file38628/shutil_latest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22933>
_______________________________________

From report at bugs.python.org  Sun Mar 22 03:03:01 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 22 Mar 2015 02:03:01 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multiple installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1426989781.64.0.102846137947.issue23546@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
title: Windows, 'Edit withIDLE', and multplie installed versions -> Windows, 'Edit withIDLE', and multiple installed versions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sun Mar 22 03:06:30 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 22 Mar 2015 02:06:30 +0000
Subject: [issue22149] the frame of a suspended generator should not have a
 local trace function
In-Reply-To: <1407271163.94.0.203518620414.issue22149@psf.upfronthosting.co.za>
Message-ID: <1426989990.03.0.117462489662.issue22149@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Can we have a formal patch review please.  I've assumed that if acceptable the patch could also be applied to 3.4 and 2.7.

----------
nosy: +BreamoreBoy
versions: +Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22149>
_______________________________________

From report at bugs.python.org  Sun Mar 22 03:59:33 2015
From: report at bugs.python.org (Ned Deily)
Date: Sun, 22 Mar 2015 02:59:33 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426993173.89.0.367164438265.issue22516@psf.upfronthosting.co.za>


Ned Deily added the comment:

This issue seems to be expanding widely in scope and it is not at all clear to me what actionable items would come out of it.  It started as a very Window-specific problem and now seems to somehow be being extended to the whole Python ecosphere.  What about the OS X world, arguably one of the most widely-used laptop development environment these days?  Apple distributes system Pythons with OS X.  There are the python.org installers for OS X.  There are third-party suppliers of popular binary wheels and or installers for important packages (e.g. NumPy, pandas, matplotlib) for one or both of the above. There are very popular third-party general open-source package distributors for OS X: Homwbrew and MacPorts, to a lesser extent, Fink. All of them distribute Pythons and many Python packages.  Then there are the cross-platform distributors, like Anaconda, Enthought, ActiveState, etc.  Should they all be part of this discussion?  What about other Posix-y platforms, like FreeBSD?  Where do you see this discussion going and is this a good forum for it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sun Mar 22 04:10:29 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 22 Mar 2015 03:10:29 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426993829.33.0.658504095815.issue22516@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

No this is not a good forum for this discussion.  Python-dev or ideas please, to be followed up by a PEP I'd guess.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sun Mar 22 04:21:48 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 22 Mar 2015 03:21:48 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1426994508.9.0.923314285654.issue22516@psf.upfronthosting.co.za>


Steve Dower added the comment:

Yeah, this is starting to get out of hand. I'm quite happy to leave things sit until the language summit, when we should have a broad enough representation to make a start. After that it'll get to python-dev before anything major is decided, but the brainstorming phase will be more effective in person (sorry to anyone who won't be there - feel free to email me directly if you want to provide your perspective in advance: steve.dower at microsoft dot com).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sun Mar 22 05:08:02 2015
From: report at bugs.python.org (paul j3)
Date: Sun, 22 Mar 2015 04:08:02 +0000
Subject: [issue23159] argparse: Provide equivalent of
 optparse.OptionParser.{option_groups, option_list, get_option}
In-Reply-To: <1420355263.97.0.969710352141.issue23159@psf.upfronthosting.co.za>
Message-ID: <1426997282.38.0.53960958672.issue23159@psf.upfronthosting.co.za>


paul j3 added the comment:

The attached file subclasses ArgumentParser, explores how these optparse methods might be added to argparse.  The __name__ section demonstrates how they might be used.

argparse differs from optparse in a number of ways:

- all actions are included in the parser._actions list.

- the parser has one dictionary with all option_strings (both short and long)

- argparse also has positionals, which don't have option_strings.  They could be found by 'dest' (or some other attribute), but this does not have to be unique.

- argparse does not use argument groups for parsing; just for formatting the help.

- groups keep a list of their own actions in ._group_actions list.  The ._actions list is shared among the parser and all groups.

- every action is in an argument group, usually one of the 2 default groups.  An action does not have a 'container' attribute.

-------------------

The idea of coordinating config sections with parser argument groups is interesting, but I question whether the stock argparser should be modified to facilitate this.  It sounds like something that belongs in a custom subclass.

Ipython populates its argparse parser with arguments derived from config files.  This provides multiple config levels - default, custom file, and calling arguments.  I don't recall whether it makes any use of argument groups.

----------
Added file: http://bugs.python.org/file38629/argparse_extended.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23159>
_______________________________________

From report at bugs.python.org  Sun Mar 22 05:27:08 2015
From: report at bugs.python.org (Carlos Pita)
Date: Sun, 22 Mar 2015 04:27:08 +0000
Subject: [issue23735] Readline not adjusting width after resize with 6.3
In-Reply-To: <1426984974.32.0.405944458303.issue23735@psf.upfronthosting.co.za>
Message-ID: <1426998428.06.0.97236540886.issue23735@psf.upfronthosting.co.za>


Carlos Pita added the comment:

Chet again:

Here's the story from the top.

Prior to readline-6.3, readline could `steal' signals from the calling
application in the sense that readline's signal handler got a crack at
all signals in which readline was interested before the application did.
Now, that was usually ok, since readline handled signals immediately
upon receipt and resent the signal to the calling application.  It did
all this in a signal handler context.

It's dangerous to execute `unsafe' library functions and system calls from
a signal handler. The Posix standard has a (short) list of signal-safe
functions.  Before bash-4.3/readline-6.3, readline and bash did far too
much work in signal handlers.  The most you are supposed to do in a signal
handler is set variables, preferably of type sig_atomic_t, and nothing
else.  The biggest offenders are malloc and free, for two reasons:
applications often want to provide their own memory allocation atop
malloc and free, and using them from signal handlers can interfere; and
the glibc versions use internal locks extensively, and calling, say, free
from a signal handler can end up in a deadlock.

I made some progress up to bash-4.2/readline-6.2 in deferring `real' work
until readline wasn't in a signal handling context using the
RL_CHECK_SIGNALS() macro, but there were still a few places left that
handled the signal immediately.  One of those places was the callback
handling code; another was the SIGWINCH handling.

The SIGWINCH code signal handling functions eventually generated the same
sort of bug reports as other signals.  One representative report is

http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00291.html

The fix was to make SIGWINCH handling the same as other signals: set a
flag and defer handling until no longer in a signal handling context.
This was necessary in both `direct' and callback modes.

The gdb folks reported most of the problems with the callback code handling
signals immediately instead of deferring handling until out of a signal
handler context; one such report is

http://lists.gnu.org/archive/html/bug-readline/2011-07/msg00010.html

So now the SIGWINCH and the callback code had to be changed to avoid
unsafe function calls from within a signal handler.

That very quickly uncovered a problem: the issue of readline stealing
the application's signals became much worse.

http://lists.gnu.org/archive/html/bug-readline/2011-07/msg00012.html

is the first explanation of that phenomenon.  If readline's signal
handlers are called when the application is active (e.g., between the
calls to rl_callback_handler_install and rl_callback_read_char), and all
they do is set a private flag the application doesn't know about, the
signals will effectively be ignored until the next time the application
calls into the readline callback interface and readline can check signals.
This is not acceptable in most contexts, including for SIGWINCH.

The fix for that is to make readline's signal handlers be active only
when readline is active and can check the flag the handlers set.

And so we reach where we are.  If a SIGWINCH arrives while readline is
not active, and the application using callback mode does not catch it and
tell readline about the updated screen dimensions (rl_set_screen_size()
exists for this purpose), readline will not know about the new size.

It seems like the issue is that people assume that the pre-readline-6.3
behavior was acceptable because they never encountered a problem, and that
any change must therefore be a bug.

Please feel free to add this message to the python issue tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23735>
_______________________________________

From report at bugs.python.org  Sun Mar 22 05:53:51 2015
From: report at bugs.python.org (John Nagle)
Date: Sun, 22 Mar 2015 04:53:51 +0000
Subject: [issue23736] "make test" on clean py3 install on CentOS 6.2 - 2 tests
 fail
Message-ID: <1427000031.58.0.0063675703932.issue23736@psf.upfronthosting.co.za>


New submission from John Nagle:

Installing Python 3.4.2 on CentOS 6.  Clean install.  Using procedure in README file:

./configure
make
make test

2 tests fail in "make test" The first one is because the FTP client
test is trying to test against a site that is long gone, the Digital Equipment Corporation Systems Research Center in Palo Alto:

ERROR: test_ftp (test.test_urllib2net.OtherNetworkTests) (url='ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/00README-Legal-Rules-Regs')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/staging/local/python/Python-3.4.3/Lib/urllib/request.py", line 1399, in ftp_open
    fw = self.connect_ftp(user, passwd, host, port, dirs, req.timeout)
  File "/home/staging/local/python/Python-3.4.3/Lib/urllib/request.py", line 1445, in connect_ftp
    dirs, timeout)
  File "/home/staging/local/python/Python-3.4.3/Lib/urllib/request.py", line 2243, in __init__
    self.init()
  File "/home/staging/local/python/Python-3.4.3/Lib/urllib/request.py", line 2249, in init
    self.ftp.connect(self.host, self.port, self.timeout)
  File "/home/staging/local/python/Python-3.4.3/Lib/ftplib.py", line 153, in connect
    source_address=self.source_address)
  File "/home/staging/local/python/Python-3.4.3/Lib/socket.py", line 512, in create_connection
    raise err
  File "/home/staging/local/python/Python-3.4.3/Lib/socket.py", line 503, in create_connection
    sock.connect(sa)
TimeoutError: [Errno 110] Connection timed out


The second one is failing because "readline" (probably GNU readline) didn't behave as expected. The installed GCC is
"gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)", which came with
"CentOS release 6.2 (Final)".  This is a long-running production server.
Is that too old?


FAIL: test_init (test.test_readline.TestReadline)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/staging/local/python/Python-3.4.3/Lib/test/test_readline.py", line 57, in test_init
    self.assertEqual(stdout, b'')
AssertionError: b'\x1b[?1034h' != b''

----------
components: Installation
messages: 238869
nosy: nagle
priority: normal
severity: normal
status: open
title: "make test" on clean py3 install on CentOS 6.2 - 2 tests fail
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23736>
_______________________________________

From report at bugs.python.org  Sun Mar 22 06:06:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Mar 2015 05:06:55 +0000
Subject: [issue23735] Readline not adjusting width after resize with 6.3
In-Reply-To: <1426984974.32.0.405944458303.issue23735@psf.upfronthosting.co.za>
Message-ID: <1427000815.7.0.158289486656.issue23735@psf.upfronthosting.co.za>


R. David Murray added the comment:

If it used to handle the signal and then re-raise it, why doesn't it now set its flag and then re-raise the signal?  (I also don't understand why the API isn't that the application takes back the signal handler if it needs it if it is using readline, but I'm not familiar enough with signal handling in applications to really judge that, I suppose.)

However, we certainly understand the issues with doing too much in signal handlers, so if that ship has sailed I guess we'll just have to deal with it.

----------
nosy: +neologix
type:  -> behavior
versions: +Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23735>
_______________________________________

From report at bugs.python.org  Sun Mar 22 06:09:45 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Mar 2015 05:09:45 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1427000985.9.0.316923454451.issue22516@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Right, I mostly borrowed the issue as a public channel that could reach folks already invested in the problem space, without needing to tidy things up sufficiently to make them coherent for a more general audience on python-dev or python-ideas.

As Steve says, we really need some high bandwidth discussions to help define what we think "good" looks like. I have a pretty solid idea of what *I* think "good" looks like, but that doesn't mean that aligns with what others think.

If we can get to a point where Steve, Slavek, Barry, Matthias and I can agree on a general outline of how we'd like platform integration to work, and whatever we propose sounds plausible to the Mac OS X experts as well, we'll be in a much better position to present a coherent story both to end users *and* to our fellow developers :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sun Mar 22 06:13:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Mar 2015 05:13:48 +0000
Subject: [issue23736] "make test" on clean py3 install on CentOS 6.2 - 2 tests
 fail
In-Reply-To: <1427000031.58.0.0063675703932.issue23736@psf.upfronthosting.co.za>
Message-ID: <1427001228.35.0.421802804604.issue23736@psf.upfronthosting.co.za>


R. David Murray added the comment:

The first test passes for me (although granted we should move that test to a psf hosted target, but we're slowly working on that general issue). The second is a bug in readline (see issue 19884).

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Importing readline produces erroneous output
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23736>
_______________________________________

From report at bugs.python.org  Sun Mar 22 06:14:26 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Sun, 22 Mar 2015 05:14:26 +0000
Subject: [issue23735] Readline not adjusting width after resize with 6.3
In-Reply-To: <1426984974.32.0.405944458303.issue23735@psf.upfronthosting.co.za>
Message-ID: <1427001266.59.0.992875349444.issue23735@psf.upfronthosting.co.za>


Changes by Thomas Kluyver <takowl at gmail.com>:


----------
nosy: +takluyver

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23735>
_______________________________________

From report at bugs.python.org  Sun Mar 22 06:18:07 2015
From: report at bugs.python.org (Ned Deily)
Date: Sun, 22 Mar 2015 05:18:07 +0000
Subject: [issue23736] "make test" on clean py3 install on CentOS 6.2 - 2 tests
 fail
In-Reply-To: <1427000031.58.0.0063675703932.issue23736@psf.upfronthosting.co.za>
Message-ID: <1427001487.43.0.811623656975.issue23736@psf.upfronthosting.co.za>


Ned Deily added the comment:

The test_ftp connection timeout error failure (seen on some platforms) is a duplicate of Issue22289.

The test_readline failure is a duplicate of, among others, Issue22647 and is believed to no longer occur with the current Python 3.4.3 (released 2015-02-25) and a GNU readline >= 6.3.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23736>
_______________________________________

From report at bugs.python.org  Sun Mar 22 06:44:37 2015
From: report at bugs.python.org (Josiah Carlson)
Date: Sun, 22 Mar 2015 05:44:37 +0000
Subject: [issue1191964] add non-blocking read and write methods to
 subprocess.Popen
Message-ID: <1427003077.27.0.814667264123.issue1191964@psf.upfronthosting.co.za>


Josiah Carlson added the comment:

Okay, I'm sorry for falling asleep at the wheel on this. At this point, I don't expect this to go in for 3.5 - but if it has a chance, I'll do what I need to do to get it there. Let me know.

I agree with the .communicate() not raising on broken pipe, and read/write_nonblocking raising on broken pipe. I'll get a patch in with the comments on the existing code review, along with those changes on Monday or Tuesday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1191964>
_______________________________________

From report at bugs.python.org  Sun Mar 22 07:06:41 2015
From: report at bugs.python.org (bintang raksaguna)
Date: Sun, 22 Mar 2015 06:06:41 +0000
Subject: [issue23737] web course
Message-ID: <1427004400.99.0.712280768019.issue23737@psf.upfronthosting.co.za>


New submission from bintang raksaguna:

href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Tempat Kursus website, SEO, Desain Grafis Favorit</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Tempat Kursus website, SEO, Desain Grafis Favorit 2015 di jakarta</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Tempat kursus website</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Tempat kursus SEO</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Tempat kursus Desain Grafis</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">kursus SEO di jakarta</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">kursus website di jakarta</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Kursus Desain Grafis di jakarta</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Tempat kursus SEO di jakarta</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Tempat kursus website di jakarta</a>
<a href="http://winstarlink.com/tempat-kursus-website-seo-desain-grafis-favorit-2015-di-jakarta/">Tempat Kursus Desain Grafis di jakarta</a>

----------
hgrepos: 302
messages: 238875
nosy: bintangrksgn
priority: normal
severity: normal
status: open
title: web course

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23737>
_______________________________________

From report at bugs.python.org  Sun Mar 22 07:09:24 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 Mar 2015 06:09:24 +0000
Subject: [issue23737] web course
In-Reply-To: <1427004400.99.0.712280768019.issue23737@psf.upfronthosting.co.za>
Message-ID: <1427004564.06.0.720596969629.issue23737@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
hgrepos:  -302

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23737>
_______________________________________

From report at bugs.python.org  Sun Mar 22 07:09:32 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 Mar 2015 06:09:32 +0000
Subject: [issue23737] web course
Message-ID: <1427004572.5.0.973468373135.issue23737@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
Removed message: http://bugs.python.org/msg238875

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23737>
_______________________________________

From report at bugs.python.org  Sun Mar 22 07:09:51 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 Mar 2015 06:09:51 +0000
Subject: [issue23737] spam
Message-ID: <1427004591.46.0.946250316877.issue23737@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: web course -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23737>
_______________________________________

From report at bugs.python.org  Sun Mar 22 07:30:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Mar 2015 06:30:53 +0000
Subject: [issue20181] Derby #12: Convert 50 sites to Argument Clinic across 4
 files
In-Reply-To: <1389140203.53.0.198441160626.issue20181@psf.upfronthosting.co.za>
Message-ID: <1427005853.94.0.365805448708.issue20181@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch for unicodedata.

----------
keywords: +patch
nosy: +serhiy.storchaka
Added file: http://bugs.python.org/file38630/unicodedata_clinic.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20181>
_______________________________________

From report at bugs.python.org  Sun Mar 22 07:36:38 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Mar 2015 06:36:38 +0000
Subject: [issue23633] Improve py launcher help, index, and doc
In-Reply-To: <1426026714.29.0.122233634927.issue23633@psf.upfronthosting.co.za>
Message-ID: <1427006198.28.0.884857737879.issue23633@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Given its Windows specific nature, I'll always defer to Steve and the other Windows devs when it comes to the launcher.

My main involvement (aside from general mailing list commentary) was asking Vinay to bring the independently distributed version under the PyPA banner :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23633>
_______________________________________

From report at bugs.python.org  Sun Mar 22 07:41:46 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Mar 2015 06:41:46 +0000
Subject: [issue23642] Interaction of ModuleSpec and C Extension Modules
In-Reply-To: <1426086531.98.0.531682777516.issue23642@psf.upfronthosting.co.za>
Message-ID: <1427006506.42.0.236013356883.issue23642@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Added Petr to the nosy list here as well.

Petr - this is the kind of discrepancy I'm hoping that PEP 489 can help remedy, so it may make for a good test case :)

----------
nosy: +encukou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23642>
_______________________________________

From report at bugs.python.org  Sun Mar 22 07:54:18 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 22 Mar 2015 06:54:18 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1427007258.61.0.723180607006.issue6422@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The current patch moves print operations inside timeit() and repeat(), instead of leaving the main() function as the only one with side effects.

My counter-proposal was to instead extract the current main functionality out into a side-effect free public API of its own, and change the existing main function to call that new API and print the results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Sun Mar 22 07:55:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Mar 2015 06:55:20 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1427007320.19.0.594449547503.issue23571@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Minimal reproducer:

>>> try:
...     1/0
... except:
...     int('spam')
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

ValueError: invalid literal for int() with base 10: 'spam'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
SystemError: <class 'ValueError'> returned a result with an error set

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Sun Mar 22 08:17:41 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 22 Mar 2015 07:17:41 +0000
Subject: [issue23642] Interaction of ModuleSpec and C Extension Modules
In-Reply-To: <1426086531.98.0.531682777516.issue23642@psf.upfronthosting.co.za>
Message-ID: <1427008661.39.0.862614377471.issue23642@psf.upfronthosting.co.za>


Changes by Stefan Behnel <scoder at users.sourceforge.net>:


----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23642>
_______________________________________

From report at bugs.python.org  Sun Mar 22 08:19:35 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Mar 2015 07:19:35 +0000
Subject: [issue10482] subprocess and deadlock avoidance
In-Reply-To: <1290320162.59.0.372707956205.issue10482@psf.upfronthosting.co.za>
Message-ID: <1427008775.24.0.946547733693.issue10482@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10482>
_______________________________________

From report at bugs.python.org  Sun Mar 22 08:48:16 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Mar 2015 07:48:16 +0000
Subject: [issue22079] Ensure in PyType_Ready() that base class of static type
 is static
In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za>
Message-ID: <20150322074812.4227.54653@psf.io>


Roundup Robot added the comment:

New changeset aa79a04e9bf5 by Serhiy Storchaka in branch '2.7':
Issue #22079: Py3k warning now is issued in  PyType_Ready() instead of
https://hg.python.org/cpython/rev/aa79a04e9bf5

New changeset 57a457ea84e4 by Serhiy Storchaka in branch '3.4':
Issue #22079: Deprecation warning now is issued in  PyType_Ready() instead of
https://hg.python.org/cpython/rev/57a457ea84e4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22079>
_______________________________________

From report at bugs.python.org  Sun Mar 22 08:59:32 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Mar 2015 07:59:32 +0000
Subject: [issue22350] nntplib file write failure causes exception from QUIT
 command
In-Reply-To: <1410061219.03.0.0230581897355.issue22350@psf.upfronthosting.co.za>
Message-ID: <1427011172.56.0.544745262081.issue22350@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

But the same issue exists with regular files.

>>> with open('/dev/full', 'wb') as f:
...     f.write(b'x'*10000)
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
OSError: [Errno 28] No space left on device

And using Python implementation for detailed traceback:

>>> import _pyio
>>> with _pyio.open('/dev/full', 'wb') as f:
...     f.write(b'x'*10000)
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/home/serhiy/py/cpython/Lib/_pyio.py", line 1184, in write
    self._flush_unlocked()
  File "/home/serhiy/py/cpython/Lib/_pyio.py", line 1211, in _flush_unlocked
    n = self.raw.write(self._write_buf)
OSError: [Errno 28] No space left on device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/home/serhiy/py/cpython/Lib/_pyio.py", line 451, in __exit__
    self.close()
  File "/home/serhiy/py/cpython/Lib/_pyio.py", line 767, in close
    self.flush()
  File "/home/serhiy/py/cpython/Lib/_pyio.py", line 1204, in flush
    self._flush_unlocked()
  File "/home/serhiy/py/cpython/Lib/_pyio.py", line 1211, in _flush_unlocked
    n = self.raw.write(self._write_buf)
OSError: [Errno 28] No space left on device


What behavior you expect?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22350>
_______________________________________

From report at bugs.python.org  Sun Mar 22 09:01:40 2015
From: report at bugs.python.org (Ned Deily)
Date: Sun, 22 Mar 2015 08:01:40 +0000
Subject: [issue22289] support.transient_internet() doesn't catch timeout on
 FTP tests of test_urllib2net
In-Reply-To: <1409142449.68.0.105373691369.issue22289@psf.upfronthosting.co.za>
Message-ID: <1427011300.86.0.88250456169.issue22289@psf.upfronthosting.co.za>


Ned Deily added the comment:

Here's an updated patch for 3.4 and default.  To test it, I had to inject a faulty test server with a timeout error, as the test with the dead URL skips properly on my system.  For 2.7, the test doesn't fail for me even with the injected server so I propose not bothering to change anything there.

----------
stage: patch review -> commit review
Added file: http://bugs.python.org/file38631/issue22289_3x.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22289>
_______________________________________

From report at bugs.python.org  Sun Mar 22 09:09:24 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 Mar 2015 08:09:24 +0000
Subject: [issue22289] support.transient_internet() doesn't catch timeout on
 FTP tests of test_urllib2net
In-Reply-To: <1427011300.86.0.88250456169.issue22289@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYowUxmwDHSsSApLs1dZ8Kk=ai4e127r6F5Xbj2u1TWyQ@mail.gmail.com>


STINNER Victor added the comment:

The patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22289>
_______________________________________

From report at bugs.python.org  Sun Mar 22 09:19:40 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Mar 2015 08:19:40 +0000
Subject: [issue22289] support.transient_internet() doesn't catch timeout on
 FTP tests of test_urllib2net
In-Reply-To: <1409142449.68.0.105373691369.issue22289@psf.upfronthosting.co.za>
Message-ID: <20150322081936.63574.26967@psf.io>


Roundup Robot added the comment:

New changeset 9eb1ce7d8039 by Ned Deily in branch '3.4':
Issue #22289: Prevent test_urllib2net failures due to ftp connection timeout.
https://hg.python.org/cpython/rev/9eb1ce7d8039

New changeset 1aad901e0307 by Ned Deily in branch 'default':
Issue #22289: merge from 3.4
https://hg.python.org/cpython/rev/1aad901e0307

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22289>
_______________________________________

From report at bugs.python.org  Sun Mar 22 09:40:21 2015
From: report at bugs.python.org (Ned Deily)
Date: Sun, 22 Mar 2015 08:40:21 +0000
Subject: [issue22289] support.transient_internet() doesn't catch timeout on
 FTP tests of test_urllib2net
In-Reply-To: <1409142449.68.0.105373691369.issue22289@psf.upfronthosting.co.za>
Message-ID: <1427013621.09.0.00607491132824.issue22289@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the review.  Fix committed for release in 3.4.4 and 3.5.0.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22289>
_______________________________________

From report at bugs.python.org  Sun Mar 22 09:50:40 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Mar 2015 08:50:40 +0000
Subject: [issue1191964] add non-blocking read and write methods to
 subprocess.Popen
Message-ID: <1427014240.28.0.243144343271.issue1191964@psf.upfronthosting.co.za>


Martin Panter added the comment:

Regarding special cases on the reading side, I think there should be an easy way to distinguish them. The existing RawIOBase way is probably as good as any, unless you want to take the chance to invent a better API:

* EOF (pipe closed, no more data ever) should be indicated by returning b""
* Empty pipe (still open, future data possible) should be indicated by returning None

Beware that BlockingIOError is normally not raised by Python?s standard library, despite the BufferedIOBase documentation, and I think it should say that way (the implementation, that is). See Issue 13322.

Regarding handling a broken pipe condition, it would be nice to have a way of signalling that to the caller, whether via an exception or other means. For example if the subprocess is a video player which gets closed early by the end user, it would be good to know to stop wasting time and bandwidth generating and piping video the the player.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1191964>
_______________________________________

From report at bugs.python.org  Sun Mar 22 10:02:53 2015
From: report at bugs.python.org (Paul Moore)
Date: Sun, 22 Mar 2015 09:02:53 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1427014973.81.0.966248375254.issue22516@psf.upfronthosting.co.za>


Paul Moore added the comment:

That sounds reasonable. I understand the need for face-to-face discussion on something like this, although I do think there's been something of a tendency in the past for things "decided at PyCon" to receive a certain amount of resistance from people who weren't there, so I'd suggest posting a summary of what you're intending to discuss in advance, to get some input. I'll try to email my thoughts to Steve, to give him my perspective on the Windows side of things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Sun Mar 22 11:11:08 2015
From: report at bugs.python.org (Liam Marsh)
Date: Sun, 22 Mar 2015 10:11:08 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multiple installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1427019068.9.0.487035691135.issue23546@psf.upfronthosting.co.za>


Liam Marsh added the comment:

er... is the fact that py -m <module> ignore <module>'s shebang deliberate?
(using the 3.4.2 version of py.exe)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sun Mar 22 11:31:02 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Mar 2015 10:31:02 +0000
Subject: [issue23738] Clarify documentation of positional-only default values
Message-ID: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>


New submission from Martin Panter:

This patch adds the PEP 457 positional-only slash ?/? indicator to some function signatures in the documentation. I only looked at the the os, builtin, binascii, zlib and fcntl modules, and their functions where the documentation incorrectly suggests that they accept keyword arguments. For example, I changed

eval(expression, globals=None, locals=None)

to

eval(expression, globals=None, locals=None, /)

References:

* Issue 22832: ?fcntl? module changed to look like accepting keyword arguments
* Ongoing discussion: <https://mail.python.org/pipermail/python-dev/2015-March/138847.html>

There are many more instances where square brackets are used, or the arguments are mandatory. See the PEP for examples, but I do not think it is so important to ?fix? them.

I also fixed parameter name mismatches that I discovered for a quite a few functions that do take keyword arguments.

One more thing I noticed, that I do not know how to fix, is the Argument Clinic signatures list invalid default values for zlib.compressobj(zdict=None) and os.utime(ns=None):

>>> zlib.compressobj(zdict=None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' does not support the buffer interface
>>> os.utime("dummy", ns=None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: utime: 'ns' must be a tuple of two ints

----------
assignee: docs at python
components: Documentation
files: pos-defaults.patch
keywords: patch
messages: 238890
nosy: docs at python, serhiy.storchaka, vadmium
priority: normal
severity: normal
status: open
title: Clarify documentation of positional-only default values
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38632/pos-defaults.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23738>
_______________________________________

From report at bugs.python.org  Sun Mar 22 11:33:19 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Mar 2015 10:33:19 +0000
Subject: [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1427020399.06.0.460021505801.issue22832@psf.upfronthosting.co.za>


Martin Panter added the comment:

I opened Issue 23738 about my problem with the new signature, so it does not get forgotten.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22832>
_______________________________________

From report at bugs.python.org  Sun Mar 22 11:33:49 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 22 Mar 2015 10:33:49 +0000
Subject: [issue21110] Slowdown and high memory usage when adding a new module
 in embedded Python 3.4 on 64bit Windows
In-Reply-To: <1396262123.2.0.239412802273.issue21110@psf.upfronthosting.co.za>
Message-ID: <1427020429.28.0.767995395113.issue21110@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Who is best placed to address this issue?

----------
components: +Build, Extension Modules -Windows
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21110>
_______________________________________

From report at bugs.python.org  Sun Mar 22 11:53:19 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Mar 2015 10:53:19 +0000
Subject: [issue23738] Clarify documentation of positional-only default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1427021599.41.0.593872683033.issue23738@psf.upfronthosting.co.za>


Martin Panter added the comment:

Hmm it seems my change for os.utimes() in Modules/posixmodule.c does not automatically get reflected in the doc string. Is there some script I can run to regenerate it, or do I have to do it manually?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23738>
_______________________________________

From report at bugs.python.org  Sun Mar 22 12:22:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Mar 2015 11:22:47 +0000
Subject: [issue23738] Clarify documentation of positional-only default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1427023367.16.0.324338810748.issue23738@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

./python Tools/clinic/clinic.py --make

or just

    make clinic

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23738>
_______________________________________

From report at bugs.python.org  Sun Mar 22 12:25:09 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 Mar 2015 11:25:09 +0000
Subject: [issue23738] Clarify documentation of positional-only default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1427023509.33.0.386231470568.issue23738@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> patch review
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23738>
_______________________________________

From report at bugs.python.org  Sun Mar 22 13:54:14 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 22 Mar 2015 12:54:14 +0000
Subject: [issue11410] Use GCC visibility attrs in PyAPI_*
In-Reply-To: <1299391945.72.0.037942723875.issue11410@psf.upfronthosting.co.za>
Message-ID: <1427028854.34.0.89026213788.issue11410@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11410>
_______________________________________

From report at bugs.python.org  Sun Mar 22 14:02:52 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 22 Mar 2015 13:02:52 +0000
Subject: [issue22079] Ensure in PyType_Ready() that base class of static type
 is static
In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za>
Message-ID: <1427029372.81.0.165247489675.issue22079@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22079>
_______________________________________

From report at bugs.python.org  Sun Mar 22 14:08:45 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 22 Mar 2015 13:08:45 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1427029725.15.0.75302653827.issue23700@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

Comment in Lib/tempfile.py mentions issue #23000, but should mention issue #23700.

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Sun Mar 22 14:29:09 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Mar 2015 13:29:09 +0000
Subject: [issue22350] nntplib file write failure causes exception from QUIT
 command
In-Reply-To: <1410061219.03.0.0230581897355.issue22350@psf.upfronthosting.co.za>
Message-ID: <1427030949.07.0.462084394391.issue22350@psf.upfronthosting.co.za>


Martin Panter added the comment:

Well with a regular BufferedWriter, the chained exception is the same type as the original exception, so it does not really matter. I was just using the out-of-space exception as an easy way to get the body() method to abort in the middle of a command.

The problem with the NNTP library is that the NNTP class assumes that it can send a QUIT command when it shouldn?t be. The result can be a giant error message full of apparent garbage data, rather like in Issue 21468.

The minimum behaviour that I expect is that when the context manager exits, it should not cause a double exception with a different error type. My patch closes the connection as soon as an unrecoverable error happens, so __exit__() will not send a QUIT command and receive an invalid response.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22350>
_______________________________________

From report at bugs.python.org  Sun Mar 22 14:36:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Mar 2015 13:36:41 +0000
Subject: [issue22852] urllib.parse wrongly strips empty #fragment
In-Reply-To: <1415787811.02.0.365080072485.issue22852@psf.upfronthosting.co.za>
Message-ID: <1427031401.94.0.0905128874748.issue22852@psf.upfronthosting.co.za>


Martin Panter added the comment:

Posting patch v2 with these changes:

* Split out scheme documentation fixes to Issue 23684.
* Renamed _NetlocResultMixinBase ? _SplitParseBase
* Explained the default values of the flags better, and what None means
* Changed to Demian?s forward-looking ?version changed? notices. I decided it is okay because the same information can be inferred.
* Tweaked urlunsplit() and urlunparse() descriptions

----------
Added file: http://bugs.python.org/file38633/has_netloc.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22852>
_______________________________________

From report at bugs.python.org  Sun Mar 22 14:55:35 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Mar 2015 13:55:35 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za>
Message-ID: <1427032535.64.0.499510430146.issue22831@psf.upfronthosting.co.za>


Martin Panter added the comment:

The new fd_leaks_tools1_2.patch seems to have dropped the changes for Tools/scripts/treesync.py, compared to the previous fd_leaks_tools1.patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22831>
_______________________________________

From report at bugs.python.org  Sun Mar 22 15:15:19 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Mar 2015 14:15:19 +0000
Subject: [issue22933] Misleading sentence in doc for shutil.move
In-Reply-To: <1416849036.72.0.766895523282.issue22933@psf.upfronthosting.co.za>
Message-ID: <20150322141516.30033.28779@psf.io>


Roundup Robot added the comment:

New changeset e5de4ee6aa4a by Benjamin Peterson in branch '3.4':
clarify behavior of shutil.move when destination exists (closes #22933)
https://hg.python.org/cpython/rev/e5de4ee6aa4a

New changeset 4502e598fe26 by Benjamin Peterson in branch '2.7':
clarify behavior of shutil.move when destination exists (closes #22933)
https://hg.python.org/cpython/rev/4502e598fe26

New changeset a9f36ec5d944 by Benjamin Peterson in branch 'default':
merge 3.4 (#22933)
https://hg.python.org/cpython/rev/a9f36ec5d944

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22933>
_______________________________________

From report at bugs.python.org  Sun Mar 22 15:21:53 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 22 Mar 2015 14:21:53 +0000
Subject: [issue18407] Fix compiler warnings in pythoncore for Win64
In-Reply-To: <1373310575.24.0.067873985204.issue18407@psf.upfronthosting.co.za>
Message-ID: <1427034113.15.0.833631034615.issue18407@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Would someone like to review the patch please, being aware that there are other open issues relating to compiler warnings on Windows.

----------
nosy: +steve.dower, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18407>
_______________________________________

From report at bugs.python.org  Sun Mar 22 15:23:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Mar 2015 14:23:28 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za>
Message-ID: <1427034208.38.0.887245315049.issue22831@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, I forgot to publish my comments. I dropped the changes for treesync.py because treesync.py is not work with Python 3. I have written separate patch for it and will open separate issue after writing tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22831>
_______________________________________

From report at bugs.python.org  Sun Mar 22 15:29:25 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 22 Mar 2015 14:29:25 +0000
Subject: [issue1654408] Installer should split tcl/tk and tkinter install
 options.
Message-ID: <1427034565.11.0.307769736981.issue1654408@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Steve what is your take on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1654408>
_______________________________________

From report at bugs.python.org  Sun Mar 22 15:32:17 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 22 Mar 2015 14:32:17 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multiple installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1427034737.92.0.838695993006.issue23546@psf.upfronthosting.co.za>


Steve Dower added the comment:

I believe so. py.exe doesn't provide the -m option, so it has already selected the version by the time that starts running.

Shebangs are really just for launching the file directly. python -m <module> on Linux will also ignore the shebang.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sun Mar 22 15:34:56 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 22 Mar 2015 14:34:56 +0000
Subject: [issue18407] Fix compiler warnings in pythoncore for Win64
In-Reply-To: <1373310575.24.0.067873985204.issue18407@psf.upfronthosting.co.za>
Message-ID: <1427034896.73.0.844264296501.issue18407@psf.upfronthosting.co.za>


Steve Dower added the comment:

Does the patch still apply cleanly?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18407>
_______________________________________

From report at bugs.python.org  Sun Mar 22 15:36:28 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 22 Mar 2015 14:36:28 +0000
Subject: [issue21313] Py_GetVersion() is broken when using mqueue and a long
 patch name
In-Reply-To: <1397945838.86.0.227153547567.issue21313@psf.upfronthosting.co.za>
Message-ID: <1427034988.3.0.69723643206.issue21313@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Any comments on the proposal to restrict the length of the returned string from Py_GetBuildInfo() to 80 characters?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21313>
_______________________________________

From report at bugs.python.org  Sun Mar 22 15:39:12 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 22 Mar 2015 14:39:12 +0000
Subject: [issue23723] Provide a way to disable bytecode staleness checks
In-Reply-To: <1426875282.27.0.254210392532.issue23723@psf.upfronthosting.co.za>
Message-ID: <1427035152.75.0.993223880049.issue23723@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I haven't thought about how to implement it, let alone document it. As I said, I might simply refactor importlib so that others can at least implement a loader which can do this without having to directly muck with importlib itself. It really depends on how far one would want to go with this.

Otherwise I would add a note in importlib in the appropriate loader(s) that if such-and-such a datetime is specified in the bytecode header then all stat-related staleness checks against the original source is disabled and the only validation is the magic number (since it's cheap and a nice safety check).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23723>
_______________________________________

From report at bugs.python.org  Sun Mar 22 15:40:39 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 22 Mar 2015 14:40:39 +0000
Subject: [issue1654408] Installer should split tcl/tk and tkinter install
 options.
Message-ID: <1427035239.05.0.160730051591.issue1654408@psf.upfronthosting.co.za>


Steve Dower added the comment:

tkinter and our tcl/tk builds are so closely linked there's no point separating them IMHO.

It sounds like this report was prompted by a misconfiguration, so there's nothing really to fix here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1654408>
_______________________________________

From report at bugs.python.org  Sun Mar 22 15:40:57 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 22 Mar 2015 14:40:57 +0000
Subject: [issue23731] Implement PEP 488
In-Reply-To: <1426944831.0.0.593089874415.issue23731@psf.upfronthosting.co.za>
Message-ID: <1427035257.47.0.844708374693.issue23731@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Will probably want to see http://bugs.python.org/issue17232 resolved as part of this as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23731>
_______________________________________

From report at bugs.python.org  Sun Mar 22 15:42:05 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 22 Mar 2015 14:42:05 +0000
Subject: [issue23738] Clarify documentation of positional-only default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1427035325.86.0.302262752986.issue23738@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23738>
_______________________________________

From report at bugs.python.org  Sun Mar 22 15:45:46 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 22 Mar 2015 14:45:46 +0000
Subject: [issue22163] max_wbits set incorrectly to -zlib.MAX_WBITS in tarfile, 
 shouldn't be negative
In-Reply-To: <1407409352.24.0.421737248606.issue22163@psf.upfronthosting.co.za>
Message-ID: <1427035546.61.0.357418225078.issue22163@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Is the thinking and hence the patch correct here?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22163>
_______________________________________

From report at bugs.python.org  Sun Mar 22 15:47:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Mar 2015 14:47:50 +0000
Subject: [issue22350] nntplib file write failure causes exception from QUIT
 command
In-Reply-To: <1410061219.03.0.0230581897355.issue22350@psf.upfronthosting.co.za>
Message-ID: <1427035670.35.0.503021511728.issue22350@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I doubt that it is good idea to close connection on *any* error. For example in _getresp() resp.decode() can raise an exception, but this failure isn't related to the ability of sending QUIT and other commands.

Sample error handling in your first message looks more reliable. Set special flags after failing command (but only if error is related to the connection), and ignore QUIT errors if it is set. After successful command this flag should be reset.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22350>
_______________________________________

From report at bugs.python.org  Sun Mar 22 15:55:10 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Mar 2015 14:55:10 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1427036110.0.0.422096235087.issue23700@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Indeed. And all the comment could be better.

Does anyone want to write better comment in the light of recent estimations?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Sun Mar 22 16:11:03 2015
From: report at bugs.python.org (Akira Li)
Date: Sun, 22 Mar 2015 15:11:03 +0000
Subject: [issue10482] subprocess and deadlock avoidance
In-Reply-To: <1290320162.59.0.372707956205.issue10482@psf.upfronthosting.co.za>
Message-ID: <1427037063.58.0.0681831152823.issue10482@psf.upfronthosting.co.za>


Changes by Akira Li <4kir4.1i at gmail.com>:


----------
nosy: +akira

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10482>
_______________________________________

From report at bugs.python.org  Sun Mar 22 16:32:42 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 22 Mar 2015 15:32:42 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multiple installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1427038362.34.0.513897186499.issue23546@psf.upfronthosting.co.za>


Steve Dower added the comment:

Also, that should be "py -3 -m idlelib.idle %1" so we get the actual latest IDLE from the context menu. (This does not affect the start menu items at all.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sun Mar 22 16:33:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Mar 2015 15:33:18 +0000
Subject: [issue23657] Don't do isinstance checks in zipapp
In-Reply-To: <1426258210.85.0.503105299924.issue23657@psf.upfronthosting.co.za>
Message-ID: <20150322153314.11918.75950@psf.io>


Roundup Robot added the comment:

New changeset 0b2993742650 by Paul Moore in branch 'default':
#23657 Don't explicitly do an isinstance check for str in zipapp
https://hg.python.org/cpython/rev/0b2993742650

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23657>
_______________________________________

From report at bugs.python.org  Sun Mar 22 16:36:40 2015
From: report at bugs.python.org (=?utf-8?q?Saulius_=C5=BDemaitaitis?=)
Date: Sun, 22 Mar 2015 15:36:40 +0000
Subject: [issue23739] locale.setlocale checks locale name for string
 incorrectly
Message-ID: <1427038600.94.0.309195930192.issue23739@psf.upfronthosting.co.za>


New submission from Saulius ?emaitaitis:

Steps to reproduce:

python2.7 -c "import locale; locale.setlocale(locale.LC_ALL, u'en_US')"

Raises: ValueError: too many values to unpack

Problem lies in locale.py file from the standard library. It checks if locale is string incorrectly:

    if locale and type(locale) is not type(""):
        # convert to string
        locale = normalize(_build_localename(locale))

I think it should instead check if locale is basestring:

    locale and not isinstance(locale, basestring):
        # <..>

If above fix looks correct I'll submit it as a patch.

----------
components: Library (Lib)
messages: 238914
nosy: Saulius ?emaitaitis
priority: normal
severity: normal
status: open
title: locale.setlocale checks locale name for string incorrectly
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23739>
_______________________________________

From report at bugs.python.org  Sun Mar 22 16:39:39 2015
From: report at bugs.python.org (=?utf-8?q?Saulius_=C5=BDemaitaitis?=)
Date: Sun, 22 Mar 2015 15:39:39 +0000
Subject: [issue23739] locale.setlocale checks locale name for string
 incorrectly
In-Reply-To: <1427038600.94.0.309195930192.issue23739@psf.upfronthosting.co.za>
Message-ID: <1427038779.37.0.278525174808.issue23739@psf.upfronthosting.co.za>


Saulius ?emaitaitis added the comment:

Python 2.7.9 (default, Jan 29 2015, 06:27:40)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23739>
_______________________________________

From report at bugs.python.org  Sun Mar 22 17:00:10 2015
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Sun, 22 Mar 2015 16:00:10 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1427040010.4.0.766661430231.issue23725@psf.upfronthosting.co.za>


Zbyszek J?drzejewski-Szmek added the comment:

v2:
- remove reflows
- update TemporaryDirectory description too
- do not call things which are not functions "functions"
- with O_TMPFILE the file is not unlinked, also update TemporaryFile description for that
- link to Examples

----------
Added file: http://bugs.python.org/file38634/0001-docs-update-description-of-TemporaryFile-and-tempfil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23725>
_______________________________________

From report at bugs.python.org  Sun Mar 22 17:10:36 2015
From: report at bugs.python.org (SilentGhost)
Date: Sun, 22 Mar 2015 16:10:36 +0000
Subject: [issue23739] locale.setlocale checks locale name for string
 incorrectly
In-Reply-To: <1427038600.94.0.309195930192.issue23739@psf.upfronthosting.co.za>
Message-ID: <1427040636.27.0.502038329388.issue23739@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +lemburg, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23739>
_______________________________________

From report at bugs.python.org  Sun Mar 22 17:16:03 2015
From: report at bugs.python.org (Paul Moore)
Date: Sun, 22 Mar 2015 16:16:03 +0000
Subject: [issue23657] Don't do isinstance checks in zipapp
In-Reply-To: <1426258210.85.0.503105299924.issue23657@psf.upfronthosting.co.za>
Message-ID: <1427040963.66.0.854066147514.issue23657@psf.upfronthosting.co.za>


Changes by Paul Moore <p.f.moore at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23657>
_______________________________________

From report at bugs.python.org  Sun Mar 22 17:22:39 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Mar 2015 16:22:39 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <1427041359.62.0.926426383482.issue23700@psf.upfronthosting.co.za>


R. David Murray added the comment:

How's this?

----------
Added file: http://bugs.python.org/file38635/csv_iter_commemt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Sun Mar 22 17:27:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Mar 2015 16:27:02 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1427041359.62.0.926426383482.issue23700@psf.upfronthosting.co.za>
Message-ID: <1798264.jFhjut7ZTo@raxxla>


Serhiy Storchaka added the comment:

LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Sun Mar 22 17:35:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Mar 2015 16:35:07 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <1426691826.62.0.385210447346.issue23700@psf.upfronthosting.co.za>
Message-ID: <20150322163504.114146.32397@psf.io>


Roundup Robot added the comment:

New changeset e9f03315d66c by R David Murray in branch '3.4':
#23700: fix/improve comment
https://hg.python.org/cpython/rev/e9f03315d66c

New changeset 64f4dbac9d07 by R David Murray in branch 'default':
Merge: #23700: fix/improve comment
https://hg.python.org/cpython/rev/64f4dbac9d07

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Sun Mar 22 17:37:16 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 Mar 2015 16:37:16 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multiple installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1427042236.71.0.606137397279.issue23546@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Some people use Windows Explorer as their default means for working with programs and files, including Python via Idle and their own .py files. What some need, as I said previously, is an explicit 'Edit with Idle x.y' for each installed Python.  They need this for the same reason that we add a separate directory to the Start Menu for each version, and not just one Python directory.  If you want me to take this request to pydev, I will, but it seems straightforward to me.

For 3.x, '-m idlelib' is sufficient, '.idle' is not needed (at least from the Windows command line).  I just verified that that 'py -3 -m idlelib path' opens path in a 3.5.0a2 Idle editor.

The fact that installing the experimental -- and broken for Idle -- alpha as non-default changes the behavior of the above incantation illustrates why separate context menu entries are needed, and why the associated command should be 'py -x.y -m idlelib %1'.

(Yes, the only option recognized by py.exe is a version option.  Anything after, like -m, is an option either for the python that py runs or the program that python runs.  '-m module' is equivalent to a .py file, so anything after that is am option for the module being run as a program.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sun Mar 22 18:11:53 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Mar 2015 17:11:53 +0000
Subject: [issue22350] nntplib file write failure causes exception from QUIT
 command
In-Reply-To: <1410061219.03.0.0230581897355.issue22350@psf.upfronthosting.co.za>
Message-ID: <1427044313.06.0.881162177175.issue22350@psf.upfronthosting.co.za>


R. David Murray added the comment:

It looks to be clearly the case that there needs to be some error handling code wrapped around the file write in _getlongresp.  Your patch doesn't do just that, however, so it seems like there may be other errors you are also worried about?  Can you explain their nature?  They should be dealt with separately from the "errors writing to file" issue, though, which is a special case.  And that case should be dealt with by draining the response before returning.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22350>
_______________________________________

From report at bugs.python.org  Sun Mar 22 18:18:33 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Mar 2015 17:18:33 +0000
Subject: [issue23738] Clarify documentation of positional-only default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1427044713.16.0.140315944043.issue23738@psf.upfronthosting.co.za>


R. David Murray added the comment:

Personally I would rather stick to the [] syntax in the docs, with the default values mentioned in the text.

----------
nosy: +georg.brandl, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23738>
_______________________________________

From report at bugs.python.org  Sun Mar 22 18:22:32 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Mar 2015 17:22:32 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1427044952.71.0.745381414157.issue2211@psf.upfronthosting.co.za>


R. David Murray added the comment:

It looks like both of those changes were part of the python3 transition, and thus not subject to our backward compatibility rules.  (Which, it should be noted, we applied rather more loosely in python 3.1, 3.2, and even to a smaller extent in 3.3).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Sun Mar 22 18:25:53 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Mar 2015 17:25:53 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1427045153.95.0.408216404068.issue2211@psf.upfronthosting.co.za>


R. David Murray added the comment:

Demien, your patch looks good to me except that it would be better to consolidate the three adjacent versionchanged entries into one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Sun Mar 22 18:28:40 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Mar 2015 17:28:40 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1427045320.11.0.478954348062.issue2211@psf.upfronthosting.co.za>


R. David Murray added the comment:

Oh, and the additional what's new text would in this case be pretty much the contents of that multi-line versionchanged entry, as a bullet item in the 'porting' section.  That is, they are behavior changes that are closer to API fixes than new features, and so don't need to be entered into the 'module improvements' section, but should be mentioned as possible porting issues (all this is IMO, of course).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Sun Mar 22 20:19:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Mar 2015 19:19:32 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <20150322191921.70050.71484@psf.io>


Roundup Robot added the comment:

New changeset 5c3dc817ffd7 by R David Murray in branch '2.7':
#23539: Set Content-Length to 0 for PUT, POST, and PATCH if body is None.
https://hg.python.org/cpython/rev/5c3dc817ffd7

New changeset f6f72422df96 by R David Murray in branch '3.4':
#23539: Set Content-Length to 0 for PUT, POST, and PATCH if body is None.
https://hg.python.org/cpython/rev/f6f72422df96

New changeset 643471ed8415 by R David Murray in branch 'default':
Merge: #23539: Set Content-Length to 0 for PUT, POST, and PATCH if body is None.
https://hg.python.org/cpython/rev/643471ed8415

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23539>
_______________________________________

From report at bugs.python.org  Sun Mar 22 20:21:10 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Mar 2015 19:21:10 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <1427052070.82.0.280891967541.issue23539@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks James and Demien.  I decided to rewrite the 'request' docs for Python3 to make them easier to follow (and more accurate).  Hopefully I didn't make any mistakes, but you might want to review it just in case.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23539>
_______________________________________

From report at bugs.python.org  Sun Mar 22 20:28:44 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Mar 2015 19:28:44 +0000
Subject: [issue23740] http.client request and send method have some datatype
 issues
Message-ID: <1427052524.74.0.134908492197.issue23740@psf.upfronthosting.co.za>


New submission from R. David Murray:

While committing the patch for issue 23539 I decided to rewrite the 'request' docs for clarity.  I doing so I found that http.client isn't as consistent as it could be about how it handles bytes and strings.  Two points specifically:  it will only take the length of a bytes-like object (to supply a default Content-Length header) if isinstance(x, bytes) is true (that is, it doesn't take the length of eg array or memoryview objects), and (2) if an iterable is passed in, it must be an iterable of bytes-like objects.  Since it already automatically encodes string objects and text files, for consistency it should probably also encode strings if they are passed in via an iterator.

----------
keywords: easy
messages: 238928
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: http.client request and send method have some datatype issues
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23740>
_______________________________________

From report at bugs.python.org  Sun Mar 22 20:28:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 Mar 2015 19:28:57 +0000
Subject: [issue23700] tempfile.NamedTemporaryFile can close too early if used
 as iterator
In-Reply-To: <20150322163504.114146.32397@psf.io>
Message-ID: <CAMpsgwZTsjeY2LFTVxx+EbTXg5xY8PoHOP-7wbFTasS3CJWm1w@mail.gmail.com>


STINNER Victor added the comment:

Yeah, the new comment is better :-) Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23700>
_______________________________________

From report at bugs.python.org  Sun Mar 22 20:39:09 2015
From: report at bugs.python.org (James Rutherford)
Date: Sun, 22 Mar 2015 19:39:09 +0000
Subject: [issue23539] Content-length not set for HTTP methods expecting body
 when body is None
In-Reply-To: <1425058243.4.0.797359828619.issue23539@psf.upfronthosting.co.za>
Message-ID: <1427053149.82.0.875492721969.issue23539@psf.upfronthosting.co.za>


James Rutherford added the comment:

Updated docs look good to me, thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23539>
_______________________________________

From report at bugs.python.org  Sun Mar 22 21:01:53 2015
From: report at bugs.python.org (paul j3)
Date: Sun, 22 Mar 2015 20:01:53 +0000
Subject: [issue23487] argparse: add_subparsers 'action' broken
In-Reply-To: <1424417043.22.0.71313795028.issue23487@psf.upfronthosting.co.za>
Message-ID: <1427054512.99.0.844230046326.issue23487@psf.upfronthosting.co.za>


paul j3 added the comment:

It certainly looks like a documentation issue.  `action` doesn't make sense here.  `add_subparsers` normally creates an Action of type `_SubParsersAction`.  

'action' for normal 'add_argument' command defines the Action type created at that time.  Conceivably a user might want to use a customized '_SubParsersAction', but it shouldn't be as easy as just specifying 'action' in the 'add_subparsers' command.

And specifying something other than the default 'store' action class for the arguments of the parsers doesn't make sense.

But I'm puzzled by the error message you got.  I'll have to run some tests to figure out what is going on.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23487>
_______________________________________

From report at bugs.python.org  Sun Mar 22 21:04:07 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Sun, 22 Mar 2015 20:04:07 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1427054647.93.0.220337626101.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

Ryan,
Has anyone taken you up on the non-KBOX testing?
Do you need me to test the patches within the KBOX environment?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Sun Mar 22 21:07:02 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Mar 2015 20:07:02 +0000
Subject: [issue23647] imaplib.py MAXLINE value is too low for gmail
In-Reply-To: <1426174765.08.0.908432771269.issue23647@psf.upfronthosting.co.za>
Message-ID: <1427054822.79.0.0940130140442.issue23647@psf.upfronthosting.co.za>


R. David Murray added the comment:

Now that I've had time to look at this, I see that in fact RFC2683 says nothing about what value MAXLINE should have, unless one is reasoning by analogy.  It is concerned with *command line* lengths from the client to the server, not about server responses.  It seems as though we really should be handling more or less arbitrary length lines in the server response.

I'll bump up the limit in the meantime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23647>
_______________________________________

From report at bugs.python.org  Sun Mar 22 21:10:58 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Sun, 22 Mar 2015 20:10:58 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1427055058.31.0.359344501656.issue23496@psf.upfronthosting.co.za>


Ryan Gonzalez added the comment:

Cyd: if you could do that, it would be great!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Sun Mar 22 21:18:44 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Mar 2015 20:18:44 +0000
Subject: [issue23740] http.client request and send method have some datatype
 issues
In-Reply-To: <1427052524.74.0.134908492197.issue23740@psf.upfronthosting.co.za>
Message-ID: <1427055524.33.0.271807695918.issue23740@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue23350 and issue23360.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23740>
_______________________________________

From report at bugs.python.org  Sun Mar 22 21:21:12 2015
From: report at bugs.python.org (paul j3)
Date: Sun, 22 Mar 2015 20:21:12 +0000
Subject: [issue23378] argparse.add_argument action parameter should allow
 value extend
In-Reply-To: <1422886990.52.0.318776752581.issue23378@psf.upfronthosting.co.za>
Message-ID: <1427055672.79.0.749881135256.issue23378@psf.upfronthosting.co.za>


paul j3 added the comment:

My opinion is that this is an unnecessary addition.

Reasons:

- it is easy to add as a custom action class

- I haven't seen other requests for it

- the append retains information about the argument strings that extend looses

- it is easy flatten the appended attribute, e.g with a simple loop or a flattener like 'list(itertools.chain(*ll))'

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23378>
_______________________________________

From report at bugs.python.org  Sun Mar 22 21:21:20 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Mar 2015 20:21:20 +0000
Subject: [issue23647] imaplib.py MAXLINE value is too low for gmail
In-Reply-To: <1426174765.08.0.908432771269.issue23647@psf.upfronthosting.co.za>
Message-ID: <20150322202102.70026.35884@psf.io>


Roundup Robot added the comment:

New changeset a56aa567072c by R David Murray in branch '2.7':
#23647: Increase imaplib's MAXLINE to accommodate modern mailbox sizes.
https://hg.python.org/cpython/rev/a56aa567072c

New changeset c1348ada8fc6 by R David Murray in branch '3.4':
#23647: Increase imaplib's MAXLINE to accommodate modern mailbox sizes.
https://hg.python.org/cpython/rev/c1348ada8fc6

New changeset be6c4569f845 by R David Murray in branch 'default':
Merge: #23647: Increase imaplib's MAXLINE to accommodate modern mailbox sizes.
https://hg.python.org/cpython/rev/be6c4569f845

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23647>
_______________________________________

From report at bugs.python.org  Sun Mar 22 21:30:47 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Mar 2015 20:30:47 +0000
Subject: [issue23350] Content-length is incorrect when request body is a list
 or tuple
In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za>
Message-ID: <1427056247.46.0.681124347173.issue23350@psf.upfronthosting.co.za>


R. David Murray added the comment:

I just updated the docs to what I think is the current reality.  See issue 23740 for what I think are problems with the current implementation, aside from any enhancement of computing a length for tuple or list.  Since the latter cannot be done reliably unless we know the list or tuple is all bytes, I propose that we don't do it at all (since I'd like to see iterables of text strings supported).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23350>
_______________________________________

From report at bugs.python.org  Sun Mar 22 21:34:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Mar 2015 20:34:48 +0000
Subject: [issue23350] Content-length is incorrect when request body is a list
 or tuple
In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za>
Message-ID: <1427056488.2.0.669214373754.issue23350@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, the current reality not counting the bug reported in this issue.  So, I documented it as if the fix here is to not set the length when body is an iterator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23350>
_______________________________________

From report at bugs.python.org  Sun Mar 22 21:35:43 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Mar 2015 20:35:43 +0000
Subject: [issue23647] imaplib.py MAXLINE value is too low for gmail
In-Reply-To: <1426174765.08.0.908432771269.issue23647@psf.upfronthosting.co.za>
Message-ID: <1427056543.49.0.678525900144.issue23647@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords:  -patch
stage: commit review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23647>
_______________________________________

From report at bugs.python.org  Sun Mar 22 21:43:29 2015
From: report at bugs.python.org (paul j3)
Date: Sun, 22 Mar 2015 20:43:29 +0000
Subject: [issue23298] Add ArgumentParser.add_mutually_dependence_group
In-Reply-To: <1421905312.49.0.407798450784.issue23298@psf.upfronthosting.co.za>
Message-ID: <1427057009.71.0.443641518995.issue23298@psf.upfronthosting.co.za>


paul j3 added the comment:

http://bugs.python.org/issue11588 is an earlier request for 'necessarily inclusive' groups.

The patches that I proposed there are more general, allowing for other logical combinations of arguments, as well as nesting groups.  As such it is more complex than your patch, but the basic testing idea is the same - 

    At the end of _parse_known_args check the group's actions
    against the ones that have been parsed.  I use the existing
    'seen_actions' or 'seen_nondefault_actions' rather than 
    check the namespace directly.

I also tried to construct this testing as a 'hook' that the user could customize.

Your test, since it uses the Namespace and Action default, rather than the 'seen_actions' set, could just as well be run AFTER parse_args.  That's the kind of testing that Stackoverflow answers often suggest for similar questions.

In some cases it's also possible to write custom Action classes that handle this kind of interdependency.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23298>
_______________________________________

From report at bugs.python.org  Sun Mar 22 22:15:23 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 22 Mar 2015 21:15:23 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multiple installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1427058923.19.0.717067459929.issue23546@psf.upfronthosting.co.za>


Steve Dower added the comment:

> If you want me to take this request to pydev, I will, but it seems straightforward to me.

"I'll go get Dad" seems a fairly immature threat and it's really not necessary.

However, (after writing and then deleting a long exposition of the options) the most reliable way of doing this is indeed to install one context menu item per Python install, and I may even be able to handle cascading, at least for 3.5 and later. The one caveat is that if you don't install the launcher you won't see the association at all, and this limitation is necessary to avoid corruption due to parallel installs (granted Python 3.4 and earlier will corrupt the association, but there's nothing we can do about that now).

When I get home tonight I'll update the patch I've been working on and make sure it works as I'm expecting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sun Mar 22 22:19:46 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Sun, 22 Mar 2015 21:19:46 +0000
Subject: [issue23378] argparse.add_argument action parameter should allow
 value extend
In-Reply-To: <1422886990.52.0.318776752581.issue23378@psf.upfronthosting.co.za>
Message-ID: <1427059186.33.0.754975535162.issue23378@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

> - I haven't seen other requests for it

For the record, an Extend custom action class is one of very few such classes I have ever written for argparse for exactly the OP's usecase, i.e., it is useful for any parser that should accept the same option multiple times, while accepting multiple arguments each time.
It *is* very simple to implement (and that's why I never asked for it as a feature), but only once you've understood custom action classes, which are not exactly for beginners.
All in all, I'm +1 on the request.

----------
nosy: +wolma

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23378>
_______________________________________

From report at bugs.python.org  Sun Mar 22 22:26:16 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Mar 2015 21:26:16 +0000
Subject: [issue23741] Small pprint refactoring
Message-ID: <1427059576.13.0.118751604266.issue23741@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

This issue is not so ambitious as issue7434. Proposed match only slightly refactor current implementation, so it becomes easier extensible for standard types. No public interface provided, this task left for issue7434. No behavior changed.

----------
assignee: serhiy.storchaka
components: Library (Lib)
files: pprint_refactoring.diff
keywords: patch
messages: 238943
nosy: fdrake, pitrou, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Small pprint refactoring
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38636/pprint_refactoring.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23741>
_______________________________________

From report at bugs.python.org  Sun Mar 22 23:04:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Mar 2015 22:04:23 +0000
Subject: [issue18684] Pointers point out of array bound in _sre.c
In-Reply-To: <1375962984.07.0.918202360038.issue18684@psf.upfronthosting.co.za>
Message-ID: <1427061863.47.0.0927781238448.issue18684@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is recent patch.

----------
versions: +Python 3.5 -Python 3.4
Added file: http://bugs.python.org/file38637/sre_ptr_out_of_bounds_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18684>
_______________________________________

From report at bugs.python.org  Sun Mar 22 23:10:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Mar 2015 22:10:08 +0000
Subject: [issue18684] Pointers point out of array bound in _sre.c
In-Reply-To: <1375962984.07.0.918202360038.issue18684@psf.upfronthosting.co.za>
Message-ID: <1427062208.34.0.46846379743.issue18684@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file38637/sre_ptr_out_of_bounds_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18684>
_______________________________________

From report at bugs.python.org  Sun Mar 22 23:10:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Mar 2015 22:10:50 +0000
Subject: [issue18684] Pointers point out of array bound in _sre.c
In-Reply-To: <1375962984.07.0.918202360038.issue18684@psf.upfronthosting.co.za>
Message-ID: <1427062250.98.0.843398469951.issue18684@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file38638/sre_ptr_out_of_bounds_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18684>
_______________________________________

From report at bugs.python.org  Sun Mar 22 23:20:54 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 Mar 2015 22:20:54 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multiple installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1427062854.26.0.0620527970287.issue23546@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Collapsing multiple 'Edit with Idle x.y' entries into one 'Edit with Idle >' + submenu (or 'Edit with Idle 3 >' + submenu) would be fine once practical to do so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sun Mar 22 23:21:45 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Sun, 22 Mar 2015 22:21:45 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1427062905.35.0.816896311949.issue23688@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

Here is a revised version of my patch addressing Serhiy's review comments.

----------
Added file: http://bugs.python.org/file38639/write_bytes_like_objects_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Sun Mar 22 23:29:57 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Mar 2015 22:29:57 +0000
Subject: [issue23729] Import ElementTree documentation for namespaces and XPath
In-Reply-To: <1426926572.78.0.5131365949.issue23729@psf.upfronthosting.co.za>
Message-ID: <20150322222954.114154.71372@psf.io>


Roundup Robot added the comment:

New changeset 88b9af268cca by Raymond Hettinger in branch '3.4':
Issue 23729:  Document ElementTree namespace handling and fix an omission in the XPATH predicate table.
https://hg.python.org/cpython/rev/88b9af268cca

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23729>
_______________________________________

From report at bugs.python.org  Sun Mar 22 23:31:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Mar 2015 22:31:38 +0000
Subject: [issue23729] Import ElementTree documentation for namespaces and XPath
In-Reply-To: <1426926572.78.0.5131365949.issue23729@psf.upfronthosting.co.za>
Message-ID: <20150322223136.16934.14791@psf.io>


Roundup Robot added the comment:

New changeset 000814bbc899 by Raymond Hettinger in branch '2.7':
Issue 23729:  Document ElementTree namespace handling and fix an omission in the XPATH predicate table.
https://hg.python.org/cpython/rev/000814bbc899

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23729>
_______________________________________

From report at bugs.python.org  Sun Mar 22 23:31:56 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 Mar 2015 22:31:56 +0000
Subject: [issue23729] Import ElementTree documentation for namespaces and XPath
In-Reply-To: <1426926572.78.0.5131365949.issue23729@psf.upfronthosting.co.za>
Message-ID: <1427063516.6.0.664536462297.issue23729@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23729>
_______________________________________

From report at bugs.python.org  Sun Mar 22 23:33:45 2015
From: report at bugs.python.org (Steve Dower)
Date: Sun, 22 Mar 2015 22:33:45 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multiple installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1427063625.78.0.125362879663.issue23546@psf.upfronthosting.co.za>


Steve Dower added the comment:

I'll try, but if it's not feasible now I doubt it will become feasible until the next installer revamp. Completely separate items are certainly okay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Sun Mar 22 23:48:33 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Mar 2015 22:48:33 +0000
Subject: [issue21526] Support new booleans in Tkinter
In-Reply-To: <1400445691.82.0.48051274053.issue21526@psf.upfronthosting.co.za>
Message-ID: <20150322224830.11912.80939@psf.io>


Roundup Robot added the comment:

New changeset e9d86c1de292 by Serhiy Storchaka in branch 'default':
Issue #21526: Tkinter now supports new boolean type in Tcl 8.5.
https://hg.python.org/cpython/rev/e9d86c1de292

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21526>
_______________________________________

From report at bugs.python.org  Mon Mar 23 00:10:36 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Mar 2015 23:10:36 +0000
Subject: [issue23252] Add support of writing to unseekable file in zipfile
In-Reply-To: <1421438148.04.0.307260333821.issue23252@psf.upfronthosting.co.za>
Message-ID: <20150322231034.7255.45322@psf.io>


Roundup Robot added the comment:

New changeset 19f36a2a34ec by Serhiy Storchaka in branch 'default':
Issue #23252:  Added support for writing ZIP files to unseekable streams.
https://hg.python.org/cpython/rev/19f36a2a34ec

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23252>
_______________________________________

From report at bugs.python.org  Mon Mar 23 00:24:20 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Mar 2015 23:24:20 +0000
Subject: [issue23740] http.client request and send method have some datatype
 issues
In-Reply-To: <1427052524.74.0.134908492197.issue23740@psf.upfronthosting.co.za>
Message-ID: <1427066660.06.0.425196731022.issue23740@psf.upfronthosting.co.za>


Martin Panter added the comment:

Summary of the main supported types as I see them, whether documented, undocumented, or only working by accident:

* None
* Bytes-like sequences, e.g. bytes(), bytearray. I believe Content-Length is actually automatically set for all these types.
* Arbitrary bytes-like objects, including array.array("I") and ctypes structures, if custom Content-Length provided (HTTP over TCP only)
* str() objects, to be automatically encoded with Latin-1
* File reader objects not supporting stat(), e.g. BytesIO
* File with valid stat().st_size, i.e. not named pipes
* Binary file reader
* Text file reader with mode attribute without a "b", automatically encoded with Latin-1
* Any iterable of bytes-like sequences
* Any iterable of arbitrary bytes-like objects (HTTP over TCP only)

Arbitrary bytes-like objects are not properly supported by SSLSocket.sendall(). After all, the non-SSL socket.sendall() documentation does not explicitly mention supporting arbitrary bytes-like objects either, though it does seem to support them in practice.

Suggested documentation fixes and additions:
* Clarify Content-Length is added for all sequence objects, not just ?string or bytes objects?
* Warn that a custom Content-Length should be provided with non-bytes sequences, and with special files like named pipes, since the len() or stat() call will give the wrong value
* end_headers() should mention byte string rather than just ?string?, since it does not (yet) accept Latin-1 text strings
* end_headers() should not mention sending in the same packet either, since separate sendall() calls are made for all cases; see Issue 23302
* send() should clarify what it accepts
* Either omit mentioning arbitrary bytes-like objects, or add support to SSLSocket.sendall() and document support by non-SSL socket.sendall()

I would support encoding iterables of str() objects for consistency. The patch for Issue 23350 already does this, although I am starting to question the wisdom of special-casing lists and tuples in that patch.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23740>
_______________________________________

From report at bugs.python.org  Mon Mar 23 00:32:41 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 22 Mar 2015 23:32:41 +0000
Subject: [issue21062] Evalute all import-related modules for best practices
In-Reply-To: <1395763138.25.0.943943141564.issue21062@psf.upfronthosting.co.za>
Message-ID: <1427067161.0.0.0650751189871.issue21062@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Just a gentle reminder as it refers to zipimport and a patch was committed just a few days ago.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21062>
_______________________________________

From report at bugs.python.org  Mon Mar 23 00:35:10 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Mar 2015 23:35:10 +0000
Subject: [issue23350] Content-length is incorrect when request body is a list
 or tuple
In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za>
Message-ID: <1427067310.14.0.0737400978756.issue23350@psf.upfronthosting.co.za>


Martin Panter added the comment:

David: Calculating the length of a list or tuple of Latin-1 text strings should actually be straight-forward and reliable, because it is a single-byte encoding.

However I am starting to think adding a new special case for lists and tuples is a bad idea. There are already way too many special cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23350>
_______________________________________

From report at bugs.python.org  Mon Mar 23 00:39:01 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 22 Mar 2015 23:39:01 +0000
Subject: [issue21120] PyArena type is used in headers from the limited API
In-Reply-To: <1396339821.73.0.473299529971.issue21120@psf.upfronthosting.co.za>
Message-ID: <1427067541.97.0.265663726642.issue21120@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I'm not sure if this should be a compile error or an enhancement request, can someone please advise.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21120>
_______________________________________

From report at bugs.python.org  Mon Mar 23 00:43:39 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 22 Mar 2015 23:43:39 +0000
Subject: [issue21315] email._header_value_parser does not recognise in-line
 encoding changes
In-Reply-To: <1398009498.59.0.139606640186.issue21315@psf.upfronthosting.co.za>
Message-ID: <1427067819.86.0.177566747639.issue21315@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Could someone formally review the patch please, it's only three additional lines of code and a new test.

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21315>
_______________________________________

From report at bugs.python.org  Mon Mar 23 00:47:10 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 22 Mar 2015 23:47:10 +0000
Subject: [issue21319] WindowsRegistryFinder never added to sys.meta_path
In-Reply-To: <1398056666.81.0.531490496163.issue21319@psf.upfronthosting.co.za>
Message-ID: <1427068030.42.0.589362829167.issue21319@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Just making sure our Windows people are aware of this issue.

----------
components: +Windows
nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21319>
_______________________________________

From report at bugs.python.org  Mon Mar 23 00:57:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Mar 2015 23:57:49 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1427068669.08.0.403531625492.issue23725@psf.upfronthosting.co.za>


Martin Panter added the comment:

[Padding]

Please start sentences with capital letters, specifically ?mkstemp() and mkdtemp() are lower-level functions . . .?.

The new sentence at the top about context managers seems out-of-place. Perhaps something like ?They can also be used as context managers, which triggers the cleanup on exit.?

The new paragraph about cleanup of TemporaryFile is good, but I think it now makes the last sentence of that entry redundant: ?. . . can be used in a ?with? statement . . .?

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23725>
_______________________________________

From report at bugs.python.org  Mon Mar 23 01:06:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Mar 2015 00:06:39 +0000
Subject: [issue23740] http.client request and send method have some datatype
 issues
In-Reply-To: <1427052524.74.0.134908492197.issue23740@psf.upfronthosting.co.za>
Message-ID: <1427069199.54.0.509061293129.issue23740@psf.upfronthosting.co.za>


Martin Panter added the comment:

As well as encoding iterables of str(), text files could also be handled more consistently by checking the read() return type. That would eliminate the complication of checking for a "b" mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23740>
_______________________________________

From report at bugs.python.org  Mon Mar 23 01:12:57 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 23 Mar 2015 00:12:57 +0000
Subject: [issue22468] Tarfile using fstat on GZip file object
In-Reply-To: <1411462192.65.0.458428981621.issue22468@psf.upfronthosting.co.za>
Message-ID: <1427069577.56.0.181863597584.issue22468@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

msg227328 states "it's not a really common scenario" but I believe we must still allow for it, what do others think?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22468>
_______________________________________

From report at bugs.python.org  Mon Mar 23 01:16:13 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Mar 2015 00:16:13 +0000
Subject: [issue22163] max_wbits set incorrectly to -zlib.MAX_WBITS in tarfile, 
 shouldn't be negative
In-Reply-To: <1407409352.24.0.421737248606.issue22163@psf.upfronthosting.co.za>
Message-ID: <1427069773.96.0.926141486024.issue22163@psf.upfronthosting.co.za>


Martin Panter added the comment:

I suspect the patch is wrong and the zlib documentation needs fixing instead. See <https://docs.python.org/dev/library/zlib.html#zlib.decompress> for a possible explanation of the negative sign, although it would make more sense for compress() which would actually create a ?gzip? header.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22163>
_______________________________________

From report at bugs.python.org  Mon Mar 23 01:40:17 2015
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 23 Mar 2015 00:40:17 +0000
Subject: [issue23350] Content-length is incorrect when request body is a list
 or tuple
In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za>
Message-ID: <1427071217.56.0.3661839356.issue23350@psf.upfronthosting.co.za>


Demian Brecht added the comment:

@Serhiy:
> Content-Length shouldn't be calculated for lists, tuples, and other non-bytes-compatible sequences.

I'd agree with this if it wasn't relatively trivial to calculate. There's no reason that I can think of to exclude the auto-generated Content-Length header for data types for which the size is known.


@Martin:
> Technically I don?t think there is a bug.

The bug is that the Content-Length header is currently added for bodies that are lists and tuples and the value is incorrect. For example:

con.request('POST', '/', ['aaa', 'bbb', 'ccc'])

results in 

Host: example.com
Accept-Encoding: identity
Content-Length: 3


@David:
> Since the latter cannot be done reliably unless we know the list or tuple is all bytes, I propose that we don't do it at all (since I'd like to see iterables of text strings supported).

The patch here adds support for iterables of text strings (as well as iterables comprised of both bytes and strings). Content-Length can be computed reliably as the size of a latin1-encoded string will be identical to the original string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23350>
_______________________________________

From report at bugs.python.org  Mon Mar 23 01:50:30 2015
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 23 Mar 2015 00:50:30 +0000
Subject: [issue23740] http.client request and send method have some datatype
 issues
In-Reply-To: <1427052524.74.0.134908492197.issue23740@psf.upfronthosting.co.za>
Message-ID: <1427071830.93.0.764377641886.issue23740@psf.upfronthosting.co.za>


Demian Brecht added the comment:

FWIW, I've done some additional work to request/send in issue #12319 where I've added support for chunked request encoding.

@David
> if an iterable is passed in, it must be an iterable of bytes-like objects

This specific issue is addressed in the patch in #23350.

@Martin
> text files could also be handled more consistently by checking the read() return type

I wouldn't be opposed to this at all. In fact, I was going to initially make that change in #12319, but wanted to keep the change surface minimal and realistically, peeking at the data type rather than checking for 'b' in mode doesn't /really/ make that much of a difference.

----------
nosy: +demian.brecht

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23740>
_______________________________________

From report at bugs.python.org  Mon Mar 23 01:50:46 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Mar 2015 00:50:46 +0000
Subject: [issue23729] Import ElementTree documentation for namespaces and XPath
In-Reply-To: <1426926572.78.0.5131365949.issue23729@psf.upfronthosting.co.za>
Message-ID: <1427071846.23.0.862415026701.issue23729@psf.upfronthosting.co.za>


Martin Panter added the comment:

Hi Raymond, perhaps you didn?t see the comments on your second patch on Reitveld. E.g. fromstring() does not have an underscore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23729>
_______________________________________

From report at bugs.python.org  Mon Mar 23 02:06:32 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 23 Mar 2015 01:06:32 +0000
Subject: [issue16328] win_add2path.py sets wrong user path
In-Reply-To: <1351255282.63.0.930970476961.issue16328@psf.upfronthosting.co.za>
Message-ID: <1427072792.09.0.0310408846996.issue16328@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Presumably we can look at this after the discussions about the installer scheduled for PyCon 2015?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16328>
_______________________________________

From report at bugs.python.org  Mon Mar 23 02:15:34 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Mar 2015 01:15:34 +0000
Subject: [issue22468] Tarfile using fstat on GZip file object
In-Reply-To: <1411462192.65.0.458428981621.issue22468@psf.upfronthosting.co.za>
Message-ID: <1427073334.05.0.397999581584.issue22468@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think a warning in the documentation might be helpful.

However a special check in the code doesn?t seem right. Would you check for LZMAFile and BZ2File as well? Some of the other attributes (modification time, owner, etc) may be useful even for a GzipFile, and the programmer can just overwrite the file size attribute if necessary.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22468>
_______________________________________

From report at bugs.python.org  Mon Mar 23 02:35:37 2015
From: report at bugs.python.org (=?utf-8?q?Manuel_V=C3=B6gele?=)
Date: Mon, 23 Mar 2015 01:35:37 +0000
Subject: [issue23742] expandvars removes single quotes ( ' )
Message-ID: <1427074537.6.0.869076773491.issue23742@psf.upfronthosting.co.za>


New submission from Manuel V?gele:

When executing

os.path.expandvars("%SystemDrive%\\Foo'Bar")

the function erases the ' returning

'C:\\FooBar'

using Python 3.4.3 on Windows 7

----------
components: Library (Lib)
messages: 238968
nosy: manuel_v, serhiy.storchaka
priority: normal
severity: normal
status: open
title: expandvars removes single quotes ( ' )
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23742>
_______________________________________

From report at bugs.python.org  Mon Mar 23 02:50:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Mar 2015 01:50:15 +0000
Subject: [issue23740] http.client request and send method have some datatype
 issues
In-Reply-To: <1427052524.74.0.134908492197.issue23740@psf.upfronthosting.co.za>
Message-ID: <1427075415.23.0.920792292656.issue23740@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yeah, if we're going to check the type for iterables to convert strings, we might as well check the type for read() as well.

The bit about the len not being set except for str and bytes was me mis-remembering what I read in the code.  (The isinstance check is about whether _send_output sends the body in the same packet.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23740>
_______________________________________

From report at bugs.python.org  Mon Mar 23 02:55:45 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Mar 2015 01:55:45 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1427075745.81.0.62504669648.issue23725@psf.upfronthosting.co.za>


R. David Murray added the comment:

If the first word is a function name that does not start with a capital, the sentence can't start with a capital.  Sometimes it is worthwhile to reword the sentence so you can start it with a capitalizable word, but sometimes it isn't.  (I haven't reviewed the patch, just putting in my two cents on this particular topic ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23725>
_______________________________________

From report at bugs.python.org  Mon Mar 23 03:07:22 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Mar 2015 02:07:22 +0000
Subject: [issue23742] expandvars removes single quotes ( ' )
In-Reply-To: <1427074537.6.0.869076773491.issue23742@psf.upfronthosting.co.za>
Message-ID: <1427076442.93.0.794970913839.issue23742@psf.upfronthosting.co.za>


R. David Murray added the comment:

It apparently only loses unbalanced single quotes.

----------
components: +Windows -Library (Lib)
nosy: +r.david.murray, steve.dower, tim.golden, zach.ware
stage:  -> needs patch
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23742>
_______________________________________

From report at bugs.python.org  Mon Mar 23 03:16:14 2015
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Mon, 23 Mar 2015 02:16:14 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1427076973.99.0.268609280426.issue23725@psf.upfronthosting.co.za>


Zbyszek J?drzejewski-Szmek added the comment:

> Please start sentences with capital letters, specifically ?mkstemp() and mkdtemp() are lower-level functions . . .?.

This would make the sentence more convoluted... I think that with markup it is pretty clear that this is a function name and the lowercase letter it not misleading.

> The new sentence at the top about context managers seems out-of-place. Perhaps something like ?They can also be used as context managers, which triggers the cleanup on exit.?

The two sentences are merged now.

> The new paragraph about cleanup of TemporaryFile is good, but I think it now makes the last sentence of that entry redundant: ?. . . can be used in a ?with? statement . . .?

Yes, removed.

v3:
- remove sentence ?. . . can be used in a ?with? statement . . .?
- merge two senteces in first paragraph

----------
Added file: http://bugs.python.org/file38640/0001-docs-update-description-of-TemporaryFile-and-tempfil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23725>
_______________________________________

From report at bugs.python.org  Mon Mar 23 03:34:53 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Mar 2015 02:34:53 +0000
Subject: [issue23676] Add support of UnicodeTranslateError in standard error
 handlers
In-Reply-To: <1426456748.16.0.28109004659.issue23676@psf.upfronthosting.co.za>
Message-ID: <1427078093.49.0.403092764836.issue23676@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think I saw your patch for Issue 18814 proposes to use UnicodeTranslateError. Is there any other case where it is used, either currently or in the past? All I know of it is the documentation, which says it is raised ?during translating?.

Experimenting with the constructor reveals that the ?object? attribute is only allowed to be a text string (not bytes). So perhaps ?translating? actually means converting from text strings to text strings, like ?rot-13?. It would be nice if this were documented somewhere, rather than just saying translating is now supported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23676>
_______________________________________

From report at bugs.python.org  Mon Mar 23 03:52:45 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Mar 2015 02:52:45 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1427079165.52.0.141060671086.issue23725@psf.upfronthosting.co.za>


Martin Panter added the comment:

The current proposed text would be rendered something like this:

'''
TemporaryFile, NamedTemporaryFile, TemporaryDirectory, SpooledTemporaryFile are high-level interfaces which provide automatic cleanup and can be used as context managers. mkstemp() and mkdtemp() are lower-level functions which require manual cleanup.
'''

My opinion is it is very often worthwhile rewording the sentence. It is awkward to read at the moment, especially if you are trying to skim over it without reading the whole paragraph. Unlike in Python, in English there?s always more than one way to do it. Perhaps you could consider this version instead:

'''
The TemporaryFile, NamedTemporaryFile, TemporaryDirectory, [and] SpooledTemporaryFile classes are high-level interfaces which provide automatic cleanup and can be used as context managers. The mkstemp() and mkdtemp() functions are lower-level, and require manual cleanup.
'''

Only about three more words, and not particularly convoluted. But if you disagree, I can live with it, since there are plenty more examples of this in the Python documentation and elsewhere :)

Other than that, I think the patch is good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23725>
_______________________________________

From report at bugs.python.org  Mon Mar 23 04:46:45 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Mar 2015 03:46:45 +0000
Subject: [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1427082405.21.0.84420392813.issue5784@psf.upfronthosting.co.za>


Martin Panter added the comment:

According to <http://zlib.net/manual.html#Advanced>, the deflateInit2(windowBits) parameter can be:

* +8 to +15 to include a ?zlib? header and trailer
* ?8 to ?15 to write a raw Deflate stream with no header nor trailer
* 16 + (8 to 15) to include a basic ?gzip? header and trailer

The inflateInit2(windowBits) parameter can also be set to the above values to specify what header and trailer to expect, and it can also be set to 0 to read the window size from the ?zlib? header itself.

Assuming that the Python module passes ?wbits? straight through to the actual ?zlib? module, I think these points could be clarified in the Python documentation.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Mon Mar 23 04:53:50 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Mar 2015 03:53:50 +0000
Subject: [issue22163] max_wbits set incorrectly to -zlib.MAX_WBITS in tarfile, 
 shouldn't be negative
In-Reply-To: <1407409352.24.0.421737248606.issue22163@psf.upfronthosting.co.za>
Message-ID: <1427082830.23.0.0499532663777.issue22163@psf.upfronthosting.co.za>


Martin Panter added the comment:

Eduardo?s patch causes many tests to fail. Abbreviated test output:

$ ./python -bWall -m test -v test_tarfile
======================================================================
ERROR: test_compare_members (test.test_tarfile.GzipStreamReadTest)
ERROR: test_empty_tarfile (test.test_tarfile.GzipStreamReadTest)
ERROR: test_fileobj_regular_file (test.test_tarfile.GzipStreamReadTest)
ERROR: test_ignore_zeros (test.test_tarfile.GzipStreamReadTest)
ERROR: test_non_existent_tarfile (test.test_tarfile.GzipStreamReadTest)
ERROR: test_null_tarfile (test.test_tarfile.GzipStreamReadTest)
ERROR: test_provoke_stream_error (test.test_tarfile.GzipStreamReadTest)
ERROR: test_read_through (test.test_tarfile.GzipStreamReadTest)
----------------------------------------------------------------------
tarfile.ReadError: invalid compressed data

======================================================================
ERROR: test_stream_padding (test.test_tarfile.GzipStreamWriteTest)
----------------------------------------------------------------------
zlib.error: Error -3 while decompressing data: invalid stored block lengths

======================================================================
FAIL: test_detect_file (test.test_tarfile.GzipDetectReadTest)
FAIL: test_detect_fileobj (test.test_tarfile.GzipDetectReadTest)
AssertionError

----------------------------------------------------------------------
Ran 387 tests in 14.216s

FAILED (failures=2, errors=9, skipped=8)

There is already Issue 5784 open about clarifying the ?wbits? parameter, so I think we can close this as a duplicate.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> raw deflate format and zlib module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22163>
_______________________________________

From report at bugs.python.org  Mon Mar 23 05:27:47 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Mar 2015 04:27:47 +0000
Subject: [issue23062] test_argparse --version test cases
In-Reply-To: <1418706736.64.0.85644160224.issue23062@psf.upfronthosting.co.za>
Message-ID: <1427084867.09.0.381455220513.issue23062@psf.upfronthosting.co.za>


Martin Panter added the comment:

Serhiy, there is already a test for that:

class TestHelpVersionAction(HelpTestCase):
    """Test the default help for the version action"""

So I still think the test is redundant, unless it is made to exercise help=SUPPRESS, as Berker?s patch does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23062>
_______________________________________

From report at bugs.python.org  Mon Mar 23 05:36:35 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Mar 2015 04:36:35 +0000
Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?=
 =?utf-8?q?=E2=80=9D_exception_message_on_Wine?=
In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za>
Message-ID: <1427085395.06.0.998173328691.issue22977@psf.upfronthosting.co.za>


Martin Panter added the comment:

V3 patch with suggested changes to the test case, though still completely untested by me.

----------
Added file: http://bugs.python.org/file38641/win-error-format-v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22977>
_______________________________________

From report at bugs.python.org  Mon Mar 23 05:57:00 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Mar 2015 04:57:00 +0000
Subject: [issue20059] Inconsistent urlparse/urllib.parse handling of invalid
 port values?
In-Reply-To: <1387842710.57.0.78188368243.issue20059@psf.upfronthosting.co.za>
Message-ID: <1427086620.64.0.430516538197.issue20059@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch v2 just changes a test to use ?with self.assertRaises()?.

The behaviour of urlparse() succeeding and then result.port failing is indeed odd and surprising. Hopefully documenting this behaviour will help with the ?surprising? aspect. But changing it would surely break compatibility. For example, the following is still potentially useful:

>>> urlsplit("http://localhost:ipp/").netloc
'localhost:ipp'

On Unix, some programs look up port names in /etc/services, even though this is not valid for URLs according to the RFCs, and urlsplit().port does not support it. In this case ?ipp? would be whatever port the Internet Printing Protocol server is configured to run on.

----------
Added file: http://bugs.python.org/file38642/port-ValueError.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20059>
_______________________________________

From report at bugs.python.org  Mon Mar 23 06:03:31 2015
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Mon, 23 Mar 2015 05:03:31 +0000
Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1427087011.23.0.969326229601.issue23725@psf.upfronthosting.co.za>


Zbyszek J?drzejewski-Szmek added the comment:

Actually they are not classes, so the proposed wording cannot be used. But indeed it sounds better with the "and".

v4:
- one more "and"

----------
Added file: http://bugs.python.org/file38643/0001-docs-update-description-of-TemporaryFile-and-tempfil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23725>
_______________________________________

From report at bugs.python.org  Mon Mar 23 06:10:35 2015
From: report at bugs.python.org (matham)
Date: Mon, 23 Mar 2015 05:10:35 +0000
Subject: [issue23743] Python crashes upon exit if importing g++ compiled mod
 after importing gcc compiled mod
Message-ID: <1427087434.95.0.234111642557.issue23743@psf.upfronthosting.co.za>


New submission from matham:

I have encountered a situation where python crashes when python exits if one imports a c compiled extension followed by a cpp compiled extension (but not if imported in the reverse order). This is on windows with mingw (current using mingw-get install gcc g++ msys-make) and py2.7.9.

This is basically the issue reported at https://mail.python.org/pipermail/python-win32/2013-April/012798.html a while back by someone else, but I'm filing it in bug form so it can't be ignored :D

Here's how to replicate it:

cplayground.c:

#include <Python.h>

static PyObject*
say_hello(PyObject* self, PyObject* args)
{
    Py_RETURN_NONE;
}

static PyMethodDef HelloMethods[] =
{
     {"say_hello", say_hello, METH_VARARGS, "Greet somebody."},
     {NULL, NULL, 0, NULL}
};

PyMODINIT_FUNC
initcplayground(void)
{
     (void) Py_InitModule("cplayground", HelloMethods);
}


cplayground.cpp:

#include <Python.h>

static PyObject*
say_hello(PyObject* self, PyObject* args)
{
    Py_RETURN_NONE;
}

static PyMethodDef HelloMethods[] =
{
     {"say_hello", say_hello, METH_VARARGS, "Greet somebody."},
     {NULL, NULL, 0, NULL}
};

PyMODINIT_FUNC
initcppplayground(void)
{
     (void) Py_InitModule("cppplayground", HelloMethods);
}


setup.py:

from distutils.core import setup
from distutils.extension import Extension
import Cython.Compiler.Options
from Cython.Distutils import build_ext
from os.path import join, sep, dirname, abspath

def get_extensions_from_sources():
    ext_modules = []
    ext_modules.append(Extension('src.cplayground', sources=['src/cplayground.c']))
    ext_modules.append(Extension('src.cppplayground', sources=['src/cplayground.cpp']))
    return ext_modules

setup(
    name='Playground',
    version='.1',
    author='Matthew Einhorn',
    ext_modules=get_extensions_from_sources(),
    cmdclass={'build_ext': build_ext},
    packages=['src']
      )


Here's a demonstration of the issue:

G:\Python\libs\Playground\src>python
Python 2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import cplayground
>>> import cppplayground
>>> exit()

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

G:\Python\libs\Playground\src>python
Python 2.7.9 (default, Dec 10 2014, 12:24:55) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import cppplayground
>>> import cplayground
>>> exit()

Here's my config:

G:\Python\libs\Playground\src>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=g:/python/env/test/py279_x86/mingw/bin/../libexec/gcc/mingw3
2/4.8.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=m
ingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto
--enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++
,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-l
ibstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gm
p-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --
with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-
libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/
mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
Thread model: win32
gcc version 4.8.1 (GCC)

G:\Python\libs\Playground\src>g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=g:/python/env/test/py279_x86/mingw/bin/../libexec/gcc/mingw3
2/4.8.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=m
ingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto
--enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++
,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-l
ibstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gm
p-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --
with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-
libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/
mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T
Thread model: win32
gcc version 4.8.1 (GCC)

----------
components: Extension Modules, Windows
messages: 238981
nosy: matham, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python crashes upon exit if importing g++ compiled mod after importing gcc compiled mod
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23743>
_______________________________________

From report at bugs.python.org  Mon Mar 23 06:26:01 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Mar 2015 05:26:01 +0000
Subject: [issue20271] urllib.parse.urlparse() accepts wrong URLs
In-Reply-To: <1389789129.93.0.775761654638.issue20271@psf.upfronthosting.co.za>
Message-ID: <1427088361.23.0.436209059714.issue20271@psf.upfronthosting.co.za>


Martin Panter added the comment:

To me, the only difference between urlsplit() and urlparse() is that urlsplit() does not treat parameters following a semicolon specially. The documentation tends to agree with this view. So whatever exceptions are raised by urlparse() should also be raised by urlsplit() for consistency.

Also, I doubt it is worth worrying about the finer details of splitport() or whatever, because they are meant to be deprecated and not used externally, except for backwards compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20271>
_______________________________________

From report at bugs.python.org  Mon Mar 23 07:05:12 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 23 Mar 2015 06:05:12 +0000
Subject: [issue23744] Speed-up deque.__bool__
Message-ID: <1427090712.12.0.119881784491.issue23744@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The __bool__ method is a little faster than __len__.
Timings attached.

----------
assignee: rhettinger
components: Library (Lib)
files: deque_bool1.diff
keywords: patch
messages: 238983
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Speed-up deque.__bool__
versions: Python 3.5
Added file: http://bugs.python.org/file38644/deque_bool1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23744>
_______________________________________

From report at bugs.python.org  Mon Mar 23 07:05:24 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 23 Mar 2015 06:05:24 +0000
Subject: [issue23744] Speed-up deque.__bool__
In-Reply-To: <1427090712.12.0.119881784491.issue23744@psf.upfronthosting.co.za>
Message-ID: <1427090724.67.0.152151410743.issue23744@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file38645/timings_deque_bool.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23744>
_______________________________________

From report at bugs.python.org  Mon Mar 23 07:15:46 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 23 Mar 2015 06:15:46 +0000
Subject: [issue23378] argparse.add_argument action parameter should allow
 value extend
In-Reply-To: <1422886990.52.0.318776752581.issue23378@psf.upfronthosting.co.za>
Message-ID: <1427091346.88.0.993874356094.issue23378@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage:  -> needs patch
versions:  -Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23378>
_______________________________________

From report at bugs.python.org  Mon Mar 23 08:28:58 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 07:28:58 +0000
Subject: [issue23742] expandvars removes single quotes ( ' )
In-Reply-To: <1427074537.6.0.869076773491.issue23742@psf.upfronthosting.co.za>
Message-ID: <1427095738.7.0.768842460417.issue23742@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch.

----------
assignee:  -> serhiy.storchaka
components: +Library (Lib)
keywords: +patch
stage: needs patch -> patch review
versions: +Python 2.7
Added file: http://bugs.python.org/file38646/issue23742.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23742>
_______________________________________

From report at bugs.python.org  Mon Mar 23 08:36:16 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 07:36:16 +0000
Subject: [issue23062] test_argparse --version test cases
In-Reply-To: <1418706736.64.0.85644160224.issue23062@psf.upfronthosting.co.za>
Message-ID: <1427096176.34.0.196055993411.issue23062@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I should agree with you. Then the patch LGTM.

----------
assignee:  -> berker.peksag
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23062>
_______________________________________

From report at bugs.python.org  Mon Mar 23 08:38:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 07:38:41 +0000
Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?=
 =?utf-8?q?=E2=80=9D_exception_message_on_Wine?=
In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za>
Message-ID: <1427096321.11.0.085888645947.issue22977@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22977>
_______________________________________

From report at bugs.python.org  Mon Mar 23 08:43:43 2015
From: report at bugs.python.org (Elmer)
Date: Mon, 23 Mar 2015 07:43:43 +0000
Subject: [issue23745] Exception when parsing an email using
 email.parser.BytesParser
Message-ID: <1427096623.21.0.20064628085.issue23745@psf.upfronthosting.co.za>


New submission from Elmer:

I am working with a large dataset of emails and loading one of them resulted in an exception: "TypeError: unorderable types: ValueTerminal() < CFWSList()"

I have attached the (anonymised and minimised) email source of the email that triggered the exception.

$ python
Python 3.4.2 (default, Nov 12 2014, 18:23:59) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.54)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import email
>>> from email import parser, policy
>>> 
>>> f = open("testmail.eml",'rb')
>>> src = f.read()
>>> f.close()
>>> 
>>> msg = email.parser.BytesParser(_class=email.message.EmailMessage, policy=email.policy.default).parsebytes(src)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/parser.py", line 124, in parsebytes
    return self.parser.parsestr(text, headersonly)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/parser.py", line 68, in parsestr
    return self.parse(StringIO(text), headersonly=headersonly)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/parser.py", line 57, in parse
    feedparser.feed(data)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/feedparser.py", line 178, in feed
    self._call_parse()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/feedparser.py", line 182, in _call_parse
    self._parse()
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/feedparser.py", line 384, in _parsegen
    for retval in self._parsegen():
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/feedparser.py", line 255, in _parsegen
    if self._cur.get_content_type() == 'message/delivery-status':
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/message.py", line 579, in get_content_type
    value = self.get('content-type', missing)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/message.py", line 472, in get
    return self.policy.header_fetch_parse(k, v)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/policy.py", line 145, in header_fetch_parse
    return self.header_factory(name, ''.join(value.splitlines()))
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/headerregistry.py", line 583, in __call__
    return self[name](name, value)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/headerregistry.py", line 194, in __new__
    cls.parse(value, kwds)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/headerregistry.py", line 441, in parse
    kwds['decoded'] = str(parse_tree)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/_header_value_parser.py", line 195, in __str__
    return ''.join(str(x) for x in self)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/_header_value_parser.py", line 195, in <genexpr>
    return ''.join(str(x) for x in self)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/_header_value_parser.py", line 1136, in __str__
    for name, value in self.params:
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/email/_header_value_parser.py", line 1101, in params
    parts = sorted(parts)
TypeError: unorderable types: ValueTerminal() < CFWSList()

----------
components: email
files: testmail.eml
messages: 238987
nosy: Elmer, barry, r.david.murray
priority: normal
severity: normal
status: open
title: Exception when parsing an email using email.parser.BytesParser
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file38647/testmail.eml

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23745>
_______________________________________

From report at bugs.python.org  Mon Mar 23 08:47:40 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 23 Mar 2015 07:47:40 +0000
Subject: [issue22516] Windows Installer won't - even when using "just for
 me"option
In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za>
Message-ID: <1427096860.75.0.0264156267521.issue22516@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I think we learned our lesson re making decisions at the language summit (rather than focusing on bringing folks up to speed on a problem area) after needing to later reverse engineer the rationale for some of the decisions made at the first couple :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22516>
_______________________________________

From report at bugs.python.org  Mon Mar 23 08:52:19 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 07:52:19 +0000
Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?=
 =?utf-8?q?=E2=80=9D_exception_message_on_Wine?=
In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za>
Message-ID: <1427097139.35.0.481210273854.issue22977@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are other occurrences of %X in the code. Do you want provide a patch for them Martin?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22977>
_______________________________________

From report at bugs.python.org  Mon Mar 23 09:34:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 08:34:54 +0000
Subject: [issue21526] Support new booleans in Tkinter
In-Reply-To: <1400445691.82.0.48051274053.issue21526@psf.upfronthosting.co.za>
Message-ID: <1427099694.67.0.288284990957.issue21526@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21526>
_______________________________________

From report at bugs.python.org  Mon Mar 23 09:35:07 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 08:35:07 +0000
Subject: [issue23252] Add support of writing to unseekable file in zipfile
In-Reply-To: <1421438148.04.0.307260333821.issue23252@psf.upfronthosting.co.za>
Message-ID: <1427099707.37.0.720642626498.issue23252@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23252>
_______________________________________

From report at bugs.python.org  Mon Mar 23 09:47:08 2015
From: report at bugs.python.org (Arnt Gulbrandsen)
Date: Mon, 23 Mar 2015 08:47:08 +0000
Subject: [issue23647] imaplib.py MAXLINE value is too low for gmail
In-Reply-To: <1426174765.08.0.908432771269.issue23647@psf.upfronthosting.co.za>
Message-ID: <1427100428.05.0.601876521758.issue23647@psf.upfronthosting.co.za>


Arnt Gulbrandsen added the comment:

You're entirely right. I should've reread 2683 too (a decade has passed since I read that).

The danger with accepting the unlimited line length is that batch scripts might accept an infinitely large batch. Which is a matter of python culture, really.

(This has been a very positive experience.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23647>
_______________________________________

From report at bugs.python.org  Mon Mar 23 09:58:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 08:58:00 +0000
Subject: [issue16314] Support xz compression in distutils
In-Reply-To: <1351114378.64.0.718374634123.issue16314@psf.upfronthosting.co.za>
Message-ID: <1427101079.99.0.650567390768.issue16314@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Addressed Berker's comments. Added versionchanged directives and a whatsnews entry.

----------
Added file: http://bugs.python.org/file38648/distutils-lzma_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16314>
_______________________________________

From report at bugs.python.org  Mon Mar 23 10:11:00 2015
From: report at bugs.python.org (Martin Teichmann)
Date: Mon, 23 Mar 2015 09:11:00 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1427101860.45.0.630838909271.issue23722@psf.upfronthosting.co.za>


Martin Teichmann added the comment:

A note on the implementation:

The compiler leaves a __cell__ entry in the class' namespace, which
is then filled by type.__new__, and removed from the namespace by
the latter. This is the same way it is done for __qualname__.

As the patch tampers with the compiler, when testing the patch
don't forget to remove old .pyc files, otherwise strange things will
happen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23722>
_______________________________________

From report at bugs.python.org  Mon Mar 23 10:13:02 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 23 Mar 2015 09:13:02 +0000
Subject: [issue23746] sysconfg.is_python_build() is buggy
Message-ID: <1427101982.73.0.589713060591.issue23746@psf.upfronthosting.co.za>


New submission from Anand B Pillai:

On Python 3.5.0a1+ built from source,

>>> import sysconfig
>>> sysconfig.is_python_build()
False
>>> sysconfig.is_python_build(True)
False
>>> sysconfig._PROJECT_BASE
'/opt/bin'
>>> import sys
>>> sys._home
>>>

The problem is, when sys._home is None, this function uses _is_python_source_dir(_PROJECT_BASE) . In this case the _PROJECT_BASE is clearly passed wrongly as '/opt/bin'. That is the INSTALL_PREFIX, not _PROJECT_BASE .

Let us do a small hack and set _PROJECT_BASE to the folder where I build this Python version.

# Of course this can't be reproduced but you get the idea.

>>> sysconfig._PROJECT_BASE='/home/anand/code/cpython/'
>>> sysconfig.is_python_build()
True

The documentation says,

"

sysconfig.is_python_build()

    Return True if the current Python installation was built from source.

"

which is clearly in conflict with what it is doing. 

>From a quick look at sysconfig.py it looks like it is calculating _PROJECT_BASE wrongly. 

I can give a patch for this, but first I am more interested in finding out what this function is supposed to do - why have this function if you are not able to get the details of the build environment from the built interpreter ? Clearly it is not doing that here.



The conclusions are part of the attached file in comments.

----------
components: Library (Lib)
messages: 238993
nosy: pythonhacker
priority: normal
severity: normal
status: open
title: sysconfg.is_python_build() is buggy
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23746>
_______________________________________

From report at bugs.python.org  Mon Mar 23 10:16:15 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 23 Mar 2015 09:16:15 +0000
Subject: [issue23746] sysconfg.is_python_build() is buggy
In-Reply-To: <1427101982.73.0.589713060591.issue23746@psf.upfronthosting.co.za>
Message-ID: <1427102175.59.0.765117114958.issue23746@psf.upfronthosting.co.za>


Changes by Anand B Pillai <abpillai at gmail.com>:


Added file: http://bugs.python.org/file38649/sysconfig_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23746>
_______________________________________

From report at bugs.python.org  Mon Mar 23 10:24:04 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 09:24:04 +0000
Subject: [issue23746] sysconfg.is_python_build() is buggy
In-Reply-To: <1427101982.73.0.589713060591.issue23746@psf.upfronthosting.co.za>
Message-ID: <1427102644.17.0.225801486105.issue23746@psf.upfronthosting.co.za>


STINNER Victor added the comment:

IMO it's more a documentation issue than a bug.

sysconfig.is_python_build() returns True when Python is run from its source code directory. For example, I compiled Python in ~/prog/python/default.

~/prog/python/default/python returns True.

I installed python to /opt/py35/bin/python: it returns False.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23746>
_______________________________________

From report at bugs.python.org  Mon Mar 23 10:30:16 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 23 Mar 2015 09:30:16 +0000
Subject: [issue23747] platform module exposes win32_ver function on posix
 systems
Message-ID: <1427103016.81.0.503768282249.issue23747@psf.upfronthosting.co.za>


New submission from Anand B Pillai:

>>> import platform
>>> platform.system()
'Linux'
>>> platform.win32_ver()
('', '', '', '')

Why is this function even exposed on Linux ? It should be conditionally exposed only on win32 platforms. 

Funny that this is coming from the module named "platform" itself :)

----------
components: Library (Lib)
messages: 238995
nosy: pythonhacker
priority: normal
severity: normal
status: open
title: platform module exposes win32_ver function on posix systems

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23747>
_______________________________________

From report at bugs.python.org  Mon Mar 23 10:33:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 09:33:45 +0000
Subject: [issue23747] platform module exposes win32_ver function on posix
 systems
In-Reply-To: <1427103016.81.0.503768282249.issue23747@psf.upfronthosting.co.za>
Message-ID: <1427103225.25.0.99046412753.issue23747@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Why is this function even exposed on Linux?

It is a deliberate design choice of the platform module. mac_ver(), win32_ver() and linux_distribution() are available on all platforms.

mac_ver() says "entries which cannot be determined are set to ''. All tuple entries are strings."

Maybe it should be better explained in the doc.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, haypo
versions: +Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23747>
_______________________________________

From report at bugs.python.org  Mon Mar 23 10:36:00 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 23 Mar 2015 09:36:00 +0000
Subject: [issue23747] platform module exposes win32_ver function on posix
 systems
In-Reply-To: <1427103016.81.0.503768282249.issue23747@psf.upfronthosting.co.za>
Message-ID: <1427103360.89.0.175964494725.issue23747@psf.upfronthosting.co.za>


Anand B Pillai added the comment:

Similarly for mac_ver, java_ver etc.

>>> platform.mac_ver()
('', ('', '', ''), '')
>>> platform.java_ver()
('', '', ('', '', ''), ('', '', ''))

Maybe it is okay if these functions are present, but can't they raise an exception or return None instead of returning these funny tuples when empty strings ?

I am surprised at Python's inconsistency in such things. For example,

>>> import winsound
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'winsound'

Works as expected on Linux. In the same vein, these functions shouldn't be present as well IMHO - I agree this is debatable of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23747>
_______________________________________

From report at bugs.python.org  Mon Mar 23 10:39:23 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 23 Mar 2015 09:39:23 +0000
Subject: [issue23746] sysconfg.is_python_build() is buggy
In-Reply-To: <1427101982.73.0.589713060591.issue23746@psf.upfronthosting.co.za>
Message-ID: <1427103563.35.0.0670894784908.issue23746@psf.upfronthosting.co.za>


Anand B Pillai added the comment:

Thanks. From current documentation it isn't clear. Agree to make this a doc bug then. 

It should also be made clear this would work only for the executable built in the source directory. As in,

(Running from the source folder using source Python executable).

anand at toshiba-laptop:~/code/cpython$ ./python 
Python 3.5.0a1+ (default:656543a2ad75, Mar  3 2015, 22:56:27) 
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> sysconfig.is_python_build()
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23746>
_______________________________________

From report at bugs.python.org  Mon Mar 23 10:40:55 2015
From: report at bugs.python.org (Michael Foord)
Date: Mon, 23 Mar 2015 09:40:55 +0000
Subject: [issue15836] unittest assertRaises should verify excClass is actually
 a BaseException class
In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za>
Message-ID: <1427103655.38.0.125420239021.issue15836@psf.upfronthosting.co.za>


Michael Foord added the comment:

I like the first variant suggested by Ezio as more concise. I'll try and look at the substance of the patch today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15836>
_______________________________________

From report at bugs.python.org  Mon Mar 23 10:50:07 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 23 Mar 2015 09:50:07 +0000
Subject: [issue23746] sysconfg.is_python_build() is buggy
In-Reply-To: <1427101982.73.0.589713060591.issue23746@psf.upfronthosting.co.za>
Message-ID: <1427104207.79.0.116122625553.issue23746@psf.upfronthosting.co.za>


Anand B Pillai added the comment:

On second thoughts, why have such a function if it works correctly only when executed from source Cpython folder using source CPython executable  and not otherwise ?

Cuz if I am calling it like that I already KNOW that I am in such an environment.

Possibly this is an internal function to be used by developers to find out if they are in such an environment.

IMHO Then -> make it private (not callable outside) or drop it altogether.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23746>
_______________________________________

From report at bugs.python.org  Mon Mar 23 10:50:54 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 09:50:54 +0000
Subject: [issue23747] platform module exposes win32_ver function on posix
 systems
In-Reply-To: <1427103360.89.0.175964494725.issue23747@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ6PMwDMvRuGaNEPEdeT6xuYK+sPbD-AYZ72NNebc9WSA@mail.gmail.com>


STINNER Victor added the comment:

> Maybe it is okay if these functions are present, but can't they raise an exception or return None instead of returning these funny tuples when empty strings ?

It would break the backward compatibility. Again, it's a delibarate choice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23747>
_______________________________________

From report at bugs.python.org  Mon Mar 23 10:53:27 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 09:53:27 +0000
Subject: [issue23746] sysconfg.is_python_build() is buggy
In-Reply-To: <1427104207.79.0.116122625553.issue23746@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZre2TFwx9rc0ObOa88kH_69FRoHOak5UknGqb7Y=qhLQ@mail.gmail.com>


STINNER Victor added the comment:

> On second thoughts, why have such a function if it works correctly only when executed from source Cpython folder using source CPython executable  and not otherwise ?

It's useful to know such information. Python behaves a little bit
differently when run from the source code (not installed).

Example of usage of this function:

Lib/test/test_asdl_parser.py:12:if not sysconfig.is_python_build():
Lib/test/test_gdb.py:38:if not sysconfig.is_python_build():
Lib/test/test_pyexpat.py:448:            if sysconfig.is_python_build():
Lib/test/test_subprocess.py:415:
@unittest.skipIf(sysconfig.is_python_build(),

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23746>
_______________________________________

From report at bugs.python.org  Mon Mar 23 11:16:23 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 23 Mar 2015 10:16:23 +0000
Subject: [issue23746] sysconfg.is_python_build() is buggy
In-Reply-To: <1427101982.73.0.589713060591.issue23746@psf.upfronthosting.co.za>
Message-ID: <1427105783.85.0.412732183014.issue23746@psf.upfronthosting.co.za>


Anand B Pillai added the comment:

> Lib/test/test_asdl_parser.py:12:if not sysconfig.is_python_build():

As I guessed - it is used internally by unit tests and possibly has no other significan audience.

It is best to document this clearly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23746>
_______________________________________

From report at bugs.python.org  Mon Mar 23 11:28:12 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Mon, 23 Mar 2015 10:28:12 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1427106492.41.0.0945954727847.issue23688@psf.upfronthosting.co.za>


Changes by Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de>:


Added file: http://bugs.python.org/file38650/write_bytes_like_objects_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Mon Mar 23 11:28:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 10:28:28 +0000
Subject: [issue21859] Add Python implementation of FileIO
In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za>
Message-ID: <1427106508.73.0.219323046814.issue21859@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated to the tip (added the closefd attribute in repr). os.fstat() is now called only once in the constructor.

----------
Added file: http://bugs.python.org/file38651/pyio_fileio_7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21859>
_______________________________________

From report at bugs.python.org  Mon Mar 23 11:37:50 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 23 Mar 2015 10:37:50 +0000
Subject: [issue23748] platform._uname_cache is writeable
Message-ID: <1427107070.63.0.510567117775.issue23748@psf.upfronthosting.co.za>


New submission from Anand B Pillai:

>> import platform
>>> print 'Actual =>',platform.uname()
Actual => ('Linux', 'toshiba-laptop', '3.13.0-24-generic', '#47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014', 'x86_64', 'x86_64')
>>> import hack_uname
# Someone imports my module unaware of the hack (see attached file)
>>> platform.uname()
('Limux', 'hacker-laptop', '11.15.0-28000-absurd', '#10000 - FunkyDistro SMMP Fry Feb 30 2015 23:59:00 UTC 2015', 'x866_64', 'x866_64')

Fix - Make the global _uname_cache inaccessible via the module and hence unwriteable. I can provide a patch - it is kind of easy fix.

I think this might also be a security issue since if someone is writing a significant piece of code based on the platform it can screw up the system - or his web application if a piece of code like this is introduced in a module via his chain of imports by a malicious hacker.

----------
components: Library (Lib)
files: hack_uname.py
messages: 239005
nosy: pythonhacker
priority: normal
severity: normal
status: open
title: platform._uname_cache is writeable
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38652/hack_uname.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23748>
_______________________________________

From report at bugs.python.org  Mon Mar 23 11:39:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 10:39:53 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1427107193.45.0.933793150093.issue23688@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In general the patch LGTM.

----------
assignee:  -> serhiy.storchaka
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Mon Mar 23 11:40:32 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 23 Mar 2015 10:40:32 +0000
Subject: [issue23748] platform._uname_cache is writeable
In-Reply-To: <1427107070.63.0.510567117775.issue23748@psf.upfronthosting.co.za>
Message-ID: <1427107232.89.0.473432639499.issue23748@psf.upfronthosting.co.za>


Anand B Pillai added the comment:

I am changing the type to security as I dont think this is a behaviour issue.

----------
type: behavior -> security

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23748>
_______________________________________

From report at bugs.python.org  Mon Mar 23 11:43:46 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 10:43:46 +0000
Subject: [issue23748] platform._uname_cache is writeable
In-Reply-To: <1427107070.63.0.510567117775.issue23748@psf.upfronthosting.co.za>
Message-ID: <1427107426.02.0.315685054827.issue23748@psf.upfronthosting.co.za>


STINNER Victor added the comment:

we are all consenting adults here. Why do you modify a private attribute?

> I am changing the type to security as I dont think this is a behaviour issue.

I don't understand why do you consider that it is a security vulnerability?

>>> import hack_uname
# Someone imports my module unaware of the hack (see attached file)

Your exploit starts by running untrusted Python code. Never do that. The vulnerability is the ability to load unstrusted Python code, not to modify the platform module.

I close the issue as not a bug.

----------
nosy: +haypo
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23748>
_______________________________________

From report at bugs.python.org  Mon Mar 23 12:02:39 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 23 Mar 2015 11:02:39 +0000
Subject: [issue23748] platform._uname_cache is writeable
In-Reply-To: <1427107070.63.0.510567117775.issue23748@psf.upfronthosting.co.za>
Message-ID: <1427108559.55.0.470348031424.issue23748@psf.upfronthosting.co.za>


Anand B Pillai added the comment:

Hmmm... dear sir -  what prevents you from adding an __all__ to the module with these cache variables excluded ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23748>
_______________________________________

From report at bugs.python.org  Mon Mar 23 12:04:03 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 23 Mar 2015 11:04:03 +0000
Subject: [issue23748] platform._uname_cache is writeable
In-Reply-To: <1427107070.63.0.510567117775.issue23748@psf.upfronthosting.co.za>
Message-ID: <1427108643.62.0.190537599197.issue23748@psf.upfronthosting.co.za>


Anand B Pillai added the comment:

Closing is an easy fix, bet on my word this would appear as a different bug, thanks for your quickie fix!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23748>
_______________________________________

From report at bugs.python.org  Mon Mar 23 13:18:47 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 12:18:47 +0000
Subject: [issue23748] platform._uname_cache is writeable
In-Reply-To: <1427107070.63.0.510567117775.issue23748@psf.upfronthosting.co.za>
Message-ID: <1427113127.84.0.694499189426.issue23748@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Hmmm... dear sir -  what prevents you from adding an __all__ to the module with these cache variables excluded ?

You didn't understand the general philosophy, we are not hidding internals. For the specific case of platform._uname_cache, it uses the "_" prefix which is an indicator saying that "you are not supposed to modify it except if you really understand what do you". It's useful to have this variable modifiable, for unit tests for example.

I don't see how adding __all__ variable to the platform would change anything. Variables prefixed by "_" are already excluded when using "from platform import *".

If you don't understand the Python philosophy, please open a thread on python-ideas or even python-dev mailing list, to get a longer explanation.

Read also the PEP 20.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23748>
_______________________________________

From report at bugs.python.org  Mon Mar 23 13:34:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 12:34:41 +0000
Subject: [issue21859] Add Python implementation of FileIO
In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za>
Message-ID: <1427114081.82.0.216362450836.issue21859@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Restored first os.fstat() (however it now is redundant) and addressed most other Victor's comments.

In general I prefer EAFP over BDFL, and often "except AttributeError" looks better to me than getattr().

----------
Added file: http://bugs.python.org/file38653/pyio_fileio_8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21859>
_______________________________________

From report at bugs.python.org  Mon Mar 23 13:37:33 2015
From: report at bugs.python.org (Anand Reddy Pandikunta)
Date: Mon, 23 Mar 2015 12:37:33 +0000
Subject: [issue23310] Mock constructor configuration fails for magic methods
In-Reply-To: <1422120039.57.0.541541438715.issue23310@psf.upfronthosting.co.za>
Message-ID: <1427114253.14.0.775046534504.issue23310@psf.upfronthosting.co.za>


Anand Reddy Pandikunta added the comment:

mock itself fails

----------
nosy: +Anand Reddy Pandikunta
title: MagicMock constructor configuration fails for magic methods -> Mock constructor configuration fails for magic methods
Added file: http://bugs.python.org/file38654/test_mock.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23310>
_______________________________________

From report at bugs.python.org  Mon Mar 23 13:40:51 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 23 Mar 2015 12:40:51 +0000
Subject: [issue19610] setup.py does not allow a tuple for classifiers
In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za>
Message-ID: <1427114451.92.0.624792702123.issue19610@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Here is a new patch. I didn't touched provides, requires and obsoletes fields since they are not used much in the setuptools era.

Distribution.finalize_options() already converts string types to lists for platforms and keywords fields. I didn't changed that behavior.

----------
Added file: http://bugs.python.org/file38655/issue19610_v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19610>
_______________________________________

From report at bugs.python.org  Mon Mar 23 14:28:05 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Mar 2015 13:28:05 +0000
Subject: [issue21560] gzip.write changes trailer ISIZE field before type
 checking - corrupted gz file after trying to write string
In-Reply-To: <1400844177.32.0.625819528356.issue21560@psf.upfronthosting.co.za>
Message-ID: <20150323132802.4221.74054@psf.io>


Roundup Robot added the comment:

New changeset 4dfe0634d11a by Serhiy Storchaka in branch '2.7':
Issue #21560: An attempt to write a data of wrong type no longer cause
https://hg.python.org/cpython/rev/4dfe0634d11a

New changeset 6eb48b22ff5c by Serhiy Storchaka in branch '3.4':
Issue #21560: An attempt to write a data of wrong type no longer cause
https://hg.python.org/cpython/rev/6eb48b22ff5c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21560>
_______________________________________

From report at bugs.python.org  Mon Mar 23 14:28:05 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Mar 2015 13:28:05 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <20150323132802.4221.26061@psf.io>


Roundup Robot added the comment:

New changeset 4dc69e5124f8 by Serhiy Storchaka in branch 'default':
Issue #23688: Added support of arbitrary bytes-like objects and avoided
https://hg.python.org/cpython/rev/4dc69e5124f8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Mon Mar 23 14:31:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 13:31:53 +0000
Subject: [issue21560] gzip.write changes trailer ISIZE field before type
 checking - corrupted gz file after trying to write string
In-Reply-To: <1400844177.32.0.625819528356.issue21560@psf.upfronthosting.co.za>
Message-ID: <1427117513.29.0.768962777187.issue21560@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Tests are taken from issue23688. Thanks for your contribution Wolfgang.

----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21560>
_______________________________________

From report at bugs.python.org  Mon Mar 23 14:32:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 13:32:26 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1427117546.04.0.65590224599.issue23688@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Mon Mar 23 14:41:40 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 13:41:40 +0000
Subject: [issue23676] Add support of UnicodeTranslateError in standard error
 handlers
In-Reply-To: <1426456748.16.0.28109004659.issue23676@psf.upfronthosting.co.za>
Message-ID: <1427118100.01.0.82702904098.issue23676@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

No, currently UnicodeTranslateError is not used in the stdlib in 3.x. But it is documented and supported by some error handlers. I think it should be wider used in text-to-text translations similar to proposed in issue18814.

----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23676>
_______________________________________

From report at bugs.python.org  Mon Mar 23 14:52:21 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 23 Mar 2015 13:52:21 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1427118741.68.0.532522503412.issue23688@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I think there's a behavior change: Before you could gzip non-contiguous
views directly, now that operation raises BufferError.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Mon Mar 23 14:57:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 13:57:00 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1427119020.08.0.684122757621.issue23688@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you provide an example?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Mon Mar 23 14:59:59 2015
From: report at bugs.python.org (Giovanni Cannata)
Date: Mon, 23 Mar 2015 13:59:59 +0000
Subject: [issue23749] asyncio missing wrap_socket
Message-ID: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>


New submission from Giovanni Cannata:

It's not possible to wrap a socket in tls. The StreamWriter object should have an option to start a tls negotiation using the SSLContext of the server.

This is needed for protocols the have a "start_tls" feature, for example the ldap protocol.

In a non async program it's very easy: 
   wrapped_socket = ssl_context.wrap_socket(connection.socket, server_side=True, do_handshake_on_connect=True)

there should be something similar in the StreamWriter interface:
   yield from writer.wrap_socket()

Bye,
Giovanni

----------
components: asyncio
messages: 239021
nosy: gc, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio missing wrap_socket
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23749>
_______________________________________

From report at bugs.python.org  Mon Mar 23 15:01:07 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 14:01:07 +0000
Subject: [issue23749] asyncio missing wrap_socket
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1427119267.01.0.502977005488.issue23749@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Yes, it's not supported yet. It was already requested in this issue:
https://code.google.com/p/tulip/issues/detail?id=79

asyncio got a new SSL implementation which makes possible to implement STARTTLS. Are you interested to implement it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23749>
_______________________________________

From report at bugs.python.org  Mon Mar 23 15:02:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 14:02:59 +0000
Subject: [issue23740] http.client request and send method have some datatype
 issues
In-Reply-To: <1427052524.74.0.134908492197.issue23740@psf.upfronthosting.co.za>
Message-ID: <1427119379.07.0.823784791408.issue23740@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Note that for file-like objects we have also the same issue as issue22468. Content-Length is not determined correctly for GzipFile and like.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23740>
_______________________________________

From report at bugs.python.org  Mon Mar 23 15:08:05 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 23 Mar 2015 14:08:05 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1427119685.87.0.476962515944.issue23688@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Sure:

import gzip
x = memoryview(b'x' * 10)
y = x[::-1]
with gzip.GzipFile("xxxxx", 'w') as f:
    f.write(y)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Mon Mar 23 15:08:37 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 23 Mar 2015 14:08:37 +0000
Subject: [issue23738] Clarify documentation of positional-only default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1427119717.77.0.540042045684.issue23738@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I say switch to what Argument Clinic uses, else there's a disconnect syntactically between help() and the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23738>
_______________________________________

From report at bugs.python.org  Mon Mar 23 15:09:20 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 23 Mar 2015 14:09:20 +0000
Subject: [issue21062] Evalute all import-related modules for best practices
In-Reply-To: <1395763138.25.0.943943141564.issue21062@psf.upfronthosting.co.za>
Message-ID: <1427119760.11.0.603786644502.issue21062@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21062>
_______________________________________

From report at bugs.python.org  Mon Mar 23 15:20:26 2015
From: report at bugs.python.org (Giovanni Cannata)
Date: Mon, 23 Mar 2015 14:20:26 +0000
Subject: [issue23749] asyncio missing wrap_socket
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1427120426.5.0.383025479565.issue23749@psf.upfronthosting.co.za>


Giovanni Cannata added the comment:

Thanks, I will look to the new implementation of ssl in 3.5, and try to adapt it for my project (sldap3). I'd like to help, but I'm not skilled in asynchronous programming so I'm not sure if I succeed.

Bye,
Giovanni

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23749>
_______________________________________

From report at bugs.python.org  Mon Mar 23 15:22:33 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Mon, 23 Mar 2015 14:22:33 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1427120553.2.0.0480661049392.issue23688@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

ouch. haven't thought of this.

OTOH, just plain io with your example:

with open('xy', 'wb') as f:
    f.write(y)

Traceback (most recent call last):
  File "<pyshell#29>", line 2, in <module>
    f.write(y)
BufferError: memoryview: underlying buffer is not C-contiguous

fails too and after all that's not too surprising.

In a sense, the old behavior was an artefact of silently copying the memoryview to bytes. You never used it *directly*.
But, yes, it is a change in (undocumented) behavior :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Mon Mar 23 15:28:11 2015
From: report at bugs.python.org (Andreas Sommer)
Date: Mon, 23 Mar 2015 14:28:11 +0000
Subject: [issue23750] Clarify difference between os.system/subprocess.call in
 section "Replacing os.system()"
Message-ID: <1427120891.65.0.0570880238086.issue23750@psf.upfronthosting.co.za>


New submission from Andreas Sommer:

Reading over the section "Replacing os.system()" (https://docs.python.org/2/library/subprocess.html#replacing-os-system), one might assume that the return value of os.system and subprocess.call are equivalent.

    status = os.system("mycmd" + " myarg")
    # becomes
    status = subprocess.call("mycmd" + " myarg", shell=True)

However, they are not. Example:

    import sys
    import os
    import subprocess

    print subprocess.call("false")
    print os.system("false")

gives 1 and 256, respectively. Maybe this could be rephrased for clarity, or a hint added.

----------
assignee: docs at python
components: Documentation
messages: 239028
nosy: Andreas Sommer, docs at python
priority: normal
severity: normal
status: open
title: Clarify difference between os.system/subprocess.call in section "Replacing os.system()"
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23750>
_______________________________________

From report at bugs.python.org  Mon Mar 23 15:29:38 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Mon, 23 Mar 2015 14:29:38 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1427120978.89.0.858364501158.issue23688@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

to preserve compatibility:

there is the memoryview.c_contiguous flag. Maybe we should just check it and if it is False fall back to the old copying behavior ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Mon Mar 23 15:35:30 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Mon, 23 Mar 2015 14:35:30 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1427121330.6.0.24452903784.issue23688@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

something like:


    def write(self,data):
        self._check_closed()
        if self.mode != WRITE:
            import errno
            raise OSError(errno.EBADF, "write() on read-only GzipFile object")

        if self.fileobj is None:
            raise ValueError("write() on closed GzipFile object")

        if isinstance(data, bytes):
            length = len(data)
        elif isinstance(data, memoryview) and not data.c_contiguous:
            data = data.tobytes()
            length = len(data)
        else:
            # accept any data that supports the buffer protocol
            data = memoryview(data)
            length = data.nbytes

        if length > 0:
            self.fileobj.write(self.compress.compress(data))
            self.size += length
            self.crc = zlib.crc32(data, self.crc) & 0xffffffff
            self.offset += length

        return length

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Mon Mar 23 15:37:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 14:37:02 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1427119685.87.0.476962515944.issue23688@psf.upfronthosting.co.za>
Message-ID: <59466636.NKnby2TS9I@raxxla>


Serhiy Storchaka added the comment:

Here is a patch that restores support on non-contiguous memoryviews.

It would be better to drop support of non-contiguous data, because it worked 
only by accident. Needed support of only bytes-like memoryviews written by 
BufferedWriter.

----------
Added file: http://bugs.python.org/file38656/gzip_write_noncontiguous.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________
-------------- next part --------------
diff -r 7e179ee91af0 Lib/gzip.py
--- a/Lib/gzip.py	Mon Mar 23 15:26:49 2015 +0200
+++ b/Lib/gzip.py	Mon Mar 23 16:27:08 2015 +0200
@@ -340,6 +340,8 @@ class GzipFile(io.BufferedIOBase):
             # accept any data that supports the buffer protocol
             data = memoryview(data)
             length = data.nbytes
+            if not data.contiguous:
+                data = bytes(data)
 
         if length > 0:
             self.fileobj.write(self.compress.compress(data))
diff -r 7e179ee91af0 Lib/test/test_gzip.py
--- a/Lib/test/test_gzip.py	Mon Mar 23 15:26:49 2015 +0200
+++ b/Lib/test/test_gzip.py	Mon Mar 23 16:27:08 2015 +0200
@@ -74,6 +74,7 @@ class TestGzip(BaseTest):
         m = memoryview(bytes(range(256)))
         data = m.cast('B', shape=[8,8,4])
         self.write_and_read_back(data)
+        self.write_and_read_back(memoryview(data1 * 50)[::-1])
 
     def test_write_bytearray(self):
         self.write_and_read_back(bytearray(data1 * 50))

From report at bugs.python.org  Mon Mar 23 15:38:53 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 23 Mar 2015 14:38:53 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1427121533.28.0.37115567563.issue23688@psf.upfronthosting.co.za>


Stefan Krah added the comment:

> In a sense, the old behavior was an artefact of silently copying the memoryview to bytes.

It likely wasn't intentional, but tobytes() *is* used to serialize
weird arrays to their C-contiguous representation (following the
logical structure of the array rather than the physical one).

Since the gzip docs don't help much, I guess the new behavior is
probably okay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Mon Mar 23 15:53:53 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 23 Mar 2015 14:53:53 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1427122433.14.0.60928837284.issue23688@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I just see that non-contiguous arrays didn't work in 2.7 either,
so that was probably the original intention.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Mon Mar 23 15:54:06 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Mon, 23 Mar 2015 14:54:06 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1427122446.62.0.650490575513.issue23688@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

Serhiy:

I think I saw that you committed this also to the 2.7 branch, but that would not work since memoryviews do not have the nbytes attribute (they do not seem to have cast either). One would have to calculate the length instead from other properties.
Tests would fail too I think.

If I'm mistaken, then sorry for the noise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Mon Mar 23 15:57:37 2015
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 23 Mar 2015 14:57:37 +0000
Subject: [issue21859] Add Python implementation of FileIO
In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za>
Message-ID: <1427122657.87.0.931579487916.issue21859@psf.upfronthosting.co.za>


Changes by Hynek Schlawack <hs at ox.cx>:


----------
nosy:  -hynek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21859>
_______________________________________

From report at bugs.python.org  Mon Mar 23 15:58:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 14:58:02 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1427121533.28.0.37115567563.issue23688@psf.upfronthosting.co.za>
Message-ID: <31027650.ejCIttxRCt@raxxla>


Serhiy Storchaka added the comment:

OK, so left it as is if nobody complains.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Mon Mar 23 15:59:15 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Mon, 23 Mar 2015 14:59:15 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1426602364.36.0.58983911161.issue23688@psf.upfronthosting.co.za>
Message-ID: <1427122755.52.0.790431004898.issue23688@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

I see now that it is just issue21560 that went into 2.7 and that's fine.
As I said: sorry for the noise

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Mon Mar 23 15:59:32 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 14:59:32 +0000
Subject: [issue23688] unnecessary copying of memoryview in gzip.GzipFile.write?
In-Reply-To: <1427122446.62.0.650490575513.issue23688@psf.upfronthosting.co.za>
Message-ID: <2413924.Dn46UVIo7z@raxxla>


Serhiy Storchaka added the comment:

> I think I saw that you committed this also to the 2.7 branch,

I committed only working tests and a fix from issue21560.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23688>
_______________________________________

From report at bugs.python.org  Mon Mar 23 16:00:17 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 23 Mar 2015 15:00:17 +0000
Subject: [issue22560] New SSL implementation based on ssl.MemoryBIO
In-Reply-To: <1412548102.84.0.685230620276.issue22560@psf.upfronthosting.co.za>
Message-ID: <1427122817.92.0.891707205476.issue22560@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: patch review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22560>
_______________________________________

From report at bugs.python.org  Mon Mar 23 16:04:15 2015
From: report at bugs.python.org (Mohith)
Date: Mon, 23 Mar 2015 15:04:15 +0000
Subject: [issue23751] Allow reverse lookup (value-to-member) for Enum
 sublcasses decorated with @enum.unique
Message-ID: <1427123055.25.0.902352877052.issue23751@psf.upfronthosting.co.za>


New submission from Mohith:

Addendum to issue 18042.

I've had a use case where I wanted to allow reverse lookups (i.e. value-to-member lookup) for my enum.Enum that was decorated via @enum.unique. In such a case, I would add my own class method that performs the logic. E.g. an unoptimized copy-and-paste-able example for use via python3 interactive shell:


import datetime
import enum

@enum.unique
class DayOfWeek(enum.Enum):
  SUNDAY = 0  # Sunday is '0' according to strftime('%w')
  MONDAY = 1
  TUESDAY = 2
  WEDNESDAY = 3
  THURSDAY = 4
  FRIDAY = 5
  SATURDAY = 6  # Saturday is '6' according to strftime('%w')
  @classmethod
  def reverse_lookup(cls, value):
    for _, member in cls.__members__.items():
      if member.value == value:
        return member
    raise LookupError

today_value = int(datetime.date.today().strftime('%w'))
today = DayOfWeek.reverse_lookup(today_value)
print('Today is', today.name.title())


---

(Aside: it seems like an optimized version that uses a cached lookup dictionary is inconvenient to implement in that it involves storing the cache in a global variable or a closure or a descriptor attribute or etc. [unless there's a simple recommended approach of which I am just unaware].)

I think use cases for reverse lookup would not be uncommon. For example, an IntEnum subclass decorated via @enum.unique is a great candidate (as is any simple hashable/equatable value type). I am unsure of the proper interface, but I am thinking that passing a boolean argument to enum.unique should enable the usage of a special __lookup__ metaclass property for optimized reverse lookups. I am thinking a possible (untested) enhancement to enum.unique along the lines of:


class EnumMeta(type):

  ...

  _reverse_lookup_ = None

  @property
  def __lookup__(cls):
    if cls._reverse_lookup_ is None:
      raise AttributeError('Reverse lookup unsupported.')
    return MappingProxyType(cls._reverse_lookup_)


def unique(enumeration, reverse_lookup=False):
    ...
    reverse_lookup = {} if reverse_lookup else None
    for name, member in enumeration.__members__.items():
      ...
      if reverse_lookup is not None:
        reverse_lookup[member.value] = member
    ...
    if reverse_lookup is not None:
      enumeration._reverse_lookup_ = reverse_lookup
    return enumeration

----------
components: Library (Lib)
messages: 239038
nosy: barry, eli.bendersky, ethan.furman, mmuddasani
priority: normal
severity: normal
status: open
title: Allow reverse lookup (value-to-member) for Enum sublcasses decorated with @enum.unique
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23751>
_______________________________________

From report at bugs.python.org  Mon Mar 23 16:08:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 15:08:54 +0000
Subject: [issue23751] Allow reverse lookup (value-to-member) for Enum
 sublcasses decorated with @enum.unique
In-Reply-To: <1427123055.25.0.902352877052.issue23751@psf.upfronthosting.co.za>
Message-ID: <1427123334.52.0.556720402471.issue23751@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Use DayOfWeek(today_value).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23751>
_______________________________________

From report at bugs.python.org  Mon Mar 23 16:24:14 2015
From: report at bugs.python.org (Mohith)
Date: Mon, 23 Mar 2015 15:24:14 +0000
Subject: [issue23751] Allow reverse lookup (value-to-member) for Enum
 sublcasses decorated with @enum.unique
In-Reply-To: <1427123055.25.0.902352877052.issue23751@psf.upfronthosting.co.za>
Message-ID: <1427124254.2.0.171891033634.issue23751@psf.upfronthosting.co.za>


Mohith added the comment:

Doh! That works. And it was in the documentation too. Silly me.

Apologies for opening an issue, and thanks for showing me the way!

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23751>
_______________________________________

From report at bugs.python.org  Mon Mar 23 16:25:20 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 23 Mar 2015 15:25:20 +0000
Subject: [issue23751] Allow reverse lookup (value-to-member) for Enum
 sublcasses decorated with @enum.unique
In-Reply-To: <1427123055.25.0.902352877052.issue23751@psf.upfronthosting.co.za>
Message-ID: <1427124320.09.0.147484793995.issue23751@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23751>
_______________________________________

From report at bugs.python.org  Mon Mar 23 16:27:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 15:27:01 +0000
Subject: [issue14260] re.groupindex is available for modification and
 continues to work, having incorrect data inside it
In-Reply-To: <1331530103.22.0.0779581075646.issue14260@psf.upfronthosting.co.za>
Message-ID: <1427124421.23.0.986478047283.issue14260@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What approach looks better, a copy or a read-only proxy?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14260>
_______________________________________

From report at bugs.python.org  Mon Mar 23 16:32:53 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 23 Mar 2015 15:32:53 +0000
Subject: [issue23699] Add a macro to ease writing rich comparisons
In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za>
Message-ID: <1427124773.8.0.0722079574403.issue23699@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

Changed the macro to Py_RETURN_RICHCOMPARE. This is not an expression, allowing the use of a switch statement. On the other hand, it's even larger macro than before now.

>From the discussion it seems that doing this correctly is tricky to do this correctly - another point for standardizing this.

I put everything in a single macro to ease review in Rietveld.

----------
Added file: http://bugs.python.org/file38657/Use-a-macro-to-reduce-boilerplate-in-rich-comparison.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23699>
_______________________________________

From report at bugs.python.org  Mon Mar 23 17:40:12 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 23 Mar 2015 16:40:12 +0000
Subject: [issue16328] win_add2path.py sets wrong user path
In-Reply-To: <1351255282.63.0.930970476961.issue16328@psf.upfronthosting.co.za>
Message-ID: <1427128812.71.0.722704585596.issue16328@psf.upfronthosting.co.za>


Steve Dower added the comment:

It looks like the script hasn't been updated for the moved user scripts directory (under %APPDATA%), but otherwise this is not a bug and can be closed.

----------
nosy: +paul.moore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16328>
_______________________________________

From report at bugs.python.org  Mon Mar 23 17:46:14 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 23 Mar 2015 16:46:14 +0000
Subject: [issue16328] win_add2path.py sets wrong user path
In-Reply-To: <1351255282.63.0.930970476961.issue16328@psf.upfronthosting.co.za>
Message-ID: <1427129174.25.0.306677382373.issue16328@psf.upfronthosting.co.za>


Paul Moore added the comment:

Pip and/or setuptools will add the Scripts directory when needed, so it's not a big deal that the installer doesn't create it. In 2.7.9 and later, and 3.4 onwards, the Scripts directory is created as part of the ensurepip step of the install, so it's pretty much a moot point anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16328>
_______________________________________

From report at bugs.python.org  Mon Mar 23 17:51:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 16:51:05 +0000
Subject: [issue23752] Cleanup io.FileIO
Message-ID: <1427129465.77.0.24572480634.issue23752@psf.upfronthosting.co.za>


New submission from STINNER Victor:

While reviewing a Python implementation of io.FileIO (_pyio.FileIO) in the issue #21859, many issues were found in the C implementation. I open an issue to fix them.

We may fix them before or after the Python implementation is merged.

----------
components: Library (Lib)
messages: 239045
nosy: haypo
priority: normal
severity: normal
status: open
title: Cleanup io.FileIO
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23752>
_______________________________________

From report at bugs.python.org  Mon Mar 23 17:51:21 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 16:51:21 +0000
Subject: [issue21859] Add Python implementation of FileIO
In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za>
Message-ID: <1427129481.84.0.900003174573.issue21859@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I opened the issue #23752: "Cleanup io.FileIO".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21859>
_______________________________________

From report at bugs.python.org  Mon Mar 23 18:16:39 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 17:16:39 +0000
Subject: [issue23753] Drop HAVE_FSTAT: require fstat() to compile/use Python
Message-ID: <1427130999.93.0.226588178703.issue23753@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Topic previously discussed at:
https://mail.python.org/pipermail/python-dev/2013-May/126285.html

Related issue:
http://bugs.python.org/issue12082

Antoine Pitrou wrote in the issue:
"I would personally like to remove HAVE_FSTAT and make Python unconditionally use fstat(). It will make the code quite simpler in some places."

I agree. I'm quite sure that Python doesn't work on such platform, and it would require much more changes than just making fstat optional.

So I'm in favor of dropping the check on fstat() and expect it to be always available.

Examples of Python modules of the standard library using os.fstat:

- fileinput
- genericpath
- netrc
- os which contains "set.add(stat) # fstat always works"
- _pyio (the call is optional, it catchs AttributeError)
- shutil
- socket
- tarfile
- asyncio
- http.client (optional, catch AttributeError)
- http.server
- logging
- io
- etc.

----------
messages: 239047
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: Drop HAVE_FSTAT: require fstat() to compile/use Python
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23753>
_______________________________________

From report at bugs.python.org  Mon Mar 23 18:30:06 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 23 Mar 2015 17:30:06 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1427131806.71.0.158611752304.issue23602@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

[Eric]

> I'm not sure it needs fixing...

Hmm.  We've gone to some lengths to make sure that we get correctly-rounded results for formatting of Decimal and float types, as well as to make sure that operations like converting a Fraction to a float are correctly rounded.  It would be disappointing if the result of formatting a Fraction wasn't correctly rounded, and I'd personally consider it a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Mon Mar 23 19:38:06 2015
From: report at bugs.python.org (Matt Frank)
Date: Mon, 23 Mar 2015 18:38:06 +0000
Subject: [issue23654] infinite loop in faulthandler._stack_overflow
In-Reply-To: <1426200687.84.0.455927631723.issue23654@psf.upfronthosting.co.za>
Message-ID: <1427135886.63.0.594704326717.issue23654@psf.upfronthosting.co.za>


Matt Frank added the comment:

This is a patch that turns off the Intel Compiler's optimization for the stack_overflow() function.  It turns out that icc doesn't support gcc's __attribute__((optimize("no-optimize-sibling-calls"))).  Instead I used an ifdef'd intel-specific pragma that turns off optimization completely for just this function, and just for the intel compiler.

This particular pragma has the benefit that it should also work with the Intel compiler on Windows without needing further ifdefs.

----------
Added file: http://bugs.python.org/file38658/icc-stackoverflow.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23654>
_______________________________________

From report at bugs.python.org  Mon Mar 23 20:05:32 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 23 Mar 2015 19:05:32 +0000
Subject: [issue16328] win_add2path.py sets wrong user path
In-Reply-To: <1351255282.63.0.930970476961.issue16328@psf.upfronthosting.co.za>
Message-ID: <1427137532.39.0.0809810231873.issue16328@psf.upfronthosting.co.za>


Steve Dower added the comment:

This script adds them to PATH. As I said, the original issue is not a bug, but it has drawn attention to something we apparently missed a while ago.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16328>
_______________________________________

From report at bugs.python.org  Mon Mar 23 20:21:16 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 23 Mar 2015 19:21:16 +0000
Subject: [issue16328] win_add2path.py sets wrong user path
In-Reply-To: <1351255282.63.0.930970476961.issue16328@psf.upfronthosting.co.za>
Message-ID: <1427138476.77.0.612258133914.issue16328@psf.upfronthosting.co.za>


Paul Moore added the comment:

Steve - is it the fact that it's not using the versioned user-site directory that you're referring to?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16328>
_______________________________________

From report at bugs.python.org  Mon Mar 23 20:22:46 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 23 Mar 2015 19:22:46 +0000
Subject: [issue16328] win_add2path.py sets wrong user path
In-Reply-To: <1351255282.63.0.930970476961.issue16328@psf.upfronthosting.co.za>
Message-ID: <1427138566.1.0.246339163348.issue16328@psf.upfronthosting.co.za>


Paul Moore added the comment:

... because I think it does do that (see http://bugs.python.org/file38085/userscripts.patch which updates this file)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16328>
_______________________________________

From report at bugs.python.org  Mon Mar 23 20:30:07 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 23 Mar 2015 19:30:07 +0000
Subject: [issue16328] win_add2path.py sets wrong user path
In-Reply-To: <1351255282.63.0.930970476961.issue16328@psf.upfronthosting.co.za>
Message-ID: <1427139007.21.0.442097382846.issue16328@psf.upfronthosting.co.za>


Paul Moore added the comment:

I think the problem here is that as the OP mentioned, win_add2path.py doesn't add the directory if it doesn't exist, so if you run it immediately after install, it won't add the directories that don't exist yet. And because it's setting the registry entries to make the path changes persistent, you only run it once and don't rerun it after those directories are created. Although if you did, that would fix the problem...

Maybe win_add2path.py should add the directories even if they don't exist? It only means removing the isdir check from the line

    if path and path not in envpath and os.path.isdir(path):

I don't really have a feel for whether that would be a good idea. I guess the only harm would be a bit of clutter on %PATH%, and probably no-one cares about that...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16328>
_______________________________________

From report at bugs.python.org  Mon Mar 23 20:32:23 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 23 Mar 2015 19:32:23 +0000
Subject: [issue16328] win_add2path.py sets wrong user path
In-Reply-To: <1351255282.63.0.930970476961.issue16328@psf.upfronthosting.co.za>
Message-ID: <1427139143.1.0.447054967194.issue16328@psf.upfronthosting.co.za>


Paul Moore added the comment:

One further thought - the installer can't create the user scripts directory if you're doing an all-users install, that's sort of the point of "all users". It could do so for a per-user install, but then there would be an inconsistency that I don't think is a good idea.

So maybe skipping the "does the directory exist" check is the only option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16328>
_______________________________________

From report at bugs.python.org  Mon Mar 23 20:38:07 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 23 Mar 2015 19:38:07 +0000
Subject: [issue16328] win_add2path.py sets wrong user path
In-Reply-To: <1351255282.63.0.930970476961.issue16328@psf.upfronthosting.co.za>
Message-ID: <1427139487.39.0.286724979117.issue16328@psf.upfronthosting.co.za>


Paul Moore added the comment:

Here is a patch to fix the issue.

----------
keywords: +patch
Added file: http://bugs.python.org/file38659/addpath.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16328>
_______________________________________

From report at bugs.python.org  Mon Mar 23 20:58:25 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 23 Mar 2015 19:58:25 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1427140705.75.0.227207687307.issue23602@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Absolutely. Fractions are all about exact calculations, much more so than Decimals. So the formatting output should be as accurate as requested or possible (well, excluding infinity).

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Mon Mar 23 21:09:10 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 23 Mar 2015 20:09:10 +0000
Subject: [issue16328] win_add2path.py sets wrong user path
In-Reply-To: <1351255282.63.0.930970476961.issue16328@psf.upfronthosting.co.za>
Message-ID: <1427141350.47.0.905431427489.issue16328@psf.upfronthosting.co.za>


Steve Dower added the comment:

Ah, you're right, it was fixed. Guess I misread my local copy (or I was looking at 3.4).

That patch looks good to me. It'll help cover the case where someone does something to create the directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16328>
_______________________________________

From report at bugs.python.org  Mon Mar 23 21:13:45 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 23 Mar 2015 20:13:45 +0000
Subject: [issue16328] win_add2path.py sets wrong user path
In-Reply-To: <1351255282.63.0.930970476961.issue16328@psf.upfronthosting.co.za>
Message-ID: <1427141625.68.0.563462549141.issue16328@psf.upfronthosting.co.za>


Paul Moore added the comment:

Cool. I'll try to set up a test (it's not covered by the testsuite AFAICT) on a VM or something, just to confirm I haven't broken anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16328>
_______________________________________

From report at bugs.python.org  Mon Mar 23 21:21:53 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Mar 2015 20:21:53 +0000
Subject: [issue23654] infinite loop in faulthandler._stack_overflow
In-Reply-To: <1426200687.84.0.455927631723.issue23654@psf.upfronthosting.co.za>
Message-ID: <20150323202150.16918.74323@psf.io>


Roundup Robot added the comment:

New changeset d6003de8ecc8 by Victor Stinner in branch '3.4':
Issue #23654: Fix faulthandler._stack_overflow() for the Intel C Compiler (ICC)
https://hg.python.org/cpython/rev/d6003de8ecc8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23654>
_______________________________________

From report at bugs.python.org  Mon Mar 23 21:22:12 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 20:22:12 +0000
Subject: [issue23654] infinite loop in faulthandler._stack_overflow
In-Reply-To: <1426200687.84.0.455927631723.issue23654@psf.upfronthosting.co.za>
Message-ID: <1427142132.98.0.0100283156378.issue23654@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks for your contribution Matt!

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23654>
_______________________________________

From report at bugs.python.org  Mon Mar 23 21:31:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 20:31:45 +0000
Subject: [issue23753] Drop HAVE_FSTAT: require fstat() to compile/use Python
In-Reply-To: <1427130999.93.0.226588178703.issue23753@psf.upfronthosting.co.za>
Message-ID: <1427142705.21.0.721919569897.issue23753@psf.upfronthosting.co.za>


STINNER Victor added the comment:

stat.patch: Stop pretending that Python works without stat() nor fstat(), consider that these functions are always available.

----------
keywords: +patch
Added file: http://bugs.python.org/file38660/stat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23753>
_______________________________________

From report at bugs.python.org  Mon Mar 23 21:32:14 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 20:32:14 +0000
Subject: [issue23753] Drop HAVE_FSTAT: require fstat() to compile/use Python
In-Reply-To: <1427130999.93.0.226588178703.issue23753@psf.upfronthosting.co.za>
Message-ID: <1427142734.14.0.956538667043.issue23753@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23753>
_______________________________________

From report at bugs.python.org  Mon Mar 23 21:42:41 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 23 Mar 2015 20:42:41 +0000
Subject: [issue16328] win_add2path.py sets wrong user path
In-Reply-To: <1351255282.63.0.930970476961.issue16328@psf.upfronthosting.co.za>
Message-ID: <1427143361.57.0.0883472324479.issue16328@psf.upfronthosting.co.za>


Paul Moore added the comment:

One further thought. This is a change in behaviour (albeit to a script in Tools), so I'm inclined to say it's a new feature for 3.5, rather than a bugfix to be backported to 2.7 and 3.4.

For users of 2.7/3.4, the workaround is simply to rerun the script - it doesn't add directories it has already added, so it's safe to rerun to add newly created directories.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16328>
_______________________________________

From report at bugs.python.org  Mon Mar 23 21:46:59 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 20:46:59 +0000
Subject: [issue23752] Cleanup io.FileIO
In-Reply-To: <1427129465.77.0.24572480634.issue23752@psf.upfronthosting.co.za>
Message-ID: <1427143619.93.0.955042242555.issue23752@psf.upfronthosting.co.za>


STINNER Victor added the comment:

fileio_drop_dup_fstat.patch: Remove the duplicate call to fstat() in fileio.c. Tests pass, invalid FD are still detected since there is a second call to fstat() which also raises OSError(EBADF) if fstat(fd) fails.

----------
keywords: +patch
Added file: http://bugs.python.org/file38661/fileio_drop_dup_fstat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23752>
_______________________________________

From report at bugs.python.org  Mon Mar 23 21:48:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 20:48:31 +0000
Subject: [issue23753] Drop HAVE_FSTAT: require fstat() to compile/use Python
In-Reply-To: <1427130999.93.0.226588178703.issue23753@psf.upfronthosting.co.za>
Message-ID: <1427143711.93.0.745641952089.issue23753@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See issue22623 for moving in opposite direction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23753>
_______________________________________

From report at bugs.python.org  Mon Mar 23 21:50:09 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Mar 2015 20:50:09 +0000
Subject: [issue22623] Missing guards for some POSIX functions
In-Reply-To: <1413204243.21.0.451981347417.issue22623@psf.upfronthosting.co.za>
Message-ID: <1427143809.36.0.671610763427.issue22623@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Personally, I'd rather answer that it's not our problem if some systems are not POSIX-compliant. Maintainers of such systems can always maintain a patch to disable the missing functionality. Adding conditionals everywhere has a non-trivial maintenance cost.

----------
nosy: +loewis, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22623>
_______________________________________

From report at bugs.python.org  Mon Mar 23 21:54:21 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 20:54:21 +0000
Subject: [issue23752] Cleanup io.FileIO
In-Reply-To: <1427129465.77.0.24572480634.issue23752@psf.upfronthosting.co.za>
Message-ID: <1427144061.06.0.350439466605.issue23752@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The previous change related to fstat() is the changeset 3b5279b5bfd1 from the issue #21679. The changeset introduces the private _blksize attribute. The strange thing is that the changelog is:
"Issue #21679: Prevent extraneous fstat() calls during open().  Patch by Bohuslav Kabrda."

fstat() was called twice and it is still called twice. Maybe I missed something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23752>
_______________________________________

From report at bugs.python.org  Mon Mar 23 22:05:20 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 21:05:20 +0000
Subject: [issue22623] Missing guards for some POSIX functions
In-Reply-To: <1413204243.21.0.451981347417.issue22623@psf.upfronthosting.co.za>
Message-ID: <1427144720.2.0.99259817761.issue22623@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Many POSIX functions aren?t available on every system, especially embedded ones.

What do you call "embedded systems"? I worked on set top boxes (the box to watch television) between 2011 and 2013 and we had a regular Linux kernel with all POSIX functions. Most of the time, the CPU was a slow MIPS. The tool chain was based on GCC. For some hardware, we used the ?libc but this C library provides all functions required by Python.

> Personally, I'd rather answer that it's not our problem if some systems are not POSIX-compliant. Maintainers of such systems can always maintain a patch to disable the missing functionality. Adding conditionals everywhere has a non-trivial maintenance cost.

I agree. Anyway, in the embedded world, softwares are usually old and heavily patched. For example, in 2013 we still used Python 2.5.2 with a lot of patches. For example, patches for cross compilation. But also backported features like HTTP Keep-Alive or HTTPS checks.

Technically, you can easily fork Python repository and keep your patches up to date using rebase.

We defined better rules to support officially a platform. A requirement is for example to have a buildbot running tests daily on the platform. I'm not sure that you are able to host a public buildbot for each custom embedded platform...

Android looks a more important target and it was already discussed to setup a Android buildbot.

I'm in favor of *dropping* all these annoying #ifdef because it's harder to review, maintain and debug such code. Here is my contribution: issue #23753 "Drop HAVE_FSTAT: require fstat() to compile/use Python". A concrete example: we are working on a Python implementation of io.FileIO and I don't want to see hasattr(os, 'fstat') in the Python code because it has a performance cost *at runtime* (see issue #21859).

See also the new Mobile-SIG mailing list which is maybe more appropriate to discuss such changes:
https://mail.python.org/mailman/listinfo/mobile-sig

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22623>
_______________________________________

From report at bugs.python.org  Mon Mar 23 22:06:22 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 21:06:22 +0000
Subject: [issue23753] Drop HAVE_FSTAT: require fstat() to compile/use Python
In-Reply-To: <1427130999.93.0.226588178703.issue23753@psf.upfronthosting.co.za>
Message-ID: <1427144782.29.0.99606611007.issue23753@psf.upfronthosting.co.za>


STINNER Victor added the comment:

My changes only *removes* code and so make it simpler ;-)

$ diffstat stat.patch 
 Include/fileutils.h  |    6 ------
 Include/pyport.h     |   22 ----------------------
 Modules/_io/fileio.c |   20 --------------------
 Modules/mmapmodule.c |    4 ----
 Python/fileutils.c   |   16 ----------------
 Python/marshal.c     |    4 ----
 6 files changed, 72 deletions(-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23753>
_______________________________________

From report at bugs.python.org  Mon Mar 23 22:16:11 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 21:16:11 +0000
Subject: [issue23754] Add a new os.read_into() function to avoid memory copies
Message-ID: <1427145371.9.0.485193711036.issue23754@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Sockets have a recv_into() method, io.IOBase has a readinto() method, but there is no os.read_into() function. It would avoid memory copies. It would benefit to the Python implementation FileIO (readall() and readinto() methods), see the issue #21859.

----------
components: Library (Lib)
messages: 239069
nosy: haypo
priority: normal
severity: normal
status: open
title: Add a new os.read_into() function to avoid memory copies
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23754>
_______________________________________

From report at bugs.python.org  Mon Mar 23 22:18:52 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 21:18:52 +0000
Subject: [issue23752] Cleanup io.FileIO
In-Reply-To: <1427129465.77.0.24572480634.issue23752@psf.upfronthosting.co.za>
Message-ID: <1427145532.82.0.709473992676.issue23752@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also issue #21861: "io class name are hardcoded in reprs".

In my review of _pyio.FileIO, I asked if it would be possible to use __qualname__ in __getstate__().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23752>
_______________________________________

From report at bugs.python.org  Mon Mar 23 22:19:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 21:19:17 +0000
Subject: [issue21859] Add Python implementation of FileIO
In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za>
Message-ID: <1427145557.07.0.458893746154.issue21859@psf.upfronthosting.co.za>


STINNER Victor added the comment:

New issue #23754: "Add a new os.read_into() function to avoid memory copies".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21859>
_______________________________________

From report at bugs.python.org  Mon Mar 23 22:26:50 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 21:26:50 +0000
Subject: [issue23754] Add a new os.read_into() function to avoid memory copies
In-Reply-To: <1427145371.9.0.485193711036.issue23754@psf.upfronthosting.co.za>
Message-ID: <1427146010.29.0.499468124016.issue23754@psf.upfronthosting.co.za>


STINNER Victor added the comment:

os.read_into() may be used by the following functions.

subprocess.Popen._execute_child():

    # Wait for exec to fail or succeed; possibly raising an
    # exception (limited in size)
    errpipe_data = bytearray()
    while True:
        part = os.read(errpipe_read, 50000)
        errpipe_data += part
        if not part or len(errpipe_data) > 50000:
            break

subprocess.Popen.communicate():

    self._fileobj2output = {}
    if self.stdout:
        self._fileobj2output[self.stdout] = []
    ...
    data = os.read(key.fd, 32768)
    if not data:
        ...
    self._fileobj2output[key.fileobj].append(data)
    ...
    stdout = b''.join(...)

multiprocessing.Connection._recv():

    def _recv(self, size, read=_read):
        buf = io.BytesIO()
        handle = self._handle
        remaining = size
        while remaining > 0:
            chunk = read(handle, remaining)
            n = len(chunk)
            if n == 0:
                if remaining == size:
                    raise EOFError
                else:
                    raise OSError("got end of file during message")
            buf.write(chunk)
            remaining -= n
        return buf

multiprocessing.read_unsigned():

    def read_unsigned(fd):
        data = b''
        length = UNSIGNED_STRUCT.size
        while len(data) < length:
            s = os.read(fd, length - len(data))
            if not s:
                raise EOFError('unexpected EOF')
            data += s
        return UNSIGNED_STRUCT.unpack(data)[0]

The problem is that some functions still require to return a bytes, not a bytearray or something else. Converting a bytearray to a bytes still require a memory copy...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23754>
_______________________________________

From report at bugs.python.org  Mon Mar 23 22:28:41 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 21:28:41 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>
Message-ID: <1427146121.34.0.243057298547.issue23648@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Well, all the syscalls which can blocki can fail with EINTR, so all
> I:O related one.

This is also what I expect, but how do you explain that I'm unable to see os.stat() failing with EINTR? I'm testing on ext4 file system. May it occur with other file systems (ex: NFS)? Or maybe not on Linux, but on other platforms?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Mon Mar 23 22:31:25 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 23 Mar 2015 21:31:25 +0000
Subject: [issue16328] win_add2path.py sets wrong user path
In-Reply-To: <1351255282.63.0.930970476961.issue16328@psf.upfronthosting.co.za>
Message-ID: <1427146285.3.0.443839549886.issue16328@psf.upfronthosting.co.za>


Paul Moore added the comment:

There's actually a bug in the pre-3.5 script beyond the "does the directory exist" check. The code is

    if hasattr(site, "USER_SITE"):
        userpath = site.USER_SITE.replace(appdata, "%APPDATA%")
        userscripts = os.path.join(userpath, "Scripts")

which sets userscripts as %APPDATA%\Python\Python34\site-packages\Scripts, which is completely wrong. Stripping off 2 directory levels gives the correct answer, but that seems a bit arbitrary - using sysconfig seems more robust.

Also, there's another point made in the original report - the registry variable HKCU\Environment\PATH is set to "%PATH%;<the stuff we add>". That's just wrong - the user PATH variable is added to the system PATH variable, so why interpolate the existing value? It may be that the behaviour varies in different Windows versions, I don't know enough about how older versions work to comment on that.

There are enough bugs here that I suspect that very few people have ever used the script :-( Maybe it would be better to leave the older versions alone, and simply rewrite or remove it for 3.5 (I know Steve has ideas about providing new path-setting scripts)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16328>
_______________________________________

From report at bugs.python.org  Mon Mar 23 22:35:06 2015
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 23 Mar 2015 21:35:06 +0000
Subject: [issue23753] Drop HAVE_FSTAT: require fstat() to compile/use Python
In-Reply-To: <1427144782.29.0.99606611007.issue23753@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2KBYQm3OH63dR22-Au+XRbv1Ynsc17GtedKbB=8y6u_Q@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

+1 from me, fstat() has always been par of POSIX.
It's really likely Python won't build anyway on such systems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23753>
_______________________________________

From report at bugs.python.org  Mon Mar 23 22:50:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Mar 2015 21:50:42 +0000
Subject: [issue23753] Drop HAVE_FSTAT: require fstat() to compile/use Python
In-Reply-To: <1427130999.93.0.226588178703.issue23753@psf.upfronthosting.co.za>
Message-ID: <1427147442.88.0.277687869147.issue23753@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue12082.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23753>
_______________________________________

From report at bugs.python.org  Mon Mar 23 22:51:24 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 21:51:24 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>
Message-ID: <1427147484.93.0.501180467581.issue23648@psf.upfronthosting.co.za>


STINNER Victor added the comment:

fstat_not_eintr.py: run this script from a NFS share and unplug the network cable, wait, replug. Spoiler: fstat() hangs until the network is back, CTRL+c or setitimer() don't interrupt it.

By the way, it looks like the itimer is interrupted during fstat!

Extract of strace output:
---
<cable unplugged>

rt_sigreturn()                          = -1 EINTR (Interrupted system call)
select(0, NULL, NULL, NULL, {0, 100000}) = ? ERESTARTNOHAND (To be restarted if no handler)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn()                          = -1 EINTR (Interrupted system call)
write(1, "fstat...\n", 9)               = 9

fstat(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0

<cable replugged>

--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
rt_sigreturn()                          = 0
---

The fstat() took 3 seconds, I expected 30 SIGALRM, but none occurred during fstat().

----------
Added file: http://bugs.python.org/file38662/fstat_not_eintr.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Mon Mar 23 23:03:39 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 23 Mar 2015 22:03:39 +0000
Subject: [issue23731] Implement PEP 488
In-Reply-To: <1426944831.0.0.593089874415.issue23731@psf.upfronthosting.co.za>
Message-ID: <1427148219.84.0.139898330158.issue23731@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23731>
_______________________________________

From report at bugs.python.org  Mon Mar 23 23:04:30 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 23 Mar 2015 22:04:30 +0000
Subject: [issue23058] argparse silently ignores arguments
In-Reply-To: <1418677327.73.0.355612765077.issue23058@psf.upfronthosting.co.za>
Message-ID: <1427148270.06.0.669899742222.issue23058@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23058>
_______________________________________

From report at bugs.python.org  Mon Mar 23 23:38:57 2015
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Mon, 23 Mar 2015 22:38:57 +0000
Subject: [issue23753] Drop HAVE_FSTAT: require fstat() to compile/use Python
In-Reply-To: <1427147442.88.0.277687869147.issue23753@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2rAE9QbWCPL7Y55QKMP0_KjLHcTv0hqeyK-ogqqGa+yQ@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> Serhiy Storchaka added the comment:
>
> See also issue12082.

Yes, but I don't think we want to clutter the code to support exotic
niche platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23753>
_______________________________________

From report at bugs.python.org  Mon Mar 23 23:40:14 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Mar 2015 22:40:14 +0000
Subject: [issue23754] Add a new os.read_into() function to avoid memory copies
In-Reply-To: <1427145371.9.0.485193711036.issue23754@psf.upfronthosting.co.za>
Message-ID: <1427150414.5.0.303185238321.issue23754@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Why do you want to optimize the pure Python FileIO?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23754>
_______________________________________

From report at bugs.python.org  Mon Mar 23 23:55:05 2015
From: report at bugs.python.org (Piotr Dobrogost)
Date: Mon, 23 Mar 2015 22:55:05 +0000
Subject: [issue23754] Add a new os.read_into() function to avoid memory copies
In-Reply-To: <1427145371.9.0.485193711036.issue23754@psf.upfronthosting.co.za>
Message-ID: <1427151305.31.0.357445404505.issue23754@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at bugs.python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23754>
_______________________________________

From report at bugs.python.org  Mon Mar 23 23:57:03 2015
From: report at bugs.python.org (Piotr Dobrogost)
Date: Mon, 23 Mar 2015 22:57:03 +0000
Subject: [issue23752] Cleanup io.FileIO
In-Reply-To: <1427129465.77.0.24572480634.issue23752@psf.upfronthosting.co.za>
Message-ID: <1427151423.51.0.961493994437.issue23752@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at bugs.python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23752>
_______________________________________

From report at bugs.python.org  Tue Mar 24 00:15:26 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 23 Mar 2015 23:15:26 +0000
Subject: [issue23058] argparse silently ignores arguments
In-Reply-To: <1418677327.73.0.355612765077.issue23058@psf.upfronthosting.co.za>
Message-ID: <1427152526.91.0.528966370711.issue23058@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +nailor, r.david.murray
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23058>
_______________________________________

From report at bugs.python.org  Tue Mar 24 00:47:06 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Mar 2015 23:47:06 +0000
Subject: [issue23754] Add a new os.read_into() function to avoid memory copies
In-Reply-To: <1427145371.9.0.485193711036.issue23754@psf.upfronthosting.co.za>
Message-ID: <1427154426.89.0.155646210006.issue23754@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23754>
_______________________________________

From report at bugs.python.org  Tue Mar 24 01:33:35 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 00:33:35 +0000
Subject: [issue22942] Language Reference - optional comma
In-Reply-To: <1416945158.04.0.329806790258.issue22942@psf.upfronthosting.co.za>
Message-ID: <1427157215.25.0.644726430231.issue22942@psf.upfronthosting.co.za>


Martin Panter added the comment:

See also Issue 9232, about adding support for trailing commas in all cases of function calls and definitions.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22942>
_______________________________________

From report at bugs.python.org  Tue Mar 24 01:50:48 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 00:50:48 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1427158248.95.0.549591896309.issue9232@psf.upfronthosting.co.za>


Martin Panter added the comment:

See also Issue 22942 about existing problems with the language documentation.

I would like to see trailing commas supported consistently, especially in function calls. (I think the patch here only does function definitions?) I like to use them when writing arguments on multiple lines, and it is surprising that adding packed *positional arguments can trigger a syntax error.

Maybe this is stretching the scope a bit too far, but it would also be nice to allow more keyword arguments after the **keyword unpacking:

print(1, 2, end=".\n", *(3, 4))  # Supported, but confusing
print(1, 2, *(3, 4), end=".\n")  # Better; also suported
print(1, 2, **dict(sep="-"), end=".\n")  # Unsupported, but would be nice
print(end=".\n", 1, 2)  # Unsupported, for good reason

Maybe some of this is covered by Issue 2292 (generalizing * unpacking), but I haven?t been following that, so I?m not sure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9232>
_______________________________________

From report at bugs.python.org  Tue Mar 24 01:55:06 2015
From: report at bugs.python.org (Stephen Gallagher)
Date: Tue, 24 Mar 2015 00:55:06 +0000
Subject: [issue23755] tempfile.NamedTemporaryFile should be able to toggle
 "delete"
Message-ID: <1427158506.1.0.856842662258.issue23755@psf.upfronthosting.co.za>


New submission from Stephen Gallagher:

Currently, NamedTemporaryFile takes an attribute at initialization that allows it to remove the temporary file on going out of scope or else leave it around. However, it's not possible to change this after the fact.

It would be a much more sensible pattern to be able to operate with auto-deletion enabled while constructing the file and then to be able to toggle this option off once the file is completed.

For example, the use-case I have in mind is that I am creating a file that, once complete, will go into a well-known location. Because of known attacks, the only secure way to create this file is to generate it in a temporary location and then atomically move (os.rename()) it into its final location. This avoids time-of-check-time-of-use risks as well as avoiding overwriting the old file if something goes wrong.

It would be handy if tempfile could be extended to support this operation.

Additionally, I attempted to solve this by monkey-patching tempfile and overriding the __del__ function on the _TemporaryFileWrapper object to be a no-op. This works in python 2.7.9, but seems to be ignored on python 3.4.2.

Example code:

{{{
import tempfile
import os

f = tempfile.NamedTemporaryFile()
os.unlink(f.name)
f.unlink = lambda x: None
}}}

If you run that under python2, it will succeed. On Python 3, it will noisily report:
Exception ignored in: <bound method _TemporaryFileCloser.__del__ of <tempfile._TemporaryFileCloser object at 0x7f7a24548c88>>
Traceback (most recent call last):
  File "/usr/lib64/python3.4/tempfile.py", line 366, in __del__
  File "/usr/lib64/python3.4/tempfile.py", line 362, in close
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/tmpqs5k6w7q'

----------
components: Library (Lib)
messages: 239082
nosy: Stephen Gallagher
priority: normal
severity: normal
status: open
title: tempfile.NamedTemporaryFile should be able to toggle "delete"
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23755>
_______________________________________

From report at bugs.python.org  Tue Mar 24 01:57:01 2015
From: report at bugs.python.org (Stephen Gallagher)
Date: Tue, 24 Mar 2015 00:57:01 +0000
Subject: [issue23755] tempfile.NamedTemporaryFile should be able to toggle
 "delete"
In-Reply-To: <1427158506.1.0.856842662258.issue23755@psf.upfronthosting.co.za>
Message-ID: <1427158621.06.0.152403038884.issue23755@psf.upfronthosting.co.za>


Stephen Gallagher added the comment:

Oops, the temporary code I sent indicated that I was overriding the unlink() function (which I also tried, just in case __del__ was somehow protected). Neither monkeypatching unlink nor __del__ actually worked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23755>
_______________________________________

From report at bugs.python.org  Tue Mar 24 02:07:00 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 24 Mar 2015 01:07:00 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1427159220.35.0.146645098305.issue9232@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

It looks like if it was not for Raymond's mild dissent, [1], we would
have a consensus last time this was raised on python-dev, [2-7].

[1] -? Raymond Hettinger https://mail.python.org/pipermail/python-dev/2010-December/106782.html
[2] +0 Guido van Rossum https://mail.python.org/pipermail/python-dev/2010-December/106780.html
[3] +0.5 Alexander Belopolsky https://mail.python.org/pipermail/python-dev/2010-December/106782.html
[4] +1 Antoine Pitrou https://mail.python.org/pipermail/python-dev/2010-December/106783.html
[5] +1 Glenn Linderman https://mail.python.org/pipermail/python-dev/2010-December/106784.html
[6] +1 Cameron Simpson https://mail.python.org/pipermail/python-dev/2010-December/106788.html
[7] +1 Terry Reedy https://mail.python.org/pipermail/python-dev/2010-December/106789.html

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9232>
_______________________________________

From report at bugs.python.org  Tue Mar 24 02:12:02 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 24 Mar 2015 01:12:02 +0000
Subject: [issue9232] Allow trailing comma in any function argument list.
In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za>
Message-ID: <1427159522.68.0.134212366771.issue9232@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

.. and a couple more -1's on the tracker:

msg123851 - Martin v. L?wis
msg123848 - Brett Cannon

It looks like a round on python-ideas is needed before this can move forward.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9232>
_______________________________________

From report at bugs.python.org  Tue Mar 24 02:46:48 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 24 Mar 2015 01:46:48 +0000
Subject: [issue23744] Speed-up deque.__bool__
In-Reply-To: <1427090712.12.0.119881784491.issue23744@psf.upfronthosting.co.za>
Message-ID: <1427161608.58.0.222965195961.issue23744@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Is it worth the definition of tp_as_number and maintaining another method for a micro-optimization? Presumably every collection in Python would benefit slightly from this (say, defaultdict in the same file, list, tuple, etc.), but none of them bother. Why would deque be worth the optimization and not the more commonly used built-ins?

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23744>
_______________________________________

From report at bugs.python.org  Tue Mar 24 02:52:35 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 01:52:35 +0000
Subject: [issue23750] Clarify difference between os.system/subprocess.call in
 section "Replacing os.system()"
In-Reply-To: <1427120891.65.0.0570880238086.issue23750@psf.upfronthosting.co.za>
Message-ID: <1427161955.09.0.563696841636.issue23750@psf.upfronthosting.co.za>


Martin Panter added the comment:

Another difference is that (at least POSIX) system() blocks SIGINT and SIGQUIT while the child is running. Compare:

$ python3 -c 'print("Waiting"); import os; print("Returned", os.system("sleep 3 && exit 3"))'
Sleeping
Returned 768
$ python3 -c 'print("Sleeping"); import os; print("Returned", os.system("sleep 3 && exit 3"))'
Waiting
^CReturned 2  # Hit Ctrl+C during sleep command
$ python3 -c 'print("Sleeping"); import subprocess; print("Returned", subprocess.call("sleep 3 && exit 3", shell=True))'
Sleeping
Returned 3
$ python3 -c 'print("Sleeping"); import subprocess; print("Returned", subprocess.call("sleep 3 && exit 3", shell=True))'
Sleeping
^CTraceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.4/subprocess.py", line 539, in call
    return p.wait(timeout=timeout)
  File "/usr/lib/python3.4/subprocess.py", line 1566, in wait
    (pid, sts) = self._try_wait(0)
  File "/usr/lib/python3.4/subprocess.py", line 1514, in _try_wait
    (pid, sts) = _eintr_retry_call(os.waitpid, self.pid, wait_flags)
  File "/usr/lib/python3.4/subprocess.py", line 491, in _eintr_retry_call
    return func(*args)
KeyboardInterrupt
[Exit 1]

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23750>
_______________________________________

From report at bugs.python.org  Tue Mar 24 03:06:23 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 24 Mar 2015 02:06:23 +0000
Subject: [issue23744] Speed-up deque.__bool__
In-Reply-To: <1427090712.12.0.119881784491.issue23744@psf.upfronthosting.co.za>
Message-ID: <1427162783.58.0.285913963641.issue23744@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

On further checking, this probably gives slightly greater benefit to deque than it would for list, tuple, dict, etc., only because PyObject_IsTrue checks for mapping before sequence; deque is a pure sequence, no mapping, so it has to fail an extra test before it reaches the sequence length interface check and uses it, where any sequence that supports extended slicing must support parts of the mapping interface, and usually copies the sequence function pointer to the mapping length slot as well.

Still hard to justify, though. Testing the truthiness of a deque is not likely to be the critical code path for many applications (if you want to take advantage of deque's atomic behaviors, you're using EAFP patterns anyway, not testing truthiness), and the gain in boolean testing means other (likely low probability tests) will run slower (for example, testing a deque with PyNumber_Check would go slower, because it would pass an extra test before failing each time).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23744>
_______________________________________

From report at bugs.python.org  Tue Mar 24 03:57:04 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 02:57:04 +0000
Subject: [issue15945] memoryview + bytes fails
In-Reply-To: <1347704879.16.0.744568990947.issue15945@psf.upfronthosting.co.za>
Message-ID: <1427165823.99.0.982068176461.issue15945@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15945>
_______________________________________

From report at bugs.python.org  Tue Mar 24 04:26:01 2015
From: report at bugs.python.org (Davin Potts)
Date: Tue, 24 Mar 2015 03:26:01 +0000
Subject: [issue21342] multiprocessing RLock and Lock raise incorrect
 exceptions when releasing an unlocked lock.
In-Reply-To: <1398319251.34.0.871128764935.issue21342@psf.upfronthosting.co.za>
Message-ID: <1427167561.69.0.0833375458778.issue21342@psf.upfronthosting.co.za>


Davin Potts added the comment:

Since the time of its introduction in 2.6, a call to multiprocessing.Lock.release on an already unlocked lock resulted in behavior that did not match that of threading.Lock.release (which raised a thread.error as far back as 2.4 and probably longer than that historically).  Similar can be said of the RLock analogs.

This is but one discrepancy of many as described in issue23484.  Behavior in threading's locks going back as far as 2.2 has not been / is not matched in multiprocessing's locks since its arrival -- it does not appear to be a case of recent changes opening a rift between these two modules' locks' behavior.

Changing the behavior that has existed in multiprocessing's locks since its arrival in the stdlib would break existing code which depends upon it (as referenced in msg236431) so I will propose a patch for issue23484 to move ahead with correcting the documentation to describe the established behaviors of multiprocessing's locks -- as part of that proposed documentation change, the behaviors discussed here should also be covered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21342>
_______________________________________

From report at bugs.python.org  Tue Mar 24 04:26:55 2015
From: report at bugs.python.org (Davin Potts)
Date: Tue, 24 Mar 2015 03:26:55 +0000
Subject: [issue21342] multiprocessing RLock and Lock raise incorrect
 exceptions when releasing an unlocked lock.
In-Reply-To: <1398319251.34.0.871128764935.issue21342@psf.upfronthosting.co.za>
Message-ID: <1427167615.52.0.866960737474.issue21342@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


----------
versions: +Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21342>
_______________________________________

From report at bugs.python.org  Tue Mar 24 04:36:29 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 03:36:29 +0000
Subject: [issue22208] tarfile can't add in memory files (reopened)
In-Reply-To: <1408145357.61.0.947327827691.issue22208@psf.upfronthosting.co.za>
Message-ID: <1427168189.35.0.848097805056.issue22208@psf.upfronthosting.co.za>


Martin Panter added the comment:

If you read the documentation it is clear that gettarfile() requires an OS file, so won?t work with an internal Python-only file object. Maybe the documentation could be tweaked, but I don?t think the gettarfile() implementation should be changed. To me the whole point of it is to call fstat() on the file and fill in the TarInfo attributes appropriately.

Instead, perhaps an enhancement could be made that allowed something like this:

metadata = TarInfo.make_file('helloworld.txt', len(b))
tarFileObj.addfile(metadata, io.BytesIO(b))

The corresponding TarInfo class could grow new presets looking something like:

class TarInfo:
    @classmethod
    def make_file(cls, name, size):  # Name and size are mandatory
        self = cls(name)
        self.type = REGTYPE
        self.size = size
        self.mtime = None  # Force addfile() to set it to some default time.time() value
        self.mode = 0o644
        return self
    
    @classmethod
    def make_executable(cls, name, size):
        ...
        self.mode = 0o755
        ...
    
    @classmethod
    def make_directory(cls, name):
        ...
        self.type = DIRTYPE
        ...
    
    def make_hard_link(cls, name, target)
    def make_symlink(cls, name, target)
    def make_block_device(cls, name, major, minor)  # Set undocumented attributes
    def make_char_device(cls, name, major, minor)

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22208>
_______________________________________

From report at bugs.python.org  Tue Mar 24 07:23:52 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 Mar 2015 06:23:52 +0000
Subject: [issue23744] Speed-up deque.__bool__
In-Reply-To: <1427090712.12.0.119881784491.issue23744@psf.upfronthosting.co.za>
Message-ID: <1427178232.75.0.581301552666.issue23744@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks for taking a look.   IMO, the cost of this one is near zero and there is a modest benefit.  It is simple enough that I don't feel any angst about applying it.  I'm doing several little touch-ups to the module, individually nothing, but collectively making it better overall.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23744>
_______________________________________

From report at bugs.python.org  Tue Mar 24 07:24:05 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 06:24:05 +0000
Subject: [issue23744] Speed-up deque.__bool__
In-Reply-To: <1427090712.12.0.119881784491.issue23744@psf.upfronthosting.co.za>
Message-ID: <20150324062402.7267.10023@psf.io>


Roundup Robot added the comment:

New changeset bb27dff7f83f by Raymond Hettinger in branch 'default':
Issue 23744:  Minor speed-up for deque.__bool__().
https://hg.python.org/cpython/rev/bb27dff7f83f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23744>
_______________________________________

From report at bugs.python.org  Tue Mar 24 07:24:22 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 Mar 2015 06:24:22 +0000
Subject: [issue23744] Speed-up deque.__bool__
In-Reply-To: <1427090712.12.0.119881784491.issue23744@psf.upfronthosting.co.za>
Message-ID: <1427178262.7.0.550514001935.issue23744@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23744>
_______________________________________

From report at bugs.python.org  Tue Mar 24 07:45:56 2015
From: report at bugs.python.org (Piotr Dobrogost)
Date: Tue, 24 Mar 2015 06:45:56 +0000
Subject: [issue21861] io class name are hardcoded in reprs
In-Reply-To: <1403631418.74.0.109096243494.issue21861@psf.upfronthosting.co.za>
Message-ID: <1427179556.11.0.167374783768.issue21861@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at bugs.python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21861>
_______________________________________

From report at bugs.python.org  Tue Mar 24 08:35:37 2015
From: report at bugs.python.org (py.user)
Date: Tue, 24 Mar 2015 07:35:37 +0000
Subject: [issue14260] re.groupindex is available for modification and
 continues to work, having incorrect data inside it
In-Reply-To: <1331530103.22.0.0779581075646.issue14260@psf.upfronthosting.co.za>
Message-ID: <1427182537.48.0.533956630289.issue14260@psf.upfronthosting.co.za>


py.user added the comment:

@Serhiy Storchaka
> What approach looks better, a copy or a read-only proxy?

ISTM, your proxy patch is better, because it expects an exception rather than silence.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14260>
_______________________________________

From report at bugs.python.org  Tue Mar 24 09:00:46 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 08:00:46 +0000
Subject: [issue21511] Thinko in Lib/quopri.py, decoding b"==" to b"="
In-Reply-To: <1400171855.37.0.067918723363.issue21511@psf.upfronthosting.co.za>
Message-ID: <1427184046.22.0.58750249211.issue21511@psf.upfronthosting.co.za>


Martin Panter added the comment:

The implementation has been fixed for Issue 23681 to slice instead of index, and now compares byte strings:

>>> import quopri
>>> quopri.decodestring(b"123==four")
b'123=four'
>>> quopri.a2b_qp = None
>>> quopri.decodestring(b"123==four")
b'123=four'

However, I think a test still needs to be written to cover this branch of the code.

----------
nosy: +vadmium
title: Thinko in Lib/quopri.py -> Thinko in Lib/quopri.py, decoding b"==" to b"="

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21511>
_______________________________________

From report at bugs.python.org  Tue Mar 24 09:11:50 2015
From: report at bugs.python.org (Link Mauve)
Date: Tue, 24 Mar 2015 08:11:50 +0000
Subject: [issue22623] Missing guards for some POSIX functions
In-Reply-To: <1427144720.2.0.99259817761.issue22623@psf.upfronthosting.co.za>
Message-ID: <20150324081123.GA13705@yuyuko>


Link Mauve added the comment:

On Mon, Mar 23, 2015 at 09:05:20PM +0000, STINNER Victor wrote:
> 
> STINNER Victor added the comment:
> 
> > Many POSIX functions aren?t available on every system, especially embedded ones.
> 
> What do you call "embedded systems"? I worked on set top boxes (the box to watch television) between 2011 and 2013 and we had a regular Linux kernel with all POSIX functions. Most of the time, the CPU was a slow MIPS. The tool chain was based on GCC. For some hardware, we used the ?libc but this C library provides all functions required by Python.

My target platforms have been the Newlib-based Wii and 3DS homebrew toolchains, which emulate a POSIX system on top of the raw hardware (or in the case of the 3DS, a proprietary micro-kernel.

> 
> > Personally, I'd rather answer that it's not our problem if some systems are not POSIX-compliant. Maintainers of such systems can always maintain a patch to disable the missing functionality. Adding conditionals everywhere has a non-trivial maintenance cost.
> 
> I agree. Anyway, in the embedded world, softwares are usually old and heavily patched. For example, in 2013 we still used Python 2.5.2 with a lot of patches. For example, patches for cross compilation. But also backported features like HTTP Keep-Alive or HTTPS checks.

There is a port of Python 2.5.something for the Wii, terribly outdated, and this is why I wanted to merge the non-specifics parts of my port upstream, as I thought it would help everyone in that case.

> 
> Technically, you can easily fork Python repository and keep your patches up to date using rebase.
> 
> We defined better rules to support officially a platform. A requirement is for example to have a buildbot running tests daily on the platform. I'm not sure that you are able to host a public buildbot for each custom embedded platform...

I can provide such a buildbot on my spare Wii.  Not really for the 3DS yet, as the homebrew scene is much younger there and unrecoverable lockups happen.

> 
> Android looks a more important target and it was already discussed to setup a Android buildbot.
> 
> I'm in favor of *dropping* all these annoying #ifdef because it's harder to review, maintain and debug such code. Here is my contribution: issue #23753 "Drop HAVE_FSTAT: require fstat() to compile/use Python". A concrete example: we are working on a Python implementation of io.FileIO and I don't want to see hasattr(os, 'fstat') in the Python code because it has a performance cost *at runtime* (see issue #21859).

On those two platforms, fstat() is correctly defined and works fine, so it shouldn?t be a problem to drop its #ifdef.

> 
> See also the new Mobile-SIG mailing list which is maybe more appropriate to discuss such changes:
> https://mail.python.org/mailman/listinfo/mobile-sig
> 
> ----------
> nosy: +haypo
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22623>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22623>
_______________________________________

From report at bugs.python.org  Tue Mar 24 09:25:17 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 08:25:17 +0000
Subject: [issue23756] Tighten definition of bytes-like objects
Message-ID: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>


New submission from Martin Panter:

There are moves at documenting and implementing support for ?bytes-like? objects in more APIs, such as the ?io? module (Issue 20699), http.client (Issue 23740). The glossary definition is currently ?An object that supports the Buffer Protocol, like bytes, bytearray or memoryview.? This was originally added for Issue 16518. However after reading Issue 23688, I realized that it should probably not mean absolutely _any_ object supporting the buffer protocol. For instance:

>>> reverse_view = memoryview(b"123")[::-1]
>>> stdout.buffer.write(reverse_view)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BufferError: memoryview: underlying buffer is not C-contiguous

I think the definition should at least be tightened to only objects with a contiguous buffer, and ?contiguous? should be defined (probably in the linked C API page or the memoryview.contiguous flag definition, not the glossary). So far, my understanding is these are contiguous:

* A zero-dimensional object, such as a ctypes object
* An multi-dimensional array with items stored contiguously in order of increasing indexes. I.e. a_2,2 is stored somewhere after both a_1,2 and a_2,1, and all the strides are positive.

and these are not contiguous:

* memoryview(contiguous)[::2], because there are memory gaps between the items
* memoryview(contiguous)[::-1], despite there being no gaps nor overlapping items
* Views that set the ?suboffsets? field (i.e. include pointers to further memory)
* Views where different array items overlap each other (e.g. 0 in view.strides)

Perhaps the bytes-like definition should tightened further, to match the above error message, to only ?C-contiguous? buffers. I understand that C-contiguous means the strides tuple has to be in non-strict decreasing order, e.g. for 2 ? 1 ? 3 arrays, strides == (3, 3, 1) is C-contiguous, but strides == (1, 3, 3) is not. This also needs documenting.

I?m not so sure about these, but the definition could be tightened even further:

* Require memoryview(x).cast("B") to be supported. Otherwise, native Python code would have to use workarounds like struct.pack_into() to write to the ?bytes-like? object. See Issue 15944.
* Require len(view) == view.nbytes. This would help in some cases avoid the bug that I have seen of code naively calling len(data), but the downside is ctypes objects would no longer be considered bytes-like objects.

----------
assignee: docs at python
components: Documentation
messages: 239097
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: Tighten definition of bytes-like objects

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23756>
_______________________________________

From report at bugs.python.org  Tue Mar 24 09:42:29 2015
From: report at bugs.python.org (David MacIver)
Date: Tue, 24 Mar 2015 08:42:29 +0000
Subject: [issue23757] tuple function gives wrong answer when called on list
 subclass with custom __iter__
Message-ID: <1427186549.72.0.114773126362.issue23757@psf.upfronthosting.co.za>


New submission from David MacIver:

Converting a list to a tuple appears to have an optimisation that is wrong in the presence of subclassing to override __iter__. It ignores the user defined iter and uses the normal list one. I've attached a file with a test case to demonstrate this.

I've verified this on both python 2.7 and python 3.4. It's presumably also the case on everything in between.

This was found because it caused a bug with a type that pytz uses, which lazily populates the list on iteration: https://bugs.launchpad.net/pytz/+bug/1435617

----------
components: Library (Lib)
files: listwithiter.py
messages: 239098
nosy: David MacIver
priority: normal
severity: normal
status: open
title: tuple function gives wrong answer when called on list subclass with custom __iter__
versions: Python 2.7, Python 3.4
Added file: http://bugs.python.org/file38663/listwithiter.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23757>
_______________________________________

From report at bugs.python.org  Tue Mar 24 09:52:16 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 08:52:16 +0000
Subject: [issue14562] urllib2 maybe blocks too long with small chunks
In-Reply-To: <1334233390.52.0.591380103695.issue14562@psf.upfronthosting.co.za>
Message-ID: <1427187136.69.0.302082888976.issue14562@psf.upfronthosting.co.za>


Martin Panter added the comment:

I can reproduce this with Python 2, but not with current Python 3, nor with v3.3.3. Probably doesn?t affect 3.2 either, but I haven?t tried.

----------
nosy: +vadmium
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14562>
_______________________________________

From report at bugs.python.org  Tue Mar 24 09:53:56 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 24 Mar 2015 08:53:56 +0000
Subject: [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427187236.67.0.466502561567.issue23756@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23756>
_______________________________________

From report at bugs.python.org  Tue Mar 24 10:03:52 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 09:03:52 +0000
Subject: [issue17301] An in-place version of many bytearray methods is needed
In-Reply-To: <1361910523.06.0.491264384267.issue17301@psf.upfronthosting.co.za>
Message-ID: <1427187832.76.0.26130898063.issue17301@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17301>
_______________________________________

From report at bugs.python.org  Tue Mar 24 10:10:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 09:10:41 +0000
Subject: [issue19023] ctypes docs: Unimplemented and undocumented features
In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>
Message-ID: <1427188241.52.0.366866280745.issue19023@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19023>
_______________________________________

From report at bugs.python.org  Tue Mar 24 10:14:10 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Mar 2015 09:14:10 +0000
Subject: [issue22623] Port Python to 3DS: micro kernel, homebrew,
 newlib (Missing guards for some POSIX functions)
In-Reply-To: <1413204243.21.0.451981347417.issue22623@psf.upfronthosting.co.za>
Message-ID: <1427188450.66.0.377505939391.issue22623@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Missing guards for some POSIX functions -> Port Python to 3DS: micro kernel, homebrew, newlib (Missing guards for some POSIX functions)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22623>
_______________________________________

From report at bugs.python.org  Tue Mar 24 10:15:16 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Mar 2015 09:15:16 +0000
Subject: [issue22623] Port Python to 3DS: micro kernel, homebrew,
 newlib (Missing guards for some POSIX functions)
In-Reply-To: <1413204243.21.0.451981347417.issue22623@psf.upfronthosting.co.za>
Message-ID: <1427188516.26.0.581133220204.issue22623@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> My target platforms have been the Newlib-based Wii and 3DS homebrew toolchains, which emulate a POSIX system on top of the raw hardware (or in the case of the 3DS, a proprietary micro-kernel.

What do you think of my idea of maintaining a fork of the Python repository to store your patches, and rebase them sometimes?

Would it be an acceptable solution?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22623>
_______________________________________

From report at bugs.python.org  Tue Mar 24 10:20:16 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 09:20:16 +0000
Subject: [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427188816.9.0.00381696535261.issue23756@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Totally agree. Current definition is too wide. Actually in different places the term "bytes-like object" can imply different requirements.

* Supports buffer protocol. list isn't.

* Contiguous. memoryview()[::2] isn't.

* len() returns bytes size. array('I') isn't.

* Supported indexing (and slicing) of bytes. array('I') isn't.

* Indexing returns integers in the range 0-255. array('b') isn't.

* Supports concatenation. memoryview isn't.

* Supports common bytes and bytearray methods, such as find() or lower().

* A subclass of (bytes, bytearray).

* A subclass of bytes.

* A bytes itself.

----------
nosy: +r.david.murray, serhiy.storchaka
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23756>
_______________________________________

From report at bugs.python.org  Tue Mar 24 10:20:26 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 24 Mar 2015 09:20:26 +0000
Subject: [issue22623] Port Python to 3DS: micro kernel, homebrew,
 newlib (Missing guards for some POSIX functions)
In-Reply-To: <1413204243.21.0.451981347417.issue22623@psf.upfronthosting.co.za>
Message-ID: <1427188826.65.0.297315652341.issue22623@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22623>
_______________________________________

From report at bugs.python.org  Tue Mar 24 10:29:42 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Mar 2015 09:29:42 +0000
Subject: [issue23753] Drop HAVE_FSTAT: require fstat() to compile/use Python
In-Reply-To: <1427130999.93.0.226588178703.issue23753@psf.upfronthosting.co.za>
Message-ID: <1427189382.88.0.417448572556.issue23753@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Antoine and Charles-Fran?ois are in favor of removing these #ifdef.

Serhiy wrote:
> See issue22623 for moving in opposite direction.

Not exactly, Link Mauve wrote "On those two platforms, fstat() is correctly defined and works fine, so it shouldn?t be a problem to drop its #ifdef."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23753>
_______________________________________

From report at bugs.python.org  Tue Mar 24 10:29:52 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 09:29:52 +0000
Subject: [issue23753] Drop HAVE_FSTAT: require fstat() to compile/use Python
In-Reply-To: <1427130999.93.0.226588178703.issue23753@psf.upfronthosting.co.za>
Message-ID: <20150324092949.24252.34292@psf.io>


Roundup Robot added the comment:

New changeset a84eae63b4cd by Victor Stinner in branch 'default':
Issue #23753: Python doesn't support anymore platforms without stat() or
https://hg.python.org/cpython/rev/a84eae63b4cd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23753>
_______________________________________

From report at bugs.python.org  Tue Mar 24 10:44:55 2015
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Tue, 24 Mar 2015 09:44:55 +0000
Subject: [issue23758] Improve documenation about num_params in sqlite3
 create_function and create_aggregate
Message-ID: <1427190295.06.0.0583773654336.issue23758@psf.upfronthosting.co.za>


New submission from C?dric Krier:

num_params must have the value -1 for any number of arguments see https://www.sqlite.org/c3ref/create_function.html

----------
assignee: docs at python
components: Documentation
files: sqlite3_doc.patch
keywords: patch
messages: 239104
nosy: ced, docs at python
priority: normal
severity: normal
status: open
title: Improve documenation about num_params in sqlite3 create_function and create_aggregate
type: enhancement
Added file: http://bugs.python.org/file38664/sqlite3_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23758>
_______________________________________

From report at bugs.python.org  Tue Mar 24 11:12:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 10:12:50 +0000
Subject: [issue23753] Drop HAVE_FSTAT: require fstat() to compile/use Python
In-Reply-To: <1427130999.93.0.226588178703.issue23753@psf.upfronthosting.co.za>
Message-ID: <1427191970.92.0.557792302199.issue23753@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> -#if defined(HAVE_STAT) && !defined(MS_WINDOWS)

This doesn't look correct. An equivalent replacement is 

-#if defined(HAVE_STAT) && !defined(MS_WINDOWS)
+#if !defined(MS_WINDOWS)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23753>
_______________________________________

From report at bugs.python.org  Tue Mar 24 11:45:14 2015
From: report at bugs.python.org (chrysn)
Date: Tue, 24 Mar 2015 10:45:14 +0000
Subject: [issue23759] urllib.parse: make coap:// known
Message-ID: <1427193914.26.0.435634285689.issue23759@psf.upfronthosting.co.za>


New submission from chrysn:

The CoAP protocol (RFC 7252) registers the new URI schemes coap and coaps. They adhere to the generic RFC3986 rules, and use netloc and relative URIs.

Therefore, please add the 'coap' and 'coaps' schemes to the uses_relative and uses_netloc lists in urllib.parse.

I'm not sure about uses_params; the CoAP protocol in itself does not do anything special with the ';' character in URIs, so probably it should not be included there. (But then again, neither does RFC2616 mention ";" in the context of addresses, and it is included in uses_params).

----------
components: Library (Lib)
messages: 239106
nosy: chrysn
priority: normal
severity: normal
status: open
title: urllib.parse: make coap:// known
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23759>
_______________________________________

From report at bugs.python.org  Tue Mar 24 11:47:56 2015
From: report at bugs.python.org (Victor Korolkevich)
Date: Tue, 24 Mar 2015 10:47:56 +0000
Subject: [issue23760] Tkinter in Python 3.4 on Windows don't post internal
 clipboard data to the Windows clipboard on exit
Message-ID: <1427194076.59.0.225721138053.issue23760@psf.upfronthosting.co.za>


New submission from Victor Korolkevich:

>From http://stackoverflow.com/questions/26321333/tkinter-in-python-3-4-on-windows-dont-post-internal-clipboard-data-to-the-windo

I use the following code to place result in clipboard.

from tkinter import Tk
r = Tk()
r.withdraw()
r.clipboard_clear()
r.clipboard_append("Result")

It works fine on Python version 3.3.5 and earlier. But in Python 3.4 it was receive empty clipboard. If I prevent the script from the immediate exit, adding input() after clipboard_append(), I see that clipboard contains the correct "Result".

If I run script, switch to any other window and press Ctrl+V, I receive "Result" and "Result" remains in clipboard after script exits.

I think in tcl/tk 8.6 clipboard_clear() affect system clipboard, but clipboard_append affect only internal tcl/tk clipboard that transfered to system clipboard only by OS request. Looks like it was done in Linux, that don't have system clipboard.

----------
components: Tkinter
messages: 239107
nosy: Victor Korolkevich
priority: normal
severity: normal
status: open
title: Tkinter in Python 3.4 on Windows don't post internal clipboard data to the Windows clipboard on exit
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23760>
_______________________________________

From report at bugs.python.org  Tue Mar 24 11:52:52 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 10:52:52 +0000
Subject: [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <20150324105248.63570.70295@psf.io>


Roundup Robot added the comment:

New changeset 4a2a5fddbab3 by Ezio Melotti in branch '2.7':
#11468: improve unittest basic example.  Initial patch by Florian Preinstorfer.
https://hg.python.org/cpython/rev/4a2a5fddbab3

New changeset 010e33b37feb by Ezio Melotti in branch '3.4':
#11468: improve unittest basic example.  Initial patch by Florian Preinstorfer.
https://hg.python.org/cpython/rev/010e33b37feb

New changeset d6791e4026f1 by Ezio Melotti in branch 'default':
#11468: merge with 3.4.
https://hg.python.org/cpython/rev/d6791e4026f1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11468>
_______________________________________

From report at bugs.python.org  Tue Mar 24 11:53:35 2015
From: report at bugs.python.org (Victor Korolkevich)
Date: Tue, 24 Mar 2015 10:53:35 +0000
Subject: [issue23760] Tkinter in Python 3.4 on Windows don't post internal
 clipboard data to the Windows clipboard on exit
In-Reply-To: <1427194076.59.0.225721138053.issue23760@psf.upfronthosting.co.za>
Message-ID: <1427194415.75.0.604902365193.issue23760@psf.upfronthosting.co.za>


Changes by Victor Korolkevich <victor.korolkevich at gmail.com>:


----------
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23760>
_______________________________________

From report at bugs.python.org  Tue Mar 24 11:55:55 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 24 Mar 2015 10:55:55 +0000
Subject: [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <1427194555.4.0.672720674377.issue11468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I tweaked the wording a bit, added a link to the section about setUp/tearDown, and applied it on all the 3 branches.
Thanks for the patch Florian!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11468>
_______________________________________

From report at bugs.python.org  Tue Mar 24 12:10:35 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 11:10:35 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <20150324111032.63588.46096@psf.io>


Roundup Robot added the comment:

New changeset efb2c9ac2f88 by Victor Stinner in branch '3.4':
Issue #23571: Enhance Py_FatalError()
https://hg.python.org/cpython/rev/efb2c9ac2f88

New changeset 6303795f035a by Victor Stinner in branch 'default':
(Merge 3.4) Issue #23571: Enhance Py_FatalError()
https://hg.python.org/cpython/rev/6303795f035a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Tue Mar 24 12:19:30 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 11:19:30 +0000
Subject: [issue23753] Drop HAVE_FSTAT: require fstat() to compile/use Python
In-Reply-To: <1427130999.93.0.226588178703.issue23753@psf.upfronthosting.co.za>
Message-ID: <20150324111927.7245.99751@psf.io>


Roundup Robot added the comment:

New changeset ad5521dd7b80 by Victor Stinner in branch 'default':
Issue #23753: Move _Py_wstat() from Python/fileutils.c to Modules/getpath.c
https://hg.python.org/cpython/rev/ad5521dd7b80

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23753>
_______________________________________

From report at bugs.python.org  Tue Mar 24 12:23:35 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Mar 2015 11:23:35 +0000
Subject: [issue23753] Drop HAVE_FSTAT: require fstat() to compile/use Python
In-Reply-To: <1427130999.93.0.226588178703.issue23753@psf.upfronthosting.co.za>
Message-ID: <1427196215.42.0.543109063354.issue23753@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> -#if defined(HAVE_STAT) && !defined(MS_WINDOWS)
> This doesn't look correct. An equivalent replacement is 

Oh, I missed the "!". Only _Py_wstat() uses this test. Windows has _wstat(), so _Py_wstat() could use it.

I added deliberately "!defined(MS_WINDOWS)" because _Py_wstat() is only used in Modules/getpath.c and this file is not compiled on Windows.

Instead of modifying _Py_wstat(), I moved it back to Modules/getpath.c. There is no need to overengineer this function only called 3 times in getpath.c.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23753>
_______________________________________

From report at bugs.python.org  Tue Mar 24 12:41:35 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 11:41:35 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <20150324114132.114142.80525@psf.io>


Roundup Robot added the comment:

New changeset 2e14ca478a57 by Victor Stinner in branch 'default':
Issue #23571: PyErr_FormatV() and PyErr_SetObject() now always clear the
https://hg.python.org/cpython/rev/2e14ca478a57

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Tue Mar 24 12:45:31 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 11:45:31 +0000
Subject: [issue23512] The list of built-in functions is not alphabetical on
 https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <20150324114528.7247.33192@psf.io>


Roundup Robot added the comment:

New changeset 971d299d2cf3 by Ezio Melotti in branch '2.7':
#23512: list non-essential built-in functions after the table.  Patch by Carlo Beccarini.
https://hg.python.org/cpython/rev/971d299d2cf3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23512>
_______________________________________

From report at bugs.python.org  Tue Mar 24 12:47:23 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 24 Mar 2015 11:47:23 +0000
Subject: [issue23512] The list of built-in functions is not alphabetical on
 https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1427197643.73.0.647003668383.issue23512@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23512>
_______________________________________

From report at bugs.python.org  Tue Mar 24 12:58:08 2015
From: report at bugs.python.org (Tim Graham)
Date: Tue, 24 Mar 2015 11:58:08 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1427198288.57.0.182923778517.issue23571@psf.upfronthosting.co.za>


Tim Graham added the comment:

That last commit fixed compatibility with Django.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Tue Mar 24 13:02:31 2015
From: report at bugs.python.org (Bob)
Date: Tue, 24 Mar 2015 12:02:31 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <1427198551.95.0.018883780085.issue20160@psf.upfronthosting.co.za>


Bob added the comment:

I was looking into http://lists.cs.uiuc.edu/pipermail/llvmbugs/2012-September/025152.html 'Use of libclang python bindings on Windows 7 64 bit fails with memory access violation'

It appears to be 90% fixed with this patch, but I believe there is still a problem when structs are passed back though a callback function.

Could this be the correct addition to fix it?
in ffi_prep_incoming_args_SYSV() _ctypes\libffi_msvc\ffi.c(line 377)

      /* because we're little endian, this is what it turns into.   */

+#if _WIN64
+      if ((*p_arg)->type == FFI_TYPE_STRUCT && z > 8)
+          {
+          z = 8;
+          *p_argv = *(void**)argp;
+          }
+      else
+          {
+          *p_argv = (void*)argp;
+          }
+#else
      *p_argv = (void*)argp;
+#endif

----------
nosy: +Bob

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20160>
_______________________________________

From report at bugs.python.org  Tue Mar 24 13:06:38 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 24 Mar 2015 12:06:38 +0000
Subject: [issue21511] Thinko in Lib/quopri.py, decoding b"==" to b"="
In-Reply-To: <1400171855.37.0.067918723363.issue21511@psf.upfronthosting.co.za>
Message-ID: <1427198798.44.0.163425584845.issue21511@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21511>
_______________________________________

From report at bugs.python.org  Tue Mar 24 14:07:25 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 13:07:25 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <20150324130721.70036.42692@psf.io>


Roundup Robot added the comment:

New changeset 850b9dcd0534 by Victor Stinner in branch 'default':
Issue #23571: In debug mode, _Py_CheckFunctionResult() now calls
https://hg.python.org/cpython/rev/850b9dcd0534

New changeset da252f12352a by Victor Stinner in branch '3.4':
Issue #23571: Py_FatalError() now tries to flush sys.stdout and sys.stderr
https://hg.python.org/cpython/rev/da252f12352a

New changeset c9bcf669d807 by Victor Stinner in branch 'default':
(Merge 3.4) Issue #23571: Py_FatalError() now tries to flush sys.stdout and
https://hg.python.org/cpython/rev/c9bcf669d807

New changeset 57550e1f57d9 by Victor Stinner in branch 'default':
Issue #23571: Update test_capi
https://hg.python.org/cpython/rev/57550e1f57d9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Tue Mar 24 14:18:37 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 13:18:37 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
 "chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1427203117.33.0.00237083789501.issue12319@psf.upfronthosting.co.za>


Martin Panter added the comment:

I left a few comments on Reitveld, mainly about the documentation and API design.

However I understand Rolf specifically wanted chunked encoding to work with the existing urlopen() framework, at least after constructing a separate opener object. I think that should be practical with the existing HTTPConnection implementation. Here is some pseudocode of how I might write a urlopen() handler class, and an encoder class that should be usable for both clients and servers:

class ChunkedHandler(...):
    def http_request(...):
        # Like AbstractHTTPHandler, but don?t force Content-Length
    
    def default_open(...):
        # Like AbstractHTTPHandler, but instead of calling h.request():
        encoder = ChunkedEncoder(h.send)
        h.putrequest(req.get_method(), req.selector)
        for item in headers:
            h.putheader(*item)
        h.putheader("Transfer-Encoding", encoder.encoding)
        h.endheaders()
        shutil.copyfileobj(req.data, writer)
        encoder.close()

class ChunkedEncoder(io.BufferedIOBase):
    # Hook output() up to either http.client.HTTPConnection.send()
    # or http.server.BaseHTTPRequestHandler.wfile.write()
    
    encoding = "chunked"
    
    def write(self, b):
        self.output("{:X}\r\n".format(len(b)).encode("ascii"))
        self.output(b)
        self.output(b"\r\n")
    
    def close(self):
        self.output(b"0\r\n\r\n")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12319>
_______________________________________

From report at bugs.python.org  Tue Mar 24 14:21:41 2015
From: report at bugs.python.org (Carol Willing)
Date: Tue, 24 Mar 2015 13:21:41 +0000
Subject: [issue23761] test_socket fails on Mac OSX 10.9.5
Message-ID: <1427203301.62.0.862934673257.issue23761@psf.upfronthosting.co.za>


New submission from Carol Willing:

On Mac OSX 10.9.5, test_socket fails when regression tests are run.


Specifically, the following fails:

FAIL: test_host_resolution (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/carol/Development/cpython/Lib/test/test_socket.py", line 788, in test_host_resolution
    self.assertRaises(OSError, socket.gethostbyname, addr)
AssertionError: OSError not raised by gethostbyname


The output from

    ./python.exe -m test -v test_socket > output-test-socket.txt

is attached.

----------
components: Tests
files: output-test-socket.txt
messages: 239120
nosy: willingc
priority: normal
severity: normal
status: open
title: test_socket fails on Mac OSX 10.9.5
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file38665/output-test-socket.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23761>
_______________________________________

From report at bugs.python.org  Tue Mar 24 14:29:08 2015
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 24 Mar 2015 13:29:08 +0000
Subject: [issue15945] memoryview + bytes fails
In-Reply-To: <1347704879.16.0.744568990947.issue15945@psf.upfronthosting.co.za>
Message-ID: <1427203748.71.0.0237228473955.issue15945@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <jean-paul at clusterhq.com>:


----------
nosy:  -exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15945>
_______________________________________

From report at bugs.python.org  Tue Mar 24 14:58:53 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 13:58:53 +0000
Subject: [issue23759] urllib.parse: make coap:// known
In-Reply-To: <1427193914.26.0.435634285689.issue23759@psf.upfronthosting.co.za>
Message-ID: <1427205533.14.0.725509077733.issue23759@psf.upfronthosting.co.za>


Martin Panter added the comment:

I would like to see these hard-coded white lists of URL schemes eliminated as much as possible. Here?s some related issues:

* Issue 16134: rtmp, rtmpe, rtmps, rtmpt
* Issue 18828: redis, also proposing to urljoin() arbitrary schemes
* Issue 15009: yelp
* Issue 22852: Proposing that urlunsplit() and urlunparse() restore empty netloc, query, and fragment components properly for arbitary schemes
* Issue 23636: scgi

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23759>
_______________________________________

From report at bugs.python.org  Tue Mar 24 15:01:48 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 14:01:48 +0000
Subject: [issue23760] Tkinter in Python 3.4 on Windows don't post internal
 clipboard data to the Windows clipboard on exit
In-Reply-To: <1427194076.59.0.225721138053.issue23760@psf.upfronthosting.co.za>
Message-ID: <1427205708.26.0.942996522177.issue23760@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23760>
_______________________________________

From report at bugs.python.org  Tue Mar 24 15:04:26 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 14:04:26 +0000
Subject: [issue23743] Python crashes upon exit if importing g++ compiled mod
 after importing gcc compiled mod
In-Reply-To: <1427087434.95.0.234111642557.issue23743@psf.upfronthosting.co.za>
Message-ID: <1427205866.64.0.978779122496.issue23743@psf.upfronthosting.co.za>


R. David Murray added the comment:

Oh, I'm afraid it can still be ignored :).  What filing it here means is that it won't be *forgotten*, and hopefully there will eventually be someone with the time and interest to address it.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23743>
_______________________________________

From report at bugs.python.org  Tue Mar 24 15:10:13 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 14:10:13 +0000
Subject: [issue23647] imaplib.py MAXLINE value is too low for gmail
In-Reply-To: <1426174765.08.0.908432771269.issue23647@psf.upfronthosting.co.za>
Message-ID: <1427206213.21.0.534885740201.issue23647@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, I agree that that is a concern.  What should probably happen is that the maximum line length be a settable parameter with a "reasonable" default.  It is too bad that (unlike say the SMTP protocol) the imap protocol does not address this directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23647>
_______________________________________

From report at bugs.python.org  Tue Mar 24 15:16:13 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 24 Mar 2015 14:16:13 +0000
Subject: [issue23703] urljoin() with no directory segments duplicates filename
In-Reply-To: <1426748956.21.0.814756519005.issue23703@psf.upfronthosting.co.za>
Message-ID: <1427206573.24.0.0639809447735.issue23703@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23703>
_______________________________________

From report at bugs.python.org  Tue Mar 24 15:18:06 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 14:18:06 +0000
Subject: [issue23747] platform module exposes win32_ver function on posix
 systems
In-Reply-To: <1427103016.81.0.503768282249.issue23747@psf.upfronthosting.co.za>
Message-ID: <1427206686.43.0.709973842478.issue23747@psf.upfronthosting.co.za>


R. David Murray added the comment:

It is a deliberate choice because (I'm guessing) the designer thought it would make it easier to write cross platform scripts.  In any case, as Haypo said, it is what it is (and it *is* consistent with itself).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23747>
_______________________________________

From report at bugs.python.org  Tue Mar 24 15:18:39 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 24 Mar 2015 14:18:39 +0000
Subject: [issue18828] urljoin behaves differently with custom and standard
 schemas
In-Reply-To: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za>
Message-ID: <1427206719.82.0.958461297173.issue18828@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> Yet another option, similar to my ?any_scheme=True? flag, might be to change from the ?uses_relative? white-list to a ?not_relative? black-list of URL schemes, [...]

I think this looks like a good solution.

----------
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18828>
_______________________________________

From report at bugs.python.org  Tue Mar 24 15:26:24 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 14:26:24 +0000
Subject: [issue23747] platform module exposes win32_ver function on posix
 systems
In-Reply-To: <1427103016.81.0.503768282249.issue23747@psf.upfronthosting.co.za>
Message-ID: <1427207184.34.0.771170865569.issue23747@psf.upfronthosting.co.za>


R. David Murray added the comment:

It is a deliberate choice because the functions accept default values to be returned if the actual values cannot be determined, and because it is easier therefore to write cross-platform scripts if the functions do *not* raise an error when called on the "wrong" platform.  There are other functions in the platform module to use to determine which platform you are on.

Agreed that the fact that they work is currently documented only by implication for those familiar with our doc style (that is, there are no "avaiability" tags, implying they are available on all platforms).  This should be corrected, probably in an introductory paragraph (which will be overlooked by most people reading the docs :)

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23747>
_______________________________________

From report at bugs.python.org  Tue Mar 24 15:26:34 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 14:26:34 +0000
Subject: [issue23747] platform module exposes win32_ver function on posix
 systems
In-Reply-To: <1427103016.81.0.503768282249.issue23747@psf.upfronthosting.co.za>
Message-ID: <1427207194.3.0.428378756657.issue23747@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
Removed message: http://bugs.python.org/msg239124

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23747>
_______________________________________

From report at bugs.python.org  Tue Mar 24 15:28:05 2015
From: report at bugs.python.org (=?utf-8?q?Jo=C3=ABl_Schaerer?=)
Date: Tue, 24 Mar 2015 14:28:05 +0000
Subject: [issue23762] python.org page on new-style classes should be updated
Message-ID: <1427207285.84.0.436806674049.issue23762@psf.upfronthosting.co.za>


New submission from Jo?l Schaerer:

This page (found it via a search engine):

https://www.python.org/doc/newstyle/

is supposed to give the status of "New-style classes". However this information is no longer relevant for Python 3, and my needlessly scare newcomers. I believe it should be either deleted or updated to mention that python3 users don't need to care about this anymore.

----------
assignee: docs at python
components: Documentation
messages: 239127
nosy: docs at python, joelthelion
priority: normal
severity: normal
status: open
title: python.org page on new-style classes should be updated
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23762>
_______________________________________

From report at bugs.python.org  Tue Mar 24 15:29:22 2015
From: report at bugs.python.org (Arnt Gulbrandsen)
Date: Tue, 24 Mar 2015 14:29:22 +0000
Subject: [issue23647] imaplib.py MAXLINE value is too low for gmail
In-Reply-To: <1426174765.08.0.908432771269.issue23647@psf.upfronthosting.co.za>
Message-ID: <1427207362.36.0.306608461156.issue23647@psf.upfronthosting.co.za>


Arnt Gulbrandsen added the comment:

Length limits has actually been discussed and rejected; noone had a proposal that solved more problems than it introduced.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23647>
_______________________________________

From report at bugs.python.org  Tue Mar 24 15:35:29 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 14:35:29 +0000
Subject: [issue23738] Clarify documentation of positional-only default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1427207729.17.0.330686167741.issue23738@psf.upfronthosting.co.za>


R. David Murray added the comment:

That's a good point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23738>
_______________________________________

From report at bugs.python.org  Tue Mar 24 15:41:37 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Mar 2015 14:41:37 +0000
Subject: [issue23763] Chain exceptions in C
Message-ID: <1427208097.93.0.892198283241.issue23763@psf.upfronthosting.co.za>


New submission from STINNER Victor:

In Python 3, it becomes possible to chain two exceptions. It's one of the killer feature of Python 3, it helps debugging.


In Python, exceptions are chained by default. Example:

    try:
        raise TypeError("old message")
    except TypeError:
        raise ValueError("new message")

Output:

    Traceback (most recent call last):
      File "x.py", line 2, in <module>
        raise TypeError("old message")
    TypeError: old message

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "x.py", line 4, in <module>
        raise ValueError("new message")
    ValueError: new message

In C, using the public PyErr_SetNone(), PyErr_Format(), PyErr_SetString(), ... functions, exceptions are *not* chained by default.

You have to call explicitly the new private _PyErr_ChainExceptions() function introduced in Python 3.4. It is not trivial to use it: you have to call PyErr_Fetch() and check if an exception was already raised.


In Python, the following examples are bad practice because they may hide important exceptions like MemoryError or KeyboardInterrupt:

    try:
        ....
    except:
        pass

or

    try:
        ....
    except:
        raise ValueError(...)

In C extensions, it's common to write such code, few functions check which exception was raised.


Last months, I enhanced Python to detect exceptions ignored by mistake: I added assert(!PyErr_Occurred()) in many functions which can clear the current exception (ex: call PyErr_Clear()) or raise a new exception (ex: call PyErr_SetString(...)). The last step is the issue #23571 which now implements in release mode.


For the next step, I propose to explicitly clear the current exception before raising a new exception.


I don't know yet if it would be a good idea to modify PyErr_*() functions to automatically chain exceptions.

----------
messages: 239130
nosy: haypo
priority: normal
severity: normal
status: open
title: Chain exceptions in C

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23763>
_______________________________________

From report at bugs.python.org  Tue Mar 24 15:44:41 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Mar 2015 14:44:41 +0000
Subject: [issue23763] Chain exceptions in C
In-Reply-To: <1427208097.93.0.892198283241.issue23763@psf.upfronthosting.co.za>
Message-ID: <1427208281.77.0.277796110738.issue23763@psf.upfronthosting.co.za>


STINNER Victor added the comment:

pyerr_assert.patch: modify PyErr_SetObject() and PyErr_Format() to fail with an assertion error if these functions are called with an exception set.

This patch detects where an exception is raised while another exception was already raised (like "try: ... except: raise ...").

I'm using this patch to explicitly not chain exceptions where chaining exceptions would be pointless (ex: replace a TypeError with a new TypeError with a better error message).

----------
keywords: +patch
Added file: http://bugs.python.org/file38666/pyerr_assert.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23763>
_______________________________________

From report at bugs.python.org  Tue Mar 24 15:46:38 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Mar 2015 14:46:38 +0000
Subject: [issue23763] Chain exceptions in C
In-Reply-To: <1427208097.93.0.892198283241.issue23763@psf.upfronthosting.co.za>
Message-ID: <1427208398.07.0.296272231355.issue23763@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> For the next step, I propose to explicitly clear the current exception before raising a new exception.

Attached pyerr_match_clear.patch implements this. It's only a work-in-progress. I prefer to get feedback on the patch before finishing it.

The patch checks also which exception was raised using PyErr_ExceptionMatches() to avoid hiding import exceptions.

Since my patch makes assumption on which exception is expected, it can change the behaviour of functions if I forgot a different exception which is also supposed to be replaced. Example: only catch ValueError and replace it with ValueError, whereas OverflowError must also be replaced with ValueError.

----------
Added file: http://bugs.python.org/file38667/pyerr_match_clear.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23763>
_______________________________________

From report at bugs.python.org  Tue Mar 24 15:48:44 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Mar 2015 14:48:44 +0000
Subject: [issue23763] Chain exceptions in C
In-Reply-To: <1427208097.93.0.892198283241.issue23763@psf.upfronthosting.co.za>
Message-ID: <1427208524.49.0.466002808612.issue23763@psf.upfronthosting.co.za>


STINNER Victor added the comment:

pyerr_match_assertion.patch: Modify PyErr_ExceptionMatches() to raise an exception if it is called with no exception set.

This patch can be used to ensure that pyerr_match_clear.patch doesn't introduce regression.

Example:


-    PyErr_Format(PyExc_TypeError,
-                 "expected %s instance instead of %s",
-                 ((PyTypeObject *)type)->tp_name,
-                 Py_TYPE(value)->tp_name);
+
+    if (PyErr_ExceptionMatches(PyExc_AttributeError)) {
+        PyErr_Clear();
+        PyErr_Format(PyExc_TypeError,
+                     "expected %s instance instead of %s",
+                     ((PyTypeObject *)type)->tp_name,
+                     Py_TYPE(value)->tp_name);
+    }

This change is wrong is not exception is set, because PyErr_ExceptionMatches() returns 0 if no exception was raised.

----------
Added file: http://bugs.python.org/file38668/pyerr_match_assertion.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23763>
_______________________________________

From report at bugs.python.org  Tue Mar 24 15:51:12 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Mar 2015 14:51:12 +0000
Subject: [issue23763] Chain exceptions in C
In-Reply-To: <1427208097.93.0.892198283241.issue23763@psf.upfronthosting.co.za>
Message-ID: <1427208672.42.0.643412450661.issue23763@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also issue #21715: "Chaining exceptions at C level". The changeset 9af21752ea2a added the new _PyErr_ChainExceptions() function.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23763>
_______________________________________

From report at bugs.python.org  Tue Mar 24 15:55:31 2015
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Tue, 24 Mar 2015 14:55:31 +0000
Subject: [issue22904] make profile-opt includes -fprofile* flags in
 _sysconfigdata CFLAGS
In-Reply-To: <1416437734.43.0.575909256617.issue22904@psf.upfronthosting.co.za>
Message-ID: <1427208931.68.0.90393736414.issue22904@psf.upfronthosting.co.za>


Bohuslav "Slavek" Kabrda added the comment:

I'm also hitting an issue with test_sysconfig_module, but for a different reason: While building Python, I used "make EXTRA_CFLAGS='some flags'" and this makes test_sysconfig_module fail when I run "make test" or "python -m test.regrtest".

The problem is that EXTRA_CFLAGS, like profile-opt, is not in the Makefile, so _sysconfigdata has it stored from build - unlike distutils, which can't see the EXTRA_CFLAGS variable in the environment, thus resulting in failure.

I'm not sure what's the proper solution here, but I think requiring people to run "make test" with precisely the same EXTRA_CFLAGS as "make" is not right (although it solves the issue). This makes me think this is a bug - should I open a new issue?

----------
nosy: +bkabrda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22904>
_______________________________________

From report at bugs.python.org  Tue Mar 24 16:00:54 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 15:00:54 +0000
Subject: [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427209254.92.0.310026079165.issue23756@psf.upfronthosting.co.za>


R. David Murray added the comment:

This not dissimilar to the problem we have with "file like object" or "file object".  The requirements on them are not consistent.  I'm not sure what the solution is in either case, but for file like objects we have decided to ignore the issue, I think.  (ie: what exactly a file like object needs to support in order to work with a give API depends on that API, and we just live with that).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23756>
_______________________________________

From report at bugs.python.org  Tue Mar 24 16:04:52 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Mar 2015 15:04:52 +0000
Subject: [issue23763] Chain exceptions in C
In-Reply-To: <1427208097.93.0.892198283241.issue23763@psf.upfronthosting.co.za>
Message-ID: <1427209492.53.0.563858025667.issue23763@psf.upfronthosting.co.za>


STINNER Victor added the comment:

While working on the PEP 475, I modified _Py_fopen_obj() to raise the OSError (instead of raising the exception from the call site). The zipimport uses _Py_fopen_obj() but it didn't raise OSError, only ZipImportError. I modified the zipimport module to raise a chained exception: OSError chained to ZipImportError: see issue #23696.

Other functions using _PyErr_ChainExceptions():

- open() (io.open): if open() failed and f.close() raised an exception, chain the two exceptions
- io.FileIO.close
- io.TextIOWrapper.close
- io.BufferedReader.close, io.BufferedWriter.close
- _Py_CheckFunctionResult(), new function introduced in the issue #23571

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23763>
_______________________________________

From report at bugs.python.org  Tue Mar 24 16:06:24 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 15:06:24 +0000
Subject: [issue23757] tuple function gives wrong answer when called on list
 subclass with custom __iter__
In-Reply-To: <1427186549.72.0.114773126362.issue23757@psf.upfronthosting.co.za>
Message-ID: <1427209584.53.0.7845012071.issue23757@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is a specific instance of the general problem covered by issue 10977.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Concrete object C API considered harmful to subclasses of builtin types

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23757>
_______________________________________

From report at bugs.python.org  Tue Mar 24 16:14:41 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 15:14:41 +0000
Subject: [issue23761] test_socket fails on Mac OSX 10.9.5
In-Reply-To: <1427203301.62.0.862934673257.issue23761@psf.upfronthosting.co.za>
Message-ID: <1427210081.17.0.57153051136.issue23761@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is almost certain to be an OSX bug.  Do you want to investigate?

----------
components: +Macintosh -Tests
nosy: +ned.deily, r.david.murray, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23761>
_______________________________________

From report at bugs.python.org  Tue Mar 24 16:17:57 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 24 Mar 2015 15:17:57 +0000
Subject: [issue23761] test_socket fails on Mac OSX 10.9.5
In-Reply-To: <1427203301.62.0.862934673257.issue23761@psf.upfronthosting.co.za>
Message-ID: <1427210277.21.0.535607189874.issue23761@psf.upfronthosting.co.za>


Ned Deily added the comment:

I don't recall ever seeing that failure on OS X systems.  Can you patch the test to find out which address lookup is not failing as expected and then check your host configuration?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23761>
_______________________________________

From report at bugs.python.org  Tue Mar 24 16:17:59 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 15:17:59 +0000
Subject: [issue23759] urllib.parse: make coap:// known
In-Reply-To: <1427193914.26.0.435634285689.issue23759@psf.upfronthosting.co.za>
Message-ID: <1427210279.31.0.527759171783.issue23759@psf.upfronthosting.co.za>


R. David Murray added the comment:

I too would like to see this issue dealt with generically.  I believe the last time we discussed it the barrier was backward compatibility and which RFCs we actually support :(.  Fixing it generically will require a well thought out and well researched proposal.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23759>
_______________________________________

From report at bugs.python.org  Tue Mar 24 16:22:04 2015
From: report at bugs.python.org (chrysn)
Date: Tue, 24 Mar 2015 15:22:04 +0000
Subject: [issue23759] urllib.parse: make coap:// known
In-Reply-To: <1427193914.26.0.435634285689.issue23759@psf.upfronthosting.co.za>
Message-ID: <1427210524.31.0.809372002002.issue23759@psf.upfronthosting.co.za>


chrysn added the comment:

i wholeheartedly agree that a generic solution would be preferable, but as you pointed out, that needs to be well-researched. until there is a concrete plan for that, please don't let the ideal solution get in the way of a practical update of the uri scheme list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23759>
_______________________________________

From report at bugs.python.org  Tue Mar 24 16:28:45 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 15:28:45 +0000
Subject: [issue23761] test_socket fails on Mac OSX 10.9.5
In-Reply-To: <1427203301.62.0.862934673257.issue23761@psf.upfronthosting.co.za>
Message-ID: <1427210925.03.0.609347990869.issue23761@psf.upfronthosting.co.za>


R. David Murray added the comment:

We could/should change that test to use subtests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23761>
_______________________________________

From report at bugs.python.org  Tue Mar 24 16:29:09 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 15:29:09 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <20150324152906.11916.56589@psf.io>


Roundup Robot added the comment:

New changeset 2a18b958f1e1 by Victor Stinner in branch 'default':
Issue #23571: Enhance _Py_CheckFunctionResult()
https://hg.python.org/cpython/rev/2a18b958f1e1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Tue Mar 24 16:38:05 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 15:38:05 +0000
Subject: [issue18473] some objects pickled by Python 3.x are not unpicklable
 in Python 2.x because of incorrect REVERSE_IMPORT_MAPPING
In-Reply-To: <1373973767.04.0.0542870445433.issue18473@psf.upfronthosting.co.za>
Message-ID: <1427211485.23.0.317973852785.issue18473@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch fixes more bugs.

Added support of unicode, izip_longest, abstract collections, ChainMap, multiprocessing exceptions, some socket and multiprocessing functions and types, xml.etree.ElementTree (C implementation). Added support of urllib and urllib2 (only public interface). Fixed reverse mapping of OSError subclasses, str, bz2, different dbm implementations, pickle. Added special sanity tests for _compat_pickle mappings (test that mappings are not ambiguous and mainly reversible, that 3.x names exist, etc).

----------
Added file: http://bugs.python.org/file38669/pickle_fix_import_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18473>
_______________________________________

From report at bugs.python.org  Tue Mar 24 16:53:02 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 24 Mar 2015 15:53:02 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <1427212382.38.0.606783408488.issue20160@psf.upfronthosting.co.za>


Steve Dower added the comment:

It could be, though I admit I don't know ctypes or libffi that well.

Should be easy enough to set up a repro for this (we'll add a function to _ctypes_test eventually that calls back and passes a struct) - I'll get to it sooner or later, but if someone else gets there first that'd be great.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20160>
_______________________________________

From report at bugs.python.org  Tue Mar 24 16:53:54 2015
From: report at bugs.python.org (Dan O'Reilly)
Date: Tue, 24 Mar 2015 15:53:54 +0000
Subject: [issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor
 should accept an initializer argument
In-Reply-To: <1399160288.58.0.274862722075.issue21423@psf.upfronthosting.co.za>
Message-ID: <1427212434.68.0.372084584278.issue21423@psf.upfronthosting.co.za>


Changes by Dan O'Reilly <oreilldf at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21423>
_______________________________________

From report at bugs.python.org  Tue Mar 24 17:03:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 16:03:20 +0000
Subject: [issue4727] copyreg doesn't support keyword only arguments in __new__
In-Reply-To: <1229999703.52.0.11232958698.issue4727@psf.upfronthosting.co.za>
Message-ID: <1427213000.06.0.401934559901.issue4727@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4727>
_______________________________________

From report at bugs.python.org  Tue Mar 24 17:07:25 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 16:07:25 +0000
Subject: [issue20289] Make cgi.FieldStorage a context manager
In-Reply-To: <1389970045.35.0.547540590752.issue20289@psf.upfronthosting.co.za>
Message-ID: <20150324160722.30040.27022@psf.io>


Roundup Robot added the comment:

New changeset 34930a6faf0d by Serhiy Storchaka in branch 'default':
Issue #20289: The copy module now uses pickle protocol 4 (PEP 3154) and
https://hg.python.org/cpython/rev/34930a6faf0d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20289>
_______________________________________

From report at bugs.python.org  Tue Mar 24 17:08:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 16:08:11 +0000
Subject: [issue4727] copyreg doesn't support keyword only arguments in __new__
In-Reply-To: <1229999703.52.0.11232958698.issue4727@psf.upfronthosting.co.za>
Message-ID: <1427213291.73.0.934234668722.issue4727@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4727>
_______________________________________

From report at bugs.python.org  Tue Mar 24 17:17:04 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 24 Mar 2015 16:17:04 +0000
Subject: [issue20984] 'Add/Remove Programs' dialog missing entries for 32-bit
 CPython 'current user only' installations on 64-bit Windows
In-Reply-To: <1395251194.85.0.622620129448.issue20984@psf.upfronthosting.co.za>
Message-ID: <1427213824.97.0.629157455785.issue20984@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Presumably this can be incorporated into the ongoing work on the Windows installer.

----------
nosy: +BreamoreBoy, paul.moore, steve.dower, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20984>
_______________________________________

From report at bugs.python.org  Tue Mar 24 17:19:45 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 16:19:45 +0000
Subject: [issue21717] Exclusive mode for ZipFile and TarFile
In-Reply-To: <1402482380.66.0.687307266587.issue21717@psf.upfronthosting.co.za>
Message-ID: <1427213985.14.0.0719674659813.issue21717@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you look on zipfile patch Berker? It is simpler than tarfile patch.

----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21717>
_______________________________________

From report at bugs.python.org  Tue Mar 24 17:24:37 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 24 Mar 2015 16:24:37 +0000
Subject: [issue20924] openssl init 100% CPU  utilization on Windows
In-Reply-To: <1394807354.77.0.238568366714.issue20924@psf.upfronthosting.co.za>
Message-ID: <1427214277.9.0.160571945693.issue20924@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Is this still considered valid considering from https://www.python.org/downloads/release/python-279/ "The entirety of Python 3.4's ssl module has been backported for Python 2.7.9. See PEP 466 for justification." ?

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20924>
_______________________________________

From report at bugs.python.org  Tue Mar 24 17:25:12 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 24 Mar 2015 16:25:12 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
 "chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1427214312.43.0.323988497883.issue12319@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


Added file: http://bugs.python.org/file38670/issue12319_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12319>
_______________________________________

From report at bugs.python.org  Tue Mar 24 17:26:07 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 24 Mar 2015 16:26:07 +0000
Subject: [issue12319] [http.client] HTTPConnection.putrequest not support
 "chunked" Transfer-Encodings to send data
In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za>
Message-ID: <1427214367.82.0.533979300693.issue12319@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Thanks for the review Martin.

> However I understand Rolf specifically wanted chunked encoding to work with the existing urlopen() framework, at least after constructing a separate opener object. I think that should be practical with the existing HTTPConnection implementation.

The original issue was that http.client doesn't support chunked encoding. With this patch, chunked encoding should more or less come for free with urlopen. There's absolutely no reason as to why HTTPConnection should not support transfer encoding out of the box given it's part of the HTTP1.1 spec. I do understand that there are some modifications needed in urllib.request in order to support the changes here, but I didn't include those in the patch as to not conflate the patch. I think that it's also reasonable to open a new issue to address the feature in urllib.request rather than piggy-backing on this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12319>
_______________________________________

From report at bugs.python.org  Tue Mar 24 17:26:35 2015
From: report at bugs.python.org (David MacIver)
Date: Tue, 24 Mar 2015 16:26:35 +0000
Subject: [issue23757] tuple function gives wrong answer when called on list
 subclass with custom __iter__
In-Reply-To: <1427186549.72.0.114773126362.issue23757@psf.upfronthosting.co.za>
Message-ID: <1427214395.37.0.5647845696.issue23757@psf.upfronthosting.co.za>


David MacIver added the comment:

Ah, I hadn't seen that. Thanks for the link.

But... is it really? They have basically the same root cause, but the general problem seems to be hard to fix, while the specific problem here seems to be basically "don't use the concrete API here because it breaks things".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23757>
_______________________________________

From report at bugs.python.org  Tue Mar 24 17:28:27 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 24 Mar 2015 16:28:27 +0000
Subject: [issue20984] 'Add/Remove Programs' dialog missing entries for 32-bit
 CPython 'current user only' installations on 64-bit Windows
In-Reply-To: <1395251194.85.0.622620129448.issue20984@psf.upfronthosting.co.za>
Message-ID: <1427214507.28.0.902217376517.issue20984@psf.upfronthosting.co.za>


Steve Dower added the comment:

If Martin wants to fix this for 3.4 he's welcome to, but otherwise this issue is out of date for 3.5.

----------
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20984>
_______________________________________

From report at bugs.python.org  Tue Mar 24 17:33:42 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 16:33:42 +0000
Subject: [issue23757] tuple function gives wrong answer when called on list
 subclass with custom __iter__
In-Reply-To: <1427186549.72.0.114773126362.issue23757@psf.upfronthosting.co.za>
Message-ID: <1427214822.48.0.265130841031.issue23757@psf.upfronthosting.co.za>


R. David Murray added the comment:

Right, but unless I miss my guess (I haven't looked at the code) it isn't that the concrete api is being used by the constructor, it's that the concrete API is being used by the iterator protocol called by the constructor.  If I'm wrong it would be sensible to fix the constructor and we can reopen this.  Even if I'm right perhaps there's a way to fix the constructor, but in that case it would be best addressed in the context of that issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23757>
_______________________________________

From report at bugs.python.org  Tue Mar 24 17:34:44 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 24 Mar 2015 16:34:44 +0000
Subject: [issue23759] urllib.parse: make coap:// known
In-Reply-To: <1427193914.26.0.435634285689.issue23759@psf.upfronthosting.co.za>
Message-ID: <1427214884.05.0.111473622005.issue23759@psf.upfronthosting.co.za>


Demian Brecht added the comment:

I'm also +1 to handling this generically and agree that a well thought out and researched proposal would be required.

I did mention in #18228 (http://bugs.python.org/issue18828#msg238363) that I think that a short term solution to this problem could be to simply add documentation around manually adding schemes as required to uses_relative.

----------
nosy: +demian.brecht

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23759>
_______________________________________

From report at bugs.python.org  Tue Mar 24 17:35:56 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 16:35:56 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <20150324163553.7257.10428@psf.io>


Roundup Robot added the comment:

New changeset 7bd87a219813 by Serhiy Storchaka in branch 'default':
Issue #22687: Fixed some corner cases in breaking words in tetxtwrap.
https://hg.python.org/cpython/rev/7bd87a219813

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Tue Mar 24 17:37:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 16:37:23 +0000
Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting
 of integers
In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za>
Message-ID: <1427215043.75.0.741907058264.issue23466@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ethan?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23466>
_______________________________________

From report at bugs.python.org  Tue Mar 24 18:08:20 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 17:08:20 +0000
Subject: [issue23741] Small pprint refactoring
In-Reply-To: <1427059576.13.0.118751604266.issue23741@psf.upfronthosting.co.za>
Message-ID: <20150324170817.24254.88888@psf.io>


Roundup Robot added the comment:

New changeset 522f6aa1f391 by Serhiy Storchaka in branch 'default':
Issue #23741: Slightly refactor the pprint module to make it a little more
https://hg.python.org/cpython/rev/522f6aa1f391

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23741>
_______________________________________

From report at bugs.python.org  Tue Mar 24 18:08:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 17:08:59 +0000
Subject: [issue23741] Small pprint refactoring
In-Reply-To: <1427059576.13.0.118751604266.issue23741@psf.upfronthosting.co.za>
Message-ID: <1427216939.14.0.398614174566.issue23741@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23741>
_______________________________________

From report at bugs.python.org  Tue Mar 24 18:10:21 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 17:10:21 +0000
Subject: [issue17530] pprint could use line continuation for long bytes
 literals
In-Reply-To: <1364067577.46.0.261047534718.issue17530@psf.upfronthosting.co.za>
Message-ID: <1427217021.76.0.724367135188.issue17530@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17530>
_______________________________________

From report at bugs.python.org  Tue Mar 24 18:23:30 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 17:23:30 +0000
Subject: [issue17530] pprint could use line continuation for long bytes
 literals
In-Reply-To: <1364067577.46.0.261047534718.issue17530@psf.upfronthosting.co.za>
Message-ID: <20150324172327.63576.83025@psf.io>


Roundup Robot added the comment:

New changeset 976de10bf731 by Serhiy Storchaka in branch 'default':
Issue #17530: pprint now wraps long bytes objects and bytearrays.
https://hg.python.org/cpython/rev/976de10bf731

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17530>
_______________________________________

From report at bugs.python.org  Tue Mar 24 18:23:48 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 17:23:48 +0000
Subject: [issue17530] pprint could use line continuation for long bytes
 literals
In-Reply-To: <1364067577.46.0.261047534718.issue17530@psf.upfronthosting.co.za>
Message-ID: <1427217828.69.0.15868107617.issue17530@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17530>
_______________________________________

From report at bugs.python.org  Tue Mar 24 18:32:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 17:32:38 +0000
Subject: [issue23502] pprint: added support for mapping proxy
In-Reply-To: <1424719308.61.0.00451137981633.issue23502@psf.upfronthosting.co.za>
Message-ID: <20150324173234.73054.28260@psf.io>


Roundup Robot added the comment:

New changeset 646a7e1da7f0 by Serhiy Storchaka in branch 'default':
Issue #23502: The pprint module now supports mapping proxies.
https://hg.python.org/cpython/rev/646a7e1da7f0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23502>
_______________________________________

From report at bugs.python.org  Tue Mar 24 18:33:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 17:33:09 +0000
Subject: [issue23502] pprint: added support for mapping proxy
In-Reply-To: <1424719308.61.0.00451137981633.issue23502@psf.upfronthosting.co.za>
Message-ID: <1427218389.67.0.731825020913.issue23502@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23502>
_______________________________________

From report at bugs.python.org  Tue Mar 24 18:39:05 2015
From: report at bugs.python.org (David MacIver)
Date: Tue, 24 Mar 2015 17:39:05 +0000
Subject: [issue23757] tuple function gives wrong answer when called on list
 subclass with custom __iter__
In-Reply-To: <1427186549.72.0.114773126362.issue23757@psf.upfronthosting.co.za>
Message-ID: <1427218745.86.0.897659674804.issue23757@psf.upfronthosting.co.za>


David MacIver added the comment:

So as a data point, this problem seems to be unique to tuple. set(x), list(x), tuple(iter(x)) all seem to work as expected and respect the overridden __iter__ (set and list were both included in the test case I attached to demonstrated this, iter I just checked right now). This suggests that the problem is in what tuple is doing, not in some general iterator protocol,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23757>
_______________________________________

From report at bugs.python.org  Tue Mar 24 18:50:45 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 17:50:45 +0000
Subject: [issue23583] IDLE: printing unicode subclasses broken (again)
In-Reply-To: <1425481188.05.0.778183770327.issue23583@psf.upfronthosting.co.za>
Message-ID: <20150324175039.82154.99682@psf.io>


Roundup Robot added the comment:

New changeset cd9e4f73b5ce by Serhiy Storchaka in branch '2.7':
Issue #23583: Fixed writing unicode to standard output stream in IDLE.
https://hg.python.org/cpython/rev/cd9e4f73b5ce

New changeset 0c72cdf3ff22 by Serhiy Storchaka in branch '2.7':
Issue #23583: Fixed writing unicode to standard output stream in IDLE.
https://hg.python.org/cpython/rev/0c72cdf3ff22

New changeset 2c680d7d8ca6 by Serhiy Storchaka in branch '3.4':
Issue #23583: Added tests for standard IO streams in IDLE.
https://hg.python.org/cpython/rev/2c680d7d8ca6

New changeset f860915e5705 by Serhiy Storchaka in branch 'default':
Issue #23583: Added tests for standard IO streams in IDLE.
https://hg.python.org/cpython/rev/f860915e5705

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23583>
_______________________________________

From report at bugs.python.org  Tue Mar 24 19:04:49 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 24 Mar 2015 18:04:49 +0000
Subject: [issue15244] Support for opening files with FILE_SHARE_DELETE on
 Windows
In-Reply-To: <1341342894.98.0.559958462018.issue15244@psf.upfronthosting.co.za>
Message-ID: <1427220289.46.0.69383230999.issue15244@psf.upfronthosting.co.za>


eryksun added the comment:

> you can't mix CRT methods with OS methods because the CRT does its 
> own buffering

Python 3's io uses the CRT's low I/O (ioinfo struct) in binary mode. It appears that the buffers pipech, pipech2, and dbcsbuffer are only used in text mode. So it should be generally OK to call get_osfhandle and use Win32 directly, if that's ever required. 

Of course, as this patch demonstrates, an io opener (3.3+) can call open_osfhandle immediately after CreateFile, and nothing else changes. This could be added to io / _pyio in 3.5. Initially it could simply be a pure-Python function that uses _winapi and msvcrt. 3.6 could get a C implementation in _iomodule.c.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15244>
_______________________________________

From report at bugs.python.org  Tue Mar 24 19:08:17 2015
From: report at bugs.python.org (mattip)
Date: Tue, 24 Mar 2015 18:08:17 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <1427220497.93.0.800497261407.issue20160@psf.upfronthosting.co.za>


mattip added the comment:

"Bob" is relating to a dead issue, the email was from 2012 and this issue was fixed in Nov 2014. His fix is wrong and unnecessary, which he would have discovered had he run the tests that were added with that patch.

This issue was only left open in order to allow someone to resync libffi with the upstream version

In the mean time this is the second time someone has mistakenly related to this issue, so could someone with super powers please close the issue. If needed (a failing test would be nice) then we could open a new issue for "sync libffi with upstream"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20160>
_______________________________________

From report at bugs.python.org  Tue Mar 24 19:14:33 2015
From: report at bugs.python.org (productivememberofsociety666)
Date: Tue, 24 Mar 2015 18:14:33 +0000
Subject: [issue23764] functools.wraps should be able to change function
 argspec as well
Message-ID: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>


New submission from productivememberofsociety666:

functools.wraps currently only changes the wrapped function's "superficial" attributes such as docstring or annotations.

But it would be useful to be able to change the function's actual argspec as well so it matches up with the changed annotations (e.g. to get proper error messages when the wrapped and wrapper functions' argspecs don't match up).

To avoid breaking existing code, this could be achieved by adding another argument change_argspec (defaulting to False) to functools.wraps. Of course, the way functools.wraps is implemented now as well as its current documentation would have to be thrown out of the window in order for this to work (at least for the case of change_argspec==True).


There is an existing 3rd party package ( https://pypi.python.org/pypi/decorator ) which has a decorator called "decorator" that does kind of what I'd want functools.wraps to do, but the details of how it is called are different and either way it's embarassing that you have to fall back on a 3rd party library to get functionality that is present but incomplete in Python's standard library.

----------
components: Library (Lib)
messages: 239165
nosy: productivememberofsociety666
priority: normal
severity: normal
status: open
title: functools.wraps should be able to change function argspec as well
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23764>
_______________________________________

From report at bugs.python.org  Tue Mar 24 19:15:51 2015
From: report at bugs.python.org (SilentGhost)
Date: Tue, 24 Mar 2015 18:15:51 +0000
Subject: [issue23764] functools.wraps should be able to change function
 argspec as well
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427220951.76.0.881039035478.issue23764@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


----------
nosy: +ncoghlan, rhettinger
versions:  -Python 3.2, Python 3.3, Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23764>
_______________________________________

From report at bugs.python.org  Tue Mar 24 19:33:57 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 24 Mar 2015 18:33:57 +0000
Subject: [issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor
 should accept an initializer argument
In-Reply-To: <1399160288.58.0.274862722075.issue21423@psf.upfronthosting.co.za>
Message-ID: <1427222037.47.0.770642394497.issue21423@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> I'm also not sure how useful it would be for ProcessPoolExecutor to receive an instance of itself.

Agreed that this doesn't make much sense; I hadn't really thought about the ProcessPoolExecutor case.  I withdraw my comments!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21423>
_______________________________________

From report at bugs.python.org  Tue Mar 24 19:39:05 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 24 Mar 2015 18:39:05 +0000
Subject: [issue23765] Remove IsBadStringPtr calls in ctypes
Message-ID: <1427222345.86.0.728447674961.issue23765@psf.upfronthosting.co.za>


New submission from Steve Dower:

Modules/_ctypes/cfield.c has this horror in it (twice):

    /* XXX What about invalid pointers ??? */
    if (*(void **)ptr) {
#if defined(MS_WIN32) && !defined(_WIN32_WCE)
        if (IsBadStringPtrA(*(char **)ptr, -1)) {
            PyErr_Format(PyExc_ValueError,
                         "invalid string pointer %p",
                         *(char **)ptr);
            return NULL;
        }
#endif
        return PyBytes_FromStringAndSize(*(char **)ptr,
                                         strlen(*(char **)ptr));

IsBadStringPtr should generally not be used, and the -1 parameter makes it even worse. See http://blogs.msdn.com/b/oldnewthing/archive/2006/09/27/773741.aspx for details, but the main reason is that if it is actually a bad pointer, we've just deferred the crash from the obvious location to somewhere that should "never" crash.

The strlen() call has exactly the same behaviour as IsBadStringPtrA except the crash will occur here.

A better alternative would be to use the safe strlen function to limit the maximum length of strings, but since we likely can't agree on a suitable maximum we should just stop trying to handle this case at all.

----------
assignee: steve.dower
components: Windows, ctypes
messages: 239167
nosy: steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Remove IsBadStringPtr calls in ctypes
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23765>
_______________________________________

From report at bugs.python.org  Tue Mar 24 19:57:57 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 18:57:57 +0000
Subject: [issue23764] functools.wraps should be able to change function
 argspec as well
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427223477.61.0.187955400413.issue23764@psf.upfronthosting.co.za>


R. David Murray added the comment:

See also issue 15731 (this might be effectively a duplicate of that one, I'm not sure).  I believe the idea of incorporating decorator into the stdlib has been brought up in the past.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23764>
_______________________________________

From report at bugs.python.org  Tue Mar 24 20:13:44 2015
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 24 Mar 2015 19:13:44 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1427147484.93.0.501180467581.issue23648@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2tS+ApXBuySMjeFDNF8G2OLg2qF=1ADdUJZYyAuZHkjA@mail.gmail.com>


Charles-Fran?ois Natali added the comment:

> fstat_not_eintr.py: run this script from a NFS share and unplug the network cable, wait, replug. Spoiler: fstat() hangs until the network is back, CTRL+c or setitimer() don't interrupt it.

You have to mount the share with the eintr option.

Getting EINTR on a local FS is probably more challenging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Tue Mar 24 20:41:47 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 24 Mar 2015 19:41:47 +0000
Subject: [issue23712] Experiment: Assume that exact unicode hashes are perfect
 discriminators
In-Reply-To: <1426795062.72.0.102774381262.issue23712@psf.upfronthosting.co.za>
Message-ID: <1427226107.19.0.891600507409.issue23712@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23712>
_______________________________________

From report at bugs.python.org  Tue Mar 24 20:43:43 2015
From: report at bugs.python.org (Pavel Strashkin)
Date: Tue, 24 Mar 2015 19:43:43 +0000
Subject: [issue23766] json.dumps: solidus ("/") should be escaped
Message-ID: <1427226223.82.0.96478521351.issue23766@psf.upfronthosting.co.za>


New submission from Pavel Strashkin:

According to http://www.json.org/ and https://tools.ietf.org/html/rfc7159#section-7, the solidus ("/") should be escaped ("\/") and currently it's not.

----------
messages: 239170
nosy: xaka
priority: normal
severity: normal
status: open
title: json.dumps: solidus ("/") should be escaped
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23766>
_______________________________________

From report at bugs.python.org  Tue Mar 24 20:44:41 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 24 Mar 2015 19:44:41 +0000
Subject: [issue23766] json.dumps: solidus ("/") should be escaped
In-Reply-To: <1427226223.82.0.96478521351.issue23766@psf.upfronthosting.co.za>
Message-ID: <1427226281.99.0.00348875728207.issue23766@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23766>
_______________________________________

From report at bugs.python.org  Tue Mar 24 20:58:17 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 19:58:17 +0000
Subject: [issue23573] Avoid redundant allocations in str.find and like
In-Reply-To: <1425390810.95.0.0960267231917.issue23573@psf.upfronthosting.co.za>
Message-ID: <20150324195814.30052.90188@psf.io>


Roundup Robot added the comment:

New changeset 6db9d7c1be29 by Serhiy Storchaka in branch 'default':
Issue #23573: Increased performance of string search operations (str.find,
https://hg.python.org/cpython/rev/6db9d7c1be29

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23573>
_______________________________________

From report at bugs.python.org  Tue Mar 24 20:59:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 19:59:50 +0000
Subject: [issue23573] Avoid redundant allocations in str.find and like
In-Reply-To: <1425390810.95.0.0960267231917.issue23573@psf.upfronthosting.co.za>
Message-ID: <1427227190.0.0.352694080013.issue23573@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23573>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:01:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 20:01:26 +0000
Subject: [issue13583] sqlite3.Row doesn't support slice indexes
In-Reply-To: <1323639948.36.0.717803065724.issue13583@psf.upfronthosting.co.za>
Message-ID: <1427227286.28.0.741987283026.issue13583@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you look at the patch Gerhard?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13583>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:04:00 2015
From: report at bugs.python.org (Samuel Cabrero)
Date: Tue, 24 Mar 2015 20:04:00 +0000
Subject: [issue23767] Library and include paths not added when cross compiling
 on localized sytem
Message-ID: <1427227440.25.0.884604694697.issue23767@psf.upfronthosting.co.za>


New submission from Samuel Cabrero:

When cross compiling on a localized system (eg. LANG=es_ES.utf8) the add_gcc_paths is called. This function parses the output of "gcc -v -E" and fails because the output is localized which
results in no paths added and detect_modules not able to find
any system library (eg. libz, libssl, etc.)

The attached patch forces the use of the default locale in the function
add_gcc_paths.

----------
components: Cross-Build
files: 0001-Override-system-locale-and-set-to-default-when-addin.patch
keywords: patch
messages: 239173
nosy: kernevil
priority: normal
severity: normal
status: open
title: Library and include paths not added when cross compiling on localized sytem
versions: Python 3.4
Added file: http://bugs.python.org/file38671/0001-Override-system-locale-and-set-to-default-when-addin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23767>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:04:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 20:04:18 +0000
Subject: [issue23583] IDLE: printing unicode subclasses broken (again)
In-Reply-To: <1425481188.05.0.778183770327.issue23583@psf.upfronthosting.co.za>
Message-ID: <1427227458.58.0.882546868802.issue23583@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23583>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:05:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 20:05:11 +0000
Subject: [issue22687] horrible performance of textwrap.wrap() with a long word
In-Reply-To: <1413909926.45.0.828322813526.issue22687@psf.upfronthosting.co.za>
Message-ID: <1427227511.01.0.276285834277.issue22687@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22687>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:06:37 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 20:06:37 +0000
Subject: [issue23671] string.Template doesn't work with the self keyword
 argument
In-Reply-To: <1426407694.34.0.298286807857.issue23671@psf.upfronthosting.co.za>
Message-ID: <1427227597.05.0.503884406969.issue23671@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23671>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:06:48 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 20:06:48 +0000
Subject: [issue23171] csv.writer.writerow() does not accept generator (must be
 coerced to list)
In-Reply-To: <1420479102.66.0.846752030326.issue23171@psf.upfronthosting.co.za>
Message-ID: <1427227608.72.0.0677490803726.issue23171@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23171>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:07:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 20:07:01 +0000
Subject: [issue14904] test_unicode_repr_oflw (in test_bigmem) crashes
In-Reply-To: <1337903212.58.0.439916347295.issue14904@psf.upfronthosting.co.za>
Message-ID: <1427227621.31.0.770505373262.issue14904@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14904>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:07:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 20:07:15 +0000
Subject: [issue23611] Pickle nested names with protocols < 4
In-Reply-To: <1425837040.48.0.408829364916.issue23611@psf.upfronthosting.co.za>
Message-ID: <1427227635.11.0.244679995184.issue23611@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23611>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:11:35 2015
From: report at bugs.python.org (Bob)
Date: Tue, 24 Mar 2015 20:11:35 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <1427227895.61.0.0554956111299.issue20160@psf.upfronthosting.co.za>


Bob added the comment:

ok, forgive me for asking a newbe question ot two, but when you say 'fixed in nov 2014' are you refering to the release mentioned below or something else, possibly something that didn't make it into 2.7.9?  

I dont really understand what 'resync libffi with the upstream version' means, but I assume that if this is done my python-clang issue might be fixed?  So having a test is important, I'll see what I can do.

I'm working with the 2.7.9 release source, because I need a fix that can be dropped into the 2.7.9 official release folder so that people here can use python-clang. The source I have for 2.7.9 does appear to have the release below in it, including the changes to test_win32.py (which still passes with my fix)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20160>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:20:09 2015
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 24 Mar 2015 20:20:09 +0000
Subject: [issue23768] assert on getting the representation of a thread in
 atexit function
Message-ID: <1427228409.82.0.424611775358.issue23768@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

The following 'thread_repr.py' script:
--------------------------------------

import threading, atexit

def foo():
    print(threading.currentThread())

atexit.register(foo)



gives the following output:
---------------------------

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "thread_repr.py", line 4, in foo
    print(threading.currentThread())
  File "/usr/local/lib/python3.5/threading.py", line 826, in __repr__
    self.is_alive() # easy way to get ._is_stopped set when appropriate
  File "/usr/local/lib/python3.5/threading.py", line 1122, in is_alive
    self._wait_for_tstate_lock(False)
  File "/usr/local/lib/python3.5/threading.py", line 1078, in _wait_for_tstate_lock
    assert self._is_stopped
AssertionError

----------
components: Library (Lib)
messages: 239175
nosy: xdegaye
priority: normal
severity: normal
status: open
title: assert on getting the representation of a thread in atexit function
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23768>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:28:27 2015
From: report at bugs.python.org (Tim Golden)
Date: Tue, 24 Mar 2015 20:28:27 +0000
Subject: [issue23765] Remove IsBadStringPtr calls in ctypes
In-Reply-To: <1427222345.86.0.728447674961.issue23765@psf.upfronthosting.co.za>
Message-ID: <5511C8C0.3050808@timgolden.me.uk>


Tim Golden added the comment:

Unless someone comes back who remembers what the ulterior motive was: I 
agree; remove the check and just the crash happen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23765>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:31:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 20:31:58 +0000
Subject: [issue23671] string.Template doesn't work with the self keyword
 argument
In-Reply-To: <1426407694.34.0.298286807857.issue23671@psf.upfronthosting.co.za>
Message-ID: <20150324203155.30728.8268@psf.io>


Roundup Robot added the comment:

New changeset 1c19778123a3 by Serhiy Storchaka in branch '2.7':
Issue #23671: string.Template now allows to specify the "self" parameter as
https://hg.python.org/cpython/rev/1c19778123a3

New changeset 7a4b499c4dc0 by Serhiy Storchaka in branch '3.4':
Issue #23671: string.Template now allows to specify the "self" parameter as
https://hg.python.org/cpython/rev/7a4b499c4dc0

New changeset 0dd263949e41 by Serhiy Storchaka in branch 'default':
Issue #23671: string.Template now allows to specify the "self" parameter as
https://hg.python.org/cpython/rev/0dd263949e41

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23671>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:33:12 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 20:33:12 +0000
Subject: [issue23671] string.Template doesn't work with the self keyword
 argument
In-Reply-To: <1426407694.34.0.298286807857.issue23671@psf.upfronthosting.co.za>
Message-ID: <1427229192.83.0.899623921754.issue23671@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23671>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:37:53 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 20:37:53 +0000
Subject: [issue4727] copyreg doesn't support keyword only arguments in __new__
In-Reply-To: <1229999703.52.0.11232958698.issue4727@psf.upfronthosting.co.za>
Message-ID: <20150324203747.120054.78392@psf.io>


Roundup Robot added the comment:

New changeset 83cbf61a972b by Serhiy Storchaka in branch 'default':
Issue #4727: Fixed issue number in Misc/NEWS.
https://hg.python.org/cpython/rev/83cbf61a972b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4727>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:38:48 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 20:38:48 +0000
Subject: [issue4727] copyreg doesn't support keyword only arguments in __new__
In-Reply-To: <1229999703.52.0.11232958698.issue4727@psf.upfronthosting.co.za>
Message-ID: <1427229528.85.0.0653529572422.issue4727@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch actually was committed in changeset 34930a6faf0d.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4727>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:49:03 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 20:49:03 +0000
Subject: [issue23637] Warnings error with non-ascii chars.
In-Reply-To: <1426062904.63.0.0951614232281.issue23637@psf.upfronthosting.co.za>
Message-ID: <1427230143.14.0.201199392144.issue23637@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23637>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:55:44 2015
From: report at bugs.python.org (mattip)
Date: Tue, 24 Mar 2015 20:55:44 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <1427230544.28.0.19062230518.issue20160@psf.upfronthosting.co.za>


mattip added the comment:

This is the workflow for developing a patch for python
https://docs.python.org/devguide
This is the workflow for adding a patch to an issue
https://docs.python.org/devguide/patch.html

If there is an issue with python, please demonstrate it in a way that we can follow, and when you submit a patch please upload it in a way that we can see what version of the original file you are changing.

libffi is a library used in python to allow foreign function interfaces in python. It lives here https://github.com/atgreen/libffi The code from libffi was imported into python at version 3.1, (Modules/_ctypes/libffi) but since the official compiler used for windows is msvc, a forked version of libffi, called libffi_msvc lives in parallel to the official libffi in the python source tree. Clang should be using the libffi code or a libffi provided with clang, not the libffi_msvc version since it is specific for msvc. If the libffi inside python is faulty, someone should create an issue to import a newer version from the "upstream" source at https://github.com/atgreen/libffi

In addition, you reference an email from 2012, but now relate to an issue with python 2.7.9 which was released much after that date. What is the problem you see, how does it manifest itself? You should create a separate issue for that behaviour

This issue here was specifically for using libffi with the microsoft compiler to support ctypes, and was fixed for the 2.7.9 release. A test was added in the general ctypes test directory to make sure small and large structures are correctly handled in ctypes. While the test is in a file named win32, the test is run on all platforms, thus exposing a problem with aarch64 on redhat systems in Jan 2015. Their issue was that the libffi in python, and the one used on their platform, had an issue with aarch64. But the upstream libffi does support aarch64, so again, this issue is not the place to report that failure.

In summary, f there is a problem using clang with libffi, perhaps open a new issue that clearly shows how clang+libffi+python fail to do something, it may be enough to simply not use the msvc version of libffi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20160>
_______________________________________

From report at bugs.python.org  Tue Mar 24 21:59:00 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 20:59:00 +0000
Subject: [issue23622] Deprecate unrecognized backslash+letter escapes in re
In-Reply-To: <1425907707.07.0.452600036872.issue23622@psf.upfronthosting.co.za>
Message-ID: <20150324205855.7505.62903@psf.io>


Roundup Robot added the comment:

New changeset 014031a4d398 by Serhiy Storchaka in branch 'default':
Issue #23622: Unknown escapes in regular expressions that consist of ``'\'``
https://hg.python.org/cpython/rev/014031a4d398

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23622>
_______________________________________

From report at bugs.python.org  Tue Mar 24 22:01:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 21:01:59 +0000
Subject: [issue21802] Reader of BufferedRWPair is not closed if writer's
 close() fails
In-Reply-To: <1403113942.14.0.852744973704.issue21802@psf.upfronthosting.co.za>
Message-ID: <1427230919.32.0.0729711192114.issue21802@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21802>
_______________________________________

From report at bugs.python.org  Tue Mar 24 22:18:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 21:18:22 +0000
Subject: [issue23622] Deprecate unrecognized backslash+letter escapes in re
In-Reply-To: <1425907707.07.0.452600036872.issue23622@psf.upfronthosting.co.za>
Message-ID: <1427231902.4.0.293379414923.issue23622@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23622>
_______________________________________

From report at bugs.python.org  Tue Mar 24 22:24:33 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 21:24:33 +0000
Subject: [issue21802] Reader of BufferedRWPair is not closed if writer's
 close() fails
In-Reply-To: <1403113942.14.0.852744973704.issue21802@psf.upfronthosting.co.za>
Message-ID: <20150324212427.16168.54787@psf.io>


Roundup Robot added the comment:

New changeset d4694c672c36 by Serhiy Storchaka in branch '3.4':
Issue #21802: The reader in BufferedRWPair now is closed even when closing
https://hg.python.org/cpython/rev/d4694c672c36

New changeset f515c7ccff57 by Serhiy Storchaka in branch 'default':
Issue #21802: The reader in BufferedRWPair now is closed even when closing
https://hg.python.org/cpython/rev/f515c7ccff57

New changeset dcf25060cae8 by Serhiy Storchaka in branch '2.7':
Issue #21802: The reader in BufferedRWPair now is closed even when closing
https://hg.python.org/cpython/rev/dcf25060cae8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21802>
_______________________________________

From report at bugs.python.org  Tue Mar 24 22:24:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 21:24:54 +0000
Subject: [issue21802] Reader of BufferedRWPair is not closed if writer's
 close() fails
In-Reply-To: <1403113942.14.0.852744973704.issue21802@psf.upfronthosting.co.za>
Message-ID: <1427232294.28.0.5520361002.issue21802@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21802>
_______________________________________

From report at bugs.python.org  Tue Mar 24 22:28:27 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 24 Mar 2015 21:28:27 +0000
Subject: [issue23671] string.Template doesn't work with the self keyword
 argument
In-Reply-To: <1426407694.34.0.298286807857.issue23671@psf.upfronthosting.co.za>
Message-ID: <1427232507.38.0.735840532996.issue23671@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This is a nice catch of a subtle bug and a nice fix.  I verified that replacing 'self' with '*args' does not simply shift the problem from 'self' to 'args'.

>>> class C:
	def test(*args, **kwargs):
		print(args, kwargs )
	
>>> c = C()
>>> c.test(1, args=2, kwargs=3, self=4)
(<__main__.C object at 0x00000000035FE128>, 1) {'args': 2, 'kwargs': 3, 'self': 4}

While the * and ** names are, like parameter names, local names given in the signature header, they are not counted as parameter names in the code object .co_argcount or .co_kwonlyargcount attributes that are used along with co_varnames in the name-argument matching process.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23671>
_______________________________________

From report at bugs.python.org  Tue Mar 24 22:38:18 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Mar 2015 21:38:18 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <CAH_1eM2tS+ApXBuySMjeFDNF8G2OLg2qF=1ADdUJZYyAuZHkjA@mail.gmail.com>
Message-ID: <CAMpsgwbpNxpNrj85ULFAEOw-Zz+=WEQ0qVmL7vFib4J+gH5jyg@mail.gmail.com>


STINNER Victor added the comment:

Charles-Fran?ois Natali added the comment:
> You have to mount the share with the eintr option.

Oh, I didn't know this option. Unlikely, it looks like the option was
deprecated something like 7 years ago, in Linux kernel 2.6.25.

Related commits:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/nfs?id=d33e4dfeab5eb0c3c1359cc1a399f2f8b49e18de
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/nfs?id=c381ad2cf2d5dcd3991bcc8a18fddd9d5c66ccaa

The patch on the NFS mailing list:
http://comments.gmane.org/gmane.linux.nfs/20011

> Getting EINTR on a local FS is probably more challenging.

Another option would be to play with FUSE. But I'm not convinced that
it's useful if fstat() never fails EINTR on filesystems used in
production.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Tue Mar 24 22:42:22 2015
From: report at bugs.python.org (Hammerite)
Date: Tue, 24 Mar 2015 21:42:22 +0000
Subject: [issue23550] Add to unicodedata a function to query the "Quick_Check"
 property for a character
In-Reply-To: <1425147670.05.0.762030398058.issue23550@psf.upfronthosting.co.za>
Message-ID: <1427233342.97.0.771171379366.issue23550@psf.upfronthosting.co.za>


Hammerite added the comment:

I tried to add these responses within the code review section of the site, but I am unable to do so; when I click "Send Message", I am taken to a page that consists of the text "500 Server Error" and no other content. Therefore I am responding to the code review comments here.

Ezio:

The form comes before the chr because that is the order unicodedata.normalize() takes its arguments (though it takes a string rather than a single character). To write normalize(form, str) but quick_check(chr, form) would be quite inconsistent, I think, and would invite confusion. Agreed that a brief description of what the property is useful for would be good; I will make another patch that includes this.

I will delete the space after the function name. I will also eliminate the column arrangement of the test code, although I think that this will make the code much less readable.

Berker:

Regarding whatsnew: Since I have your invitation to do so, I will. Regarding putting the normalisation form comparison into helper functions, I will follow your suggestion, and incorporate the improvement for normalize() as well.

For the error message, this is the same error message that is given by unicodedata.normalize(). I could change it, but if I do, I think I should change it for normalize() at the same time.

For two of your other points I would like to observe that the way I have done things is in mimicry of existing code that relates to the unicodedata module. Elsewhere in unicodedata.c multiline strings are continued using \, so I have done the same; in makeunicodedata.py the other arrays are not static so the new one is not static either. I could make these changes regardless, but the result would be inconsistency in the code. Or I could change these things everywhere in the relevant files, but this would mean I would be changing parts of the files that are not properly related to this issue.

For the remaining stylistic points, I will make the changes you asked for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23550>
_______________________________________

From report at bugs.python.org  Tue Mar 24 22:53:46 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 24 Mar 2015 21:53:46 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <1427234026.37.0.891920756775.issue20160@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

This https://mail.python.org/pipermail/python-dev/2014-December/137631.html seems relevant.  Follow up here https://mail.python.org/pipermail/python-dev/2015-March/138731.html

----------
nosy: +BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20160>
_______________________________________

From report at bugs.python.org  Tue Mar 24 23:01:29 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 22:01:29 +0000
Subject: [issue23573] Avoid redundant allocations in str.find and like
In-Reply-To: <1425390810.95.0.0960267231917.issue23573@psf.upfronthosting.co.za>
Message-ID: <1427234489.27.0.0338290769213.issue23573@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Looks as this patch makes buildbots crash.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23573>
_______________________________________

From report at bugs.python.org  Tue Mar 24 23:03:16 2015
From: report at bugs.python.org (Carol Willing)
Date: Tue, 24 Mar 2015 22:03:16 +0000
Subject: [issue23761] test_socket fails on Mac OSX 10.9.5
In-Reply-To: <1427203301.62.0.862934673257.issue23761@psf.upfronthosting.co.za>
Message-ID: <1427234596.25.0.827679208873.issue23761@psf.upfronthosting.co.za>


Carol Willing added the comment:

Thanks Ned and R. David. A few questions...

1.  I've rerun the tests using:

One failure:
70 tests OK.
1 test failed:
    test_socket
1 test altered the execution environment:
    test_warnings
21 tests skipped:
    test_curses test_dbm_gnu test_devpoll test_epoll test_gdb
    test_lzma test_msilib test_ossaudiodev test_smtpnet
    test_socketserver test_spwd test_startfile test_timeout test_tk
    test_ttk_guionly test_urllib2net test_urllibnet test_winreg
    test_winsound test_xmlrpc_net test_zipfile64

I noticed that many tests are skipped since Network is not enabled. Although test_socket fails and is not skipped, it seems plausible that the failure in test_socket should also be skipped when Network is disabled. Other test files that are skipped have support.requires('network') in the beginning of the file. Should test_socket.py have this as well?

2. I am rerunning the tests with the following command:
./python.exe -m test -uall

Tests dependent on 'Network' are now run. Three failures now:

3 tests failed:
    test_curses test_nntplib test_socket
1 test altered the execution environment:
    test_warnings
14 tests skipped:
    test_dbm_gnu test_devpoll test_epoll test_gdb test_lzma
    test_msilib test_ossaudiodev test_spwd test_startfile test_tk
    test_ttk_guionly test_winreg test_winsound test_zipfile64

Detail:
    nntplib.NNTPTemporaryError: 400 Permission denied:  Closed service.

    
3. Is there a doc that outlines how to enable all dependencies needed to have tests execute and not be skipped? Which is the preferred command for running tests for Mac OSX?

I'm willing to keep chasing this down but need a little direction. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23761>
_______________________________________

From report at bugs.python.org  Tue Mar 24 23:12:03 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 22:12:03 +0000
Subject: [issue23766] json.dumps: solidus ("/") should be escaped
In-Reply-To: <1427226223.82.0.96478521351.issue23766@psf.upfronthosting.co.za>
Message-ID: <1427235123.02.0.212902642011.issue23766@psf.upfronthosting.co.za>


Martin Panter added the comment:

According to that RFC section, the forward solidus is allowed to be in an escape sequence, but it is also allowed unescaped:

?All Unicode characters may be placed within the quotation marks, except for the characters that must be escaped: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F).?

. . .

unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

In general, escaping the forward solidus is not needed, and is easier to read. Apparently this escaping is a workaround for embedding JSON inside a HTML <script> element, where the sequence ?</? is not allowed, and HTML itself does not allow escaping: <http://www.w3.org/TR/html4/appendix/notes.html#h-B.3.2>. In that case, JSON like {markup: "<i>italic<\/i>"} would be escaped, but most cases still do not need escaping, such as {url: "http://example.net/"}.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23766>
_______________________________________

From report at bugs.python.org  Tue Mar 24 23:21:18 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 22:21:18 +0000
Subject: [issue23766] json.dumps: solidus ("/") should be escaped
In-Reply-To: <1427226223.82.0.96478521351.issue23766@psf.upfronthosting.co.za>
Message-ID: <1427235678.81.0.677968293364.issue23766@psf.upfronthosting.co.za>


R. David Murray added the comment:

It sounds like that makes this not-a-bug?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23766>
_______________________________________

From report at bugs.python.org  Tue Mar 24 23:22:14 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Mar 2015 22:22:14 +0000
Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting
 of integers
In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za>
Message-ID: <1427235734.28.0.366176961032.issue23466@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The patch looks good to me, except of a question added on the review.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23466>
_______________________________________

From report at bugs.python.org  Tue Mar 24 23:27:08 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 22:27:08 +0000
Subject: [issue23171] csv.writer.writerow() does not accept generator (must be
 coerced to list)
In-Reply-To: <1420479102.66.0.846752030326.issue23171@psf.upfronthosting.co.za>
Message-ID: <1427236028.16.0.372891162155.issue23171@psf.upfronthosting.co.za>


Martin Panter added the comment:

Left a question about handling of the unquoted empty field exception on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23171>
_______________________________________

From report at bugs.python.org  Tue Mar 24 23:32:14 2015
From: report at bugs.python.org (Robert Kuska)
Date: Tue, 24 Mar 2015 22:32:14 +0000
Subject: [issue23769] valgrind reports leaks for test_zipimport
Message-ID: <1427236334.27.0.200472101868.issue23769@psf.upfronthosting.co.za>


New submission from Robert Kuska:

Leaks happen only when both testDoctestFile and testDoctestSuite are run.
Run with Python 3.4.2 and 3.4.1 with same result.

I have extracted those two tests into `leak.py` (attached).

> $ valgrind --suppressions=/../cpython/Misc/valgrind-python.supp python3 leak.py                                                                                            
==17896== Memcheck, a memory error detector
==17896== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==17896== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==17896== Command: python3 leak.py
==17896== 
==17896== 
==17896== HEAP SUMMARY:
==17896==     in use at exit: 1,599,328 bytes in 11,595 blocks
==17896==   total heap usage: 283,757 allocs, 272,162 frees, 37,891,147 bytes allocated
==17896== 
==17896== LEAK SUMMARY:
==17896==    definitely lost: 30 bytes in 1 blocks
==17896==    indirectly lost: 0 bytes in 0 blocks
==17896==      possibly lost: 597,418 bytes in 2,319 blocks
==17896==    still reachable: 1,001,880 bytes in 9,275 blocks
==17896==         suppressed: 0 bytes in 0 blocks
==17896== Rerun with --leak-check=full to see details of leaked memory
==17896== 
==17896== For counts of detected and suppressed errors, rerun with: -v
==17896== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Note that when I remove support.modules_cleanup(*modules_before) from leak.py valgrind reports no leaks (in original test_zipimport those are run in setUp and tearDown).

Output of  
valgrind --suppressions=/home/rkuska/upstream/cpython/Misc/valgrind-python.supp --leak-check=yes -v python3 leak.py
attached as `report`.

----------
components: Tests
files: leak.py
messages: 239193
nosy: rkuska
priority: normal
severity: normal
status: open
title: valgrind reports leaks for test_zipimport
versions: Python 3.4
Added file: http://bugs.python.org/file38672/leak.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23769>
_______________________________________

From report at bugs.python.org  Tue Mar 24 23:32:45 2015
From: report at bugs.python.org (Robert Kuska)
Date: Tue, 24 Mar 2015 22:32:45 +0000
Subject: [issue23769] valgrind reports leaks for test_zipimport
In-Reply-To: <1427236334.27.0.200472101868.issue23769@psf.upfronthosting.co.za>
Message-ID: <1427236365.41.0.0778661307108.issue23769@psf.upfronthosting.co.za>


Changes by Robert Kuska <rkuska at gmail.com>:


Added file: http://bugs.python.org/file38673/report

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23769>
_______________________________________

From report at bugs.python.org  Tue Mar 24 23:36:12 2015
From: report at bugs.python.org (Robert Kuska)
Date: Tue, 24 Mar 2015 22:36:12 +0000
Subject: [issue23769] valgrind reports leaks for test_zipimport
In-Reply-To: <1427236334.27.0.200472101868.issue23769@psf.upfronthosting.co.za>
Message-ID: <1427236572.32.0.506402278019.issue23769@psf.upfronthosting.co.za>


Robert Kuska added the comment:

Summary for
valgrind python3 test_zipimport.py

==18608== 
==18608== HEAP SUMMARY:
==18608==     in use at exit: 1,596,390 bytes in 11,536 blocks
==18608==   total heap usage: 343,849 allocs, 332,313 frees, 59,355,776 bytes allocated
==18608== 
==18608== LEAK SUMMARY:
==18608==    definitely lost: 90 bytes in 3 blocks
==18608==    indirectly lost: 0 bytes in 0 blocks
==18608==      possibly lost: 594,488 bytes in 2,258 blocks
==18608==    still reachable: 1,001,812 bytes in 9,275 blocks
==18608==         suppressed: 0 bytes in 0 blocks
==18608== Rerun with --leak-check=full to see details of leaked memory
==18608== 
==18608== For counts of detected and suppressed errors, rerun with: -v
==18608== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23769>
_______________________________________

From report at bugs.python.org  Tue Mar 24 23:40:46 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 Mar 2015 22:40:46 +0000
Subject: [issue23712] Experiment: Assume that exact unicode hashes are perfect
 discriminators
In-Reply-To: <1426795062.72.0.102774381262.issue23712@psf.upfronthosting.co.za>
Message-ID: <1427236846.96.0.225831058414.issue23712@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> low
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23712>
_______________________________________

From report at bugs.python.org  Tue Mar 24 23:52:01 2015
From: report at bugs.python.org (Nikolaus Rath)
Date: Tue, 24 Mar 2015 22:52:01 +0000
Subject: [issue23529] Limit decompressed data when reading from LZMAFile and
 BZ2File
In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za>
Message-ID: <1427237521.29.0.154294363968.issue23529@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

As discussed in Rietveld, here's an attempt to reuse more DecompressReader for GzipFile. There is still an unexplained test failure (test_read_truncated).

----------
Added file: http://bugs.python.org/file38674/LZMAFile-etc.v7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23529>
_______________________________________

From report at bugs.python.org  Wed Mar 25 00:29:32 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 Mar 2015 23:29:32 +0000
Subject: [issue23769] valgrind reports leaks for test_zipimport
In-Reply-To: <1427236334.27.0.200472101868.issue23769@psf.upfronthosting.co.za>
Message-ID: <1427239772.68.0.319659351695.issue23769@psf.upfronthosting.co.za>


STINNER Victor added the comment:

When calling gc.collect() after each test, I don't see any leak anymore.

doTest() has a small leak: it prepends a path to sys.path, but it never removes it.

Try attached leak2.py: it displays something like +254 kB. Uncomment the two following lines and the output will be close to +0 kB.

        #sys.path = old_path
    #gc.collect()

----------
nosy: +haypo
Added file: http://bugs.python.org/file38675/leak2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23769>
_______________________________________

From report at bugs.python.org  Wed Mar 25 00:35:06 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 23:35:06 +0000
Subject: [issue23622] Deprecate unrecognized backslash+letter escapes in re
In-Reply-To: <1425907707.07.0.452600036872.issue23622@psf.upfronthosting.co.za>
Message-ID: <20150324233502.82182.42773@psf.io>


Roundup Robot added the comment:

New changeset 7384db2fce8a by Serhiy Storchaka in branch 'default':
Fixed using deprecated escaping in regular expression in _strptime.py (issue23622).
https://hg.python.org/cpython/rev/7384db2fce8a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23622>
_______________________________________

From report at bugs.python.org  Wed Mar 25 01:26:08 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Mar 2015 00:26:08 +0000
Subject: [issue23761] test_socket fails on Mac OSX 10.9.5
In-Reply-To: <1427203301.62.0.862934673257.issue23761@psf.upfronthosting.co.za>
Message-ID: <1427243168.26.0.889301788591.issue23761@psf.upfronthosting.co.za>


R. David Murray added the comment:

There are always going to be tests that are skipped (ones that don't run on your platform).

Most of test_socket should run even if all you have is localhost networking. The 'network' resource is designed to control access to *external* networking resources, and there is at least one specific test in test_socket that is protected by the resource.  

I always run the test suite using '-uall' myself, which enables all the resources except for the ones that take lots of memory or disk space. If you have built python from source/checkout, then you can run the test suite using:

  ./python.exe -m test -uall

For investigating this failure, you should change the beginning of test_host_resolution from:

    for addr in ['0.1.1.~1', '1+.1.1.1', '::1q', '::1::2',
                 '1:1:1:1:1:1:1:1:1']:
        self.assertRaises(OSError, socket.gethostbyname, addr)
        self.assertRaises(OSError, socket.gethostbyaddr, addr)

to:

    for addr in ['0.1.1.~1', '1+.1.1.1', '::1q', '::1::2',
                 '1:1:1:1:1:1:1:1:1']:
        for func in socket.gethostbyname, socket.gethostbyaddr:
            with self.subTest(addr=addr, func=func):
                self.assertRaises(OSError, func, addr)

and report the results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23761>
_______________________________________

From report at bugs.python.org  Wed Mar 25 01:29:20 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 00:29:20 +0000
Subject: [issue23770] Rework of exceptions are handled in the parser module
 (in validate_repeating_list())
Message-ID: <1427243360.96.0.274103044553.issue23770@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch avoids calling validate_numnodes() with an exception set in the parser module.

I found this issue while working on the issue #23763 "Chain exceptions in C".

----------
files: validate_repeating_list.patch
keywords: patch
messages: 239199
nosy: haypo
priority: normal
severity: normal
status: open
title: Rework of exceptions are handled in the parser module (in validate_repeating_list())
versions: Python 3.5
Added file: http://bugs.python.org/file38676/validate_repeating_list.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23770>
_______________________________________

From report at bugs.python.org  Wed Mar 25 01:32:32 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 00:32:32 +0000
Subject: [issue23763] Chain exceptions in C
In-Reply-To: <1427208097.93.0.892198283241.issue23763@psf.upfronthosting.co.za>
Message-ID: <1427243552.81.0.785917409462.issue23763@psf.upfronthosting.co.za>


STINNER Victor added the comment:

pyerr_match_clear-2.patch: Updated patch, more complete (I also removed the assertions, I only added to debug).

> Since my patch makes assumption on which exception is expected, it can change the behaviour of functions if I forgot a different exception which is also supposed to be replaced.

To reduce risks, we can just remove the new PyErr_ExceptionMatches() checks from the patch in a first time, and add them later, while being very careful.

Calling PyErr_Clear() where exceptions must not be chained should be enough for a first step.

----------
Added file: http://bugs.python.org/file38677/pyerr_match_clear-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23763>
_______________________________________

From report at bugs.python.org  Wed Mar 25 01:40:50 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 00:40:50 +0000
Subject: [issue23763] Chain exceptions in C
In-Reply-To: <1427208097.93.0.892198283241.issue23763@psf.upfronthosting.co.za>
Message-ID: <1427244050.68.0.80018897961.issue23763@psf.upfronthosting.co.za>


STINNER Victor added the comment:

New issue #23770: "Rework of exceptions are handled in the parser module (in validate_repeating_list())" to fix error handling in the parser module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23763>
_______________________________________

From report at bugs.python.org  Wed Mar 25 01:44:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 00:44:23 +0000
Subject: [issue23766] json.dumps: solidus ("/") should be escaped
In-Reply-To: <1427226223.82.0.96478521351.issue23766@psf.upfronthosting.co.za>
Message-ID: <1427244263.03.0.834531696289.issue23766@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See issue18290. Not only solidus is incompatible with JavaScript, and it id easy to escape problem characters after passing through JSON encoder using str.replace().

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23766>
_______________________________________

From report at bugs.python.org  Wed Mar 25 01:46:21 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 00:46:21 +0000
Subject: [issue23763] Chain exceptions in C
In-Reply-To: <1427208097.93.0.892198283241.issue23763@psf.upfronthosting.co.za>
Message-ID: <1427244381.12.0.947209043324.issue23763@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, I had a private local commit when I generated pyerr_match_clear-2.patch and so Rietveld failed to find the branch. I regenerated the patch.

----------
Added file: http://bugs.python.org/file38678/pyerr_match_clear-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23763>
_______________________________________

From report at bugs.python.org  Wed Mar 25 01:46:33 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 00:46:33 +0000
Subject: [issue23763] Chain exceptions in C
In-Reply-To: <1427208097.93.0.892198283241.issue23763@psf.upfronthosting.co.za>
Message-ID: <1427244393.11.0.650820864588.issue23763@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file38677/pyerr_match_clear-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23763>
_______________________________________

From report at bugs.python.org  Wed Mar 25 01:52:08 2015
From: report at bugs.python.org (productivememberofsociety666)
Date: Wed, 25 Mar 2015 00:52:08 +0000
Subject: [issue23764] functools.wraps should be able to change function
 argspec as well
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427244728.84.0.301619702948.issue23764@psf.upfronthosting.co.za>


productivememberofsociety666 added the comment:

I'm not sure if I understand issue 15731 correctly, but isn't that one just about docstrings and signatures? These are both purely "cosmetic" and don't have an effect on calling behaviour, do they?
This issue wouldn't be a duplicate then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23764>
_______________________________________

From report at bugs.python.org  Wed Mar 25 01:52:58 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 00:52:58 +0000
Subject: [issue23763] Chain exceptions in C
In-Reply-To: <1427208097.93.0.892198283241.issue23763@psf.upfronthosting.co.za>
Message-ID: <1427244778.02.0.928118006884.issue23763@psf.upfronthosting.co.za>


STINNER Victor added the comment:

pyerr_chain.patch: The real patch to chain automatically exceptions when using
PyErr_*() functions.

pyerr_match_clear-2.patch hides the original exception when it is useless, too
low level like OverflowError when casting to C types, etc.

Examples without pyerr_match_clear-2.patch.

int, before:

| $ python3 -c 'int("123z")'
| Traceback (most recent call last):
|   File "<string>", line 1, in <module>
| ValueError: invalid literal for int() with base 10: '123z'

int, after:

| $ ./python -c 'int("123z")'
| ValueError: invalid literal for int() with base 10: '123z'
|
| During handling of the above exception, another exception occurred:
|
| Traceback (most recent call last):
|   File "<string>", line 1, in <module>
| ValueError: invalid literal for int() with base 10: '123z'

struct, before:

| $ python3 -c 'import struct; struct.pack("b", 2**100)'
| Traceback (most recent call last):
|   File "<string>", line 1, in <module>
| struct.error: argument out of range

struct, after:

| $ ./python -c 'import struct; struct.pack("b", 2**100)'
| OverflowError: Python int too large to convert to C long
|
| During handling of the above exception, another exception occurred:
|
| Traceback (most recent call last):
|   File "<string>", line 1, in <module>
| struct.error: argument out of range


More examples, after (still without pyerr_match_clear-2.patch):

int(str):

| TypeError: a bytes-like object is required, not 'type'
|
| During handling of the above exception, another exception occurred:
|
| Traceback (most recent call last):
|   File "<stdin>", line 1, in <module>
| TypeError: int() argument must be a string, a bytes-like object or a number, not 'type'

''.join(str):

| TypeError: 'type' object is not iterable
|
| During handling of the above exception, another exception occurred:
|
| Traceback (most recent call last):
|   File "<stdin>", line 1, in <module>
| TypeError: can only join an iterable


b"%f" % "abc":

| TypeError: a float is required
|
| During handling of the above exception, another exception occurred:
|
| Traceback (most recent call last):
|   File "<stdin>", line 1, in <module>
| TypeError: float argument required, not str

----------
Added file: http://bugs.python.org/file38679/pyerr_chain.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23763>
_______________________________________

From report at bugs.python.org  Wed Mar 25 01:55:50 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Mar 2015 00:55:50 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <20150325005547.30042.52480@psf.io>


Roundup Robot added the comment:

New changeset 1c2376825dd2 by Victor Stinner in branch '3.4':
Issue #23571: Fix reentrant call to Py_FatalError()
https://hg.python.org/cpython/rev/1c2376825dd2

New changeset e9ba95418af8 by Victor Stinner in branch 'default':
(Merge 3.4) Issue #23571: Fix reentrant call to Py_FatalError()
https://hg.python.org/cpython/rev/e9ba95418af8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Wed Mar 25 01:55:52 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 00:55:52 +0000
Subject: [issue23763] Chain exceptions in C
In-Reply-To: <1427208097.93.0.892198283241.issue23763@psf.upfronthosting.co.za>
Message-ID: <1427244952.54.0.387339854857.issue23763@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file38678/pyerr_match_clear-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23763>
_______________________________________

From report at bugs.python.org  Wed Mar 25 01:56:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 00:56:57 +0000
Subject: [issue23763] Chain exceptions in C
In-Reply-To: <1427208097.93.0.892198283241.issue23763@psf.upfronthosting.co.za>
Message-ID: <1427245017.92.0.450668919152.issue23763@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Sorry, I had issues with my local repository. Third try to upload pyerr_match_clear-2.patch for Rietveld.

----------
Added file: http://bugs.python.org/file38680/pyerr_match_clear-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23763>
_______________________________________

From report at bugs.python.org  Wed Mar 25 02:30:37 2015
From: report at bugs.python.org (matham)
Date: Wed, 25 Mar 2015 01:30:37 +0000
Subject: [issue23743] Python crashes upon exit if importing g++ compiled mod
 after importing gcc compiled mod
In-Reply-To: <1427087434.95.0.234111642557.issue23743@psf.upfronthosting.co.za>
Message-ID: <1427247037.79.0.193369288899.issue23743@psf.upfronthosting.co.za>


matham added the comment:

Well, we won't have to wait until interested solves it. After hours of debugging including compiling Python with VS2013 and looking at windows dump files, it seems that hard work pays off - sorry, I mean asking someone who knows the answer pays off :P.

I asked on #mingw and it was suggested that I use mingw compiled with the SJLJ exception model. And indeed, using sjlj fixed this so that it does not crash anymore. It seems that mingw from mingw.org compiles with `"--disable-sjlj-exceptions`, so one has to use mingw-w64's distribution which offers a sjlj build (for x86 and SEH for x64).

I am wondering whether this information should be somewhere on the python website so that other people do not run into this issue. I'm not sure what the proper resolution is here so I'll live it open. Or maybe it should be open until the docs is updated to warn about this issue.

Anyway, here's the pertinent parts of my #mingw chat:

<jon_y> matham: I suggest going for SJLJ on 32bit
<jon_y> SEH on 64bit
<jon_y> avoid dw2 exception like the plague
<matham> ok, the one I got from mingw-get says "--disable-sjlj-exceptions --with-dwarf2"
<matham> I'll try with sjlj
<matham> from mingw-w64
<matham> jon_y, \o/\o/\o/\o/\o/\o/\o/ omg I'm so happy :D it looks like using sjlj fixed it
<jon_y> matham: I mean --disable-sjlj-exceptions
<jon_y> that is the C++ exception part
<jon_y> dwarf2 as debug is fine
<jon_y> --with-dwarf2 specifies the debug data format
<jon_y> yeah, dw2 (when --disable-sjlj-exceptions is used) has lots of issues with python
<matham> so the problem is when sjlj is disabled?
<matham> I thought it was either/or with sjlj vs dw2
<jon_y> dw2 doesn't quite work right for windows
<jon_y> it requires ALL dll code use the same shared libgcc dll
<jon_y> failure to do so leads to random crashes, especially during program termination
<matham> so why does mingw-get automatically do --disable-sjlj-exceptions?
<jon_y> mingw.org only provides toolchain that uses dw2 exceptions
<jon_y> this has been so ever since the 4.2.1 days
<jon_y> (that was the first widely used Windows gcc 4.x version)
<jon_y> matham: Cygwin had the same problem with python and their dw2 gcc recently
<jon_y> but had some local patches done in to fix it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23743>
_______________________________________

From report at bugs.python.org  Wed Mar 25 02:47:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 01:47:05 +0000
Subject: [issue23573] Avoid redundant allocations in str.find and like
In-Reply-To: <1425390810.95.0.0960267231917.issue23573@psf.upfronthosting.co.za>
Message-ID: <1427248025.4.0.819080398934.issue23573@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Looks as this patch makes buildbots crash.

Yep. It took me some minutes to find that the crash was caused by this issue :-p

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/5930/steps/test/logs/stdio

...
[117/393/1] test_bigmem
Assertion failed: 0, file c:\buildbot.python.org\3.x.kloth-win64\build\objects\stringlib/fastsearch.h, line 76
Fatal Python error: Aborted

Current thread 0x000010ec (most recent call first):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_bigmem.py", line 294 in test_rfind
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 1641 in wrapper
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\case.py", line 577 in run
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\case.py", line 625 in __call__
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 122 in run
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 84 in __call__
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 122 in run
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 84 in __call__
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\runner.py", line 176 in run
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 1773 in _run_suite
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 1807 in run_unittest
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_bigmem.py", line 1252 in test_main
...

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23573>
_______________________________________

From report at bugs.python.org  Wed Mar 25 02:47:37 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Mar 2015 01:47:37 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <20150325014730.30033.3277@psf.io>


Roundup Robot added the comment:

New changeset 004e3870d9e6 by Victor Stinner in branch '3.4':
Issue #23571: If io.TextIOWrapper constructor fails in _Py_DisplaySourceLine(),
https://hg.python.org/cpython/rev/004e3870d9e6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Wed Mar 25 02:58:00 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 01:58:00 +0000
Subject: [issue23573] Avoid redundant allocations in str.find and like
In-Reply-To: <1425390810.95.0.0960267231917.issue23573@psf.upfronthosting.co.za>
Message-ID: <1427248680.39.0.731155715921.issue23573@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The problem is that Windows has no memrchr() function, and so fastsearch_memchr_1char() only supports FAST_SEARCH on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23573>
_______________________________________

From report at bugs.python.org  Wed Mar 25 03:17:15 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Mar 2015 02:17:15 +0000
Subject: [issue23573] Avoid redundant allocations in str.find and like
In-Reply-To: <1425390810.95.0.0960267231917.issue23573@psf.upfronthosting.co.za>
Message-ID: <20150325021712.30031.62953@psf.io>


Roundup Robot added the comment:

New changeset 3ac58de829ef by Victor Stinner in branch 'default':
Issue #23573: Fix bytes.rfind() and bytearray.rfind() on Windows
https://hg.python.org/cpython/rev/3ac58de829ef

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23573>
_______________________________________

From report at bugs.python.org  Wed Mar 25 03:19:38 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 02:19:38 +0000
Subject: [issue23573] Avoid redundant allocations in str.find and like
In-Reply-To: <1425390810.95.0.0960267231917.issue23573@psf.upfronthosting.co.za>
Message-ID: <1427249978.46.0.948136706723.issue23573@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It looks like fastsearch_memchr_1char() manipulate pointers for memory alignment. It's not necessary when looking for ASCII or Latin1 characters or for bytes.

I propose to add a new fastsearch_memchr_1byte() function which would be used by bytes and bytearray, but also by str for ASCII and Latin1 strings.

Are you interested to implement this idea Serhiy?

For Windows without memrchr(), the code can be a simple loop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23573>
_______________________________________

From report at bugs.python.org  Wed Mar 25 03:42:02 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 02:42:02 +0000
Subject: [issue23771] Timeouts on "x86 Ubuntu Shared 3.x" buildbot
Message-ID: <1427251322.87.0.815245923642.issue23771@psf.upfronthosting.co.za>


New submission from STINNER Victor:

First timeout:
http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/11358

This build was only triggered by one changeset 0b99d7043a99: "Issue #23694: Enhance _Py_open(), it now raises exceptions".

 * _Py_open() now raises exceptions on error. If open() fails, it raises an OSError with the filename.
 * _Py_open() now releases the GIL while calling open()
 * Add _Py_open_noraise() when _Py_open() cannot be used because the GIL is not held

Example of subprocess timeout:
---
Timeout (1:00:00)!
Thread 0x55aaedc0 (most recent call first):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 1502 in _try_wait
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 1552 in wait
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_subprocess.py", line 58 in tearDown
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 580 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 625 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/runner.py", line 176 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1773 in _run_suite
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1807 in run_unittest
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_subprocess.py", line 2532 in test_main
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1284 in runtest_inner
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 967 in runtest
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 763 in main
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1568 in main_in_temp_cwd
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/__main__.py", line 3 in <module>
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/runpy.py", line 85 in _run_code
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/runpy.py", line 170 in _run_module_as_main
make: *** [buildbottest] Error 1
---

Example of multiprocessing timeout:
---
[240/393] test_multiprocessing_spawn
Timeout (1:00:00)!
Thread 0x68fddb40 (most recent call first):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 379 in _recv
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 407 in _recv_bytes
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 250 in recv
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 717 in _callmethod
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 955 in wait
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/_test_multiprocessing.py", line 834 in f
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 871 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 923 in _bootstrap_inner
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 891 in _bootstrap

Thread 0x58a5ab40 (most recent call first):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 379 in _recv
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 407 in _recv_bytes
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 250 in recv
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 717 in _callmethod
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 955 in wait
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/_test_multiprocessing.py", line 834 in f
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 871 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 923 in _bootstrap_inner
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/threading.py", line 891 in _bootstrap

(...)

Thread 0x55aaedc0 (most recent call first):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 379 in _recv
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 407 in _recv_bytes
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/connection.py", line 250 in recv
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 717 in _callmethod
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/multiprocessing/managers.py", line 943 in acquire
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/_test_multiprocessing.py", line 933 in test_notify_all
  ...
---

----------
messages: 239214
nosy: haypo
priority: normal
severity: normal
status: open
title: Timeouts on "x86 Ubuntu Shared 3.x" buildbot
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23771>
_______________________________________

From report at bugs.python.org  Wed Mar 25 03:43:43 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 25 Mar 2015 02:43:43 +0000
Subject: [issue23529] Limit decompressed data when reading from LZMAFile and
 BZ2File
In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za>
Message-ID: <1427251423.55.0.504754280708.issue23529@psf.upfronthosting.co.za>


Martin Panter added the comment:

Wolfgang: If the patch here is too massive, perhaps you might like to review my patch at Issue 23528 first. :) It only fixes the ?gzip? module, but is definitely simpler, so might have more chance of making it into 3.4 or 3.5 on time.

===

Changes introduced by patch v7 if anyone?s interested: <https://bitbucket.org/vadmium/cpython/commits/b7c43f7>. A few problems and behaviour changes are introduced:

* GzipFile(filename=...).close() now relies on the garbage collector to close the file
* EOFError("Compressed file ended before the end-of-stream marker was reached") repaced with ?struct.error? exception in some cases, e.g. GzipFile(fileobj=BytesIO(gzip_data[:3])).read()
* Premature EOF when stream ends in some cases, e.g. GzipFile(fileobj=BytesIO(empty_gzip + gzip_data)).read()

However I think the general idea of inheriting the common reader class and overriding as necessary is sound. Just looks like the code got too messed around in the process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23529>
_______________________________________

From report at bugs.python.org  Wed Mar 25 03:51:22 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 02:51:22 +0000
Subject: [issue23772] pymonotonic() gone backward on "AMD64 Debian root 3.x"
 buildbot
Message-ID: <1427251882.59.0.116696625299.issue23772@psf.upfronthosting.co.za>


New submission from STINNER Victor:

I would be interested to know the Linux version of this buildbot slave.

Maybe the slave is running in a VM and it's a virtualization issue? If it's the case, should Python fix the bug? Or should we just remove the assertion?

http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/1943/steps/test/logs/stdio
---
python: Python/pytime.c:221: pymonotonic: Assertion `last.tv_usec == -1 || tp->tv_sec > last.tv_sec || (tp->tv_sec == last.tv_sec && tp->tv_usec >= last.tv_usec)' failed.
Fatal Python error: Aborted

Thread 0x00002b9135bc4700 (most recent call first):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_gc.py", line 364 in sleeper_gen
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_gc.py", line 390 in make_nested
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_gc.py", line 395 in run_thread
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 871 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 923 in _bootstrap_inner
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 891 in _bootstrap

Current thread 0x00002b91355c1700 (most recent call first):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_gc.py", line 364 in sleeper_gen
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_gc.py", line 390 in make_nested
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_gc.py", line 395 in run_thread
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 871 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 923 in _bootstrap_inner
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 891 in _bootstrap

Thread 0x00002b9127825b20 (most recent call first):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_gc.py", line 407 in test_trashcan_threads
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/case.py", line 577 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/case.py", line 625 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 122 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 122 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/runner.py", line 176 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/support/__init__.py", line 1772 in _run_suite
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/support/__init__.py", line 1806 in run_unittest
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_gc.py", line 1000 in test_main
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/regrtest.py", line 1284 in runtest_inner
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/regrtest.py", line 967 in runtest
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/regrtest.py", line 763 in main
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/regrtest.py", line 1568 in main_in_temp_cwd
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/__main__.py", line 3 in <module>
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/runpy.py", line 85 in _run_code
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/runpy.py", line 170 in _run_module_as_main
---

----------
messages: 239216
nosy: haypo
priority: normal
severity: normal
status: open
title: pymonotonic() gone backward on "AMD64 Debian root 3.x" buildbot
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23772>
_______________________________________

From report at bugs.python.org  Wed Mar 25 04:06:58 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 03:06:58 +0000
Subject: [issue23771] Timeouts on "x86 Ubuntu Shared 3.x" buildbot
In-Reply-To: <1427251322.87.0.815245923642.issue23771@psf.upfronthosting.co.za>
Message-ID: <1427252818.44.0.766254300525.issue23771@psf.upfronthosting.co.za>


STINNER Victor added the comment:

test_multiprocessing_spawn.test_notify_all() also hangs on "AMD64 Debian root 3.x" buildbot:

http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/1959/steps/test/logs/stdio
---
[330/393] test_multiprocessing_spawn
Timeout (1:00:00)!
Thread 0x00002b303f269700 (most recent call first):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/multiprocessing/synchronize.py", line 262 in wait
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/_test_multiprocessing.py", line 834 in f
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 871 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 923 in _bootstrap_inner
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 891 in _bootstrap

Thread 0x00002b303d918700 (most recent call first):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/multiprocessing/synchronize.py", line 262 in wait
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/_test_multiprocessing.py", line 834 in f
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 871 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 923 in _bootstrap_inner
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 891 in _bootstrap

Thread 0x00002b3060947700 (most recent call first):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/multiprocessing/synchronize.py", line 262 in wait
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/_test_multiprocessing.py", line 834 in f
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 871 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 923 in _bootstrap_inner
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/threading.py", line 891 in _bootstrap

Thread 0x00002b303289db20 (most recent call first):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/_test_multiprocessing.py", line 933 in test_notify_all
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/case.py", line 577 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/case.py", line 625 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 122 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 122 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 122 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/unittest/runner.py", line 176 in run
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/support/__init__.py", line 1773 in _run_suite
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/support/__init__.py", line 1807 in run_unittest
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/regrtest.py", line 1283 in test_runner
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/regrtest.py", line 1284 in runtest_inner
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/regrtest.py", line 967 in runtest
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/regrtest.py", line 763 in main
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/regrtest.py", line 1568 in main_in_temp_cwd
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/__main__.py", line 3 in <module>
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/runpy.py", line 85 in _run_code
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/runpy.py", line 170 in _run_module_as_main
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23771>
_______________________________________

From report at bugs.python.org  Wed Mar 25 04:17:09 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 03:17:09 +0000
Subject: [issue23772] pymonotonic() gone backward on "AMD64 Debian root 3.x"
 buildbot
In-Reply-To: <1427251882.59.0.116696625299.issue23772@psf.upfronthosting.co.za>
Message-ID: <1427253429.69.0.0232309769308.issue23772@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> ==   Linux-3.2.0-4-amd64-x86_64-with-debian-7.7 little-endian

Kernel: Linux-3.2.0-4
CPU: amd64-x86_64 (little-endian)
OS: debian-7.7

Linux had a bug in version < 2.6.33 (also fixed in 2.6.32.19):

"[PATCH] Fix clock_gettime vsyscall time warp"
https://lkml.org/lkml/2009/11/17/7

=> https://lists.debian.org/debian-kernel/2010/09/msg00001.html

See also:

- https://bugzilla.redhat.com/show_bug.cgi?id=595225
- https://bugzilla.redhat.com/show_bug.cgi?id=742037

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23772>
_______________________________________

From report at bugs.python.org  Wed Mar 25 04:28:58 2015
From: report at bugs.python.org (Shiz)
Date: Wed, 25 Mar 2015 03:28:58 +0000
Subject: [issue23773] importlib does not properly remove frames when invoking
 external import hooks
Message-ID: <1427254138.42.0.76544892287.issue23773@psf.upfronthosting.co.za>


New submission from Shiz:

When adding a custom module loader to sys.meta_path, importlib does not properly remove its frames before invoking it. This results in a weird traceback with importlib._bootstrap frames in if an error occurs during load_module(), like such:

Traceback (most recent call last):
  File "/Users/mark/Development/Projects/rave/rave/bootstrap/__init__.py", line 102, in bootstrap_game
    __import__(MODULE_PACKAGE + '.' + mod.replace('.py', ''))
  File "<frozen importlib._bootstrap>", line 2237, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2226, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1200, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1129, in _exec
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module
    super().exec_module(module)
  File "/.modules/opengl/__init__.py", line 1, in <module>
    from . import common, core3
  File "<frozen importlib._bootstrap>", line 2237, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2226, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1200, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1129, in _exec
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module
    super().exec_module(module)
  File "/.modules/opengl/core3/__init__.py", line 11, in <module>
    from .texture import Texture, Image
  File "<frozen importlib._bootstrap>", line 2237, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2226, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 1200, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 1129, in _exec
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module
    super().exec_module(module)
  File "/.modules/opengl/core3/texture.py", line 8, in <module>
    raise ValueError

Attached is a patch against the current hg head that makes sure module loaders are invoked through _call_with_frames_removed, so that the output becomes a lot more readable:

Traceback (most recent call last):
  File "/Users/mark/Development/Projects/rave/rave/bootstrap/__init__.py", line 102, in bootstrap_game
    __import__(MODULE_PACKAGE + '.' + mod.replace('.py', ''))
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module
    super().exec_module(module)
  File "/.modules/opengl/__init__.py", line 1, in <module>
    from . import common, core3
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module
    super().exec_module(module)
  File "/.modules/opengl/core3/__init__.py", line 11, in <module>
    from .texture import Texture, Image
  File "/Users/mark/Development/Projects/rave/rave/modularity.py", line 23, in exec_module
    super().exec_module(module)
  File "/.modules/opengl/core3/texture.py", line 8, in <module>
    raise ValueError
ValueError

Ideally it would remove the calls /within/ the module loader itself too, but I do not see an easy way to do this without changing the entire _call_with_frames_removed semantics. This fixes most of the issues, though.

----------
components: Library (Lib)
files: cpython-3ac58de829ef-fix-external-module-loader-call-traceback.patch
keywords: patch
messages: 239219
nosy: shiz
priority: normal
severity: normal
status: open
title: importlib does not properly remove frames when invoking external import hooks
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38681/cpython-3ac58de829ef-fix-external-module-loader-call-traceback.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23773>
_______________________________________

From report at bugs.python.org  Wed Mar 25 07:21:57 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 06:21:57 +0000
Subject: [issue23573] Avoid redundant allocations in str.find and like
In-Reply-To: <1427249978.46.0.948136706723.issue23573@psf.upfronthosting.co.za>
Message-ID: <5046143.15ca9vEqOO@raxxla>


Serhiy Storchaka added the comment:

Many thanks Victor for fixing crashes. Unfortunately I couldn't reproduce a 
crash on my computers, perhaps it is was 64-bit only.

Yes, I'll look how the code can be optimized.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23573>
_______________________________________

From report at bugs.python.org  Wed Mar 25 07:29:15 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Mar 2015 06:29:15 +0000
Subject: [issue23765] Remove IsBadStringPtr calls in ctypes
In-Reply-To: <1427222345.86.0.728447674961.issue23765@psf.upfronthosting.co.za>
Message-ID: <20150325062912.120036.4978@psf.io>


Roundup Robot added the comment:

New changeset 585e555247ac by Steve Dower in branch 'default':
Issue #23765: Remove IsBadStringPtr calls in ctypes
https://hg.python.org/cpython/rev/585e555247ac

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23765>
_______________________________________

From report at bugs.python.org  Wed Mar 25 07:29:53 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 25 Mar 2015 06:29:53 +0000
Subject: [issue23765] Remove IsBadStringPtr calls in ctypes
In-Reply-To: <1427222345.86.0.728447674961.issue23765@psf.upfronthosting.co.za>
Message-ID: <1427264993.05.0.250541424164.issue23765@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at microsoft.com>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23765>
_______________________________________

From report at bugs.python.org  Wed Mar 25 07:32:35 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 25 Mar 2015 06:32:35 +0000
Subject: [issue23314] Disabling CRT asserts in debug build
In-Reply-To: <1422142044.09.0.973511381337.issue23314@psf.upfronthosting.co.za>
Message-ID: <1427265155.26.0.254103716145.issue23314@psf.upfronthosting.co.za>


Steve Dower added the comment:

I haven't seen any of these in a while, and the buildbot at http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x (the only one running VS 2015 right now AFAIK) hasn't either, so I'm calling this fixed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23314>
_______________________________________

From report at bugs.python.org  Wed Mar 25 07:36:23 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 25 Mar 2015 06:36:23 +0000
Subject: [issue23465] Implement PEP 486 - Make the Python Launcher aware of
 virtual environments
In-Reply-To: <1423925955.39.0.302643429195.issue23465@psf.upfronthosting.co.za>
Message-ID: <1427265383.49.0.979494855604.issue23465@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at microsoft.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23465>
_______________________________________

From report at bugs.python.org  Wed Mar 25 07:36:59 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Mar 2015 06:36:59 +0000
Subject: [issue9445] Fix undefined symbol errors on VS8.0 build
In-Reply-To: <1280627576.04.0.298775706484.issue9445@psf.upfronthosting.co.za>
Message-ID: <20150325063655.82156.67085@psf.io>


Roundup Robot added the comment:

New changeset d094eeeb1496 by Steve Dower in branch 'default':
Closes #9445: Removes detection of GetFinalPathNameByHandle
https://hg.python.org/cpython/rev/d094eeeb1496

----------
nosy: +python-dev
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9445>
_______________________________________

From report at bugs.python.org  Wed Mar 25 07:40:47 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 25 Mar 2015 06:40:47 +0000
Subject: [issue22904] make profile-opt includes -fprofile* flags in
 _sysconfigdata CFLAGS
In-Reply-To: <1416437734.43.0.575909256617.issue22904@psf.upfronthosting.co.za>
Message-ID: <1427265647.39.0.423230560244.issue22904@psf.upfronthosting.co.za>


Ned Deily added the comment:

Slavek, this issue and its superseder are both closed so comments here will likely not be acted on.

----------
nosy: +ned.deily
stage: needs patch -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22904>
_______________________________________

From report at bugs.python.org  Wed Mar 25 07:41:36 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 25 Mar 2015 06:41:36 +0000
Subject: [issue23774] Test failures when unable to write to install location
Message-ID: <1427265696.1.0.371099529167.issue23774@psf.upfronthosting.co.za>


New submission from Steve Dower:

The following tests fail when run in an all-users installation because they cannot write to the install directory:

test_compileall test_tcl test_tools test_zipfile

See the attached file for traces.

>From Ned Deily:
Regarding tests trying to write into the install directory tree, I'm pretty sure that there have been fixes added for those but I can't recall off the top of my head specific examples.  I think the best approach is to use a temporary, writable directory instead; if that's not practical, then the test case should be skipped.  I support fixing any tests that still currently fail due to this.

(New issue cloned from discussion on #23619)

----------
components: Tests, Windows
files: 35a2-failures.txt
messages: 239225
nosy: ned.deily, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Test failures when unable to write to install location
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38682/35a2-failures.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23774>
_______________________________________

From report at bugs.python.org  Wed Mar 25 07:42:14 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 25 Mar 2015 06:42:14 +0000
Subject: [issue23619] Python 3.5.0a2 installer fails on Windows
In-Reply-To: <1425896617.91.0.543795000231.issue23619@psf.upfronthosting.co.za>
Message-ID: <1427265734.37.0.610347582951.issue23619@psf.upfronthosting.co.za>


Steve Dower added the comment:

Migrated the test failures to #23774 and closing this.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23619>
_______________________________________

From report at bugs.python.org  Wed Mar 25 07:49:07 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 06:49:07 +0000
Subject: [issue23763] Chain exceptions in C
In-Reply-To: <1427208097.93.0.892198283241.issue23763@psf.upfronthosting.co.za>
Message-ID: <1427266147.07.0.711306102943.issue23763@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think it would be safer to defer automatically chaining exceptions to 3.6. After releasing 3.5 we can got reports about exceptions ignored by mistake. After fixing all bugs not covered by the testsuite, we could try automatically chain exceptions. May be this will require longer transient period, 3.6-3.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23763>
_______________________________________

From report at bugs.python.org  Wed Mar 25 07:51:22 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 25 Mar 2015 06:51:22 +0000
Subject: [issue21319] WindowsRegistryFinder never added to sys.meta_path
In-Reply-To: <1398056666.81.0.531490496163.issue21319@psf.upfronthosting.co.za>
Message-ID: <1427266282.12.0.0986755770994.issue21319@psf.upfronthosting.co.za>


Steve Dower added the comment:

I've seen some module paths be registered there, but no, it doesn't really get used much (maybe because it's been broken?) os.name is certainly the right test here.

FWIW, I'd rather be prioritising file system over registry for finding packages anyway. It makes it much easier to set up app-local installs of Python (there are also conflicts between e.g. Canopy and CPython virtual environments because of the registry...). I know this is mostly getpath.c's fault and not importlib though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21319>
_______________________________________

From report at bugs.python.org  Wed Mar 25 07:53:00 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 25 Mar 2015 06:53:00 +0000
Subject: [issue23767] Library and include paths not added when cross compiling
 on localized sytem
In-Reply-To: <1427227440.25.0.884604694697.issue23767@psf.upfronthosting.co.za>
Message-ID: <1427266380.98.0.930804614339.issue23767@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +doko
stage:  -> patch review
versions: +Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23767>
_______________________________________

From report at bugs.python.org  Wed Mar 25 07:57:21 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 25 Mar 2015 06:57:21 +0000
Subject: [issue19351] python msi installers - silent mode
In-Reply-To: <1382450332.98.0.946317884841.issue19351@psf.upfronthosting.co.za>
Message-ID: <1427266641.09.0.137853473421.issue19351@psf.upfronthosting.co.za>


Steve Dower added the comment:

I'm not exactly sure how msiexec does its parsing, but it's possible that ALLUSERS="1" may not actually be the same as ALLUSERS=1. I use the latter regularly with most versions of Python in existence and it works fine.

There may also be problems upgrading from the previous installation. If you run the old installers then they may offer to remove Python, even if it doesn't show up in Programs and Features.

----------
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19351>
_______________________________________

From report at bugs.python.org  Wed Mar 25 07:57:57 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 25 Mar 2015 06:57:57 +0000
Subject: [issue23773] importlib does not properly remove frames when invoking
 external import hooks
In-Reply-To: <1427254138.42.0.76544892287.issue23773@psf.upfronthosting.co.za>
Message-ID: <1427266677.79.0.904840208989.issue23773@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +brett.cannon
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23773>
_______________________________________

From report at bugs.python.org  Wed Mar 25 07:59:25 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 25 Mar 2015 06:59:25 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multiple installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1427266765.11.0.433191645593.issue23546@psf.upfronthosting.co.za>


Steve Dower added the comment:

I've committed a change that adds a submenu for IDLE almost exactly like Liam's mockup.

Thanks for pushing me on this, I probably wouldn't have worked this hard to get something as robust otherwise :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Wed Mar 25 08:42:43 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Mar 2015 07:42:43 +0000
Subject: [issue21717] Exclusive mode for ZipFile and TarFile
In-Reply-To: <1402482380.66.0.687307266587.issue21717@psf.upfronthosting.co.za>
Message-ID: <1427269363.09.0.271548390624.issue21717@psf.upfronthosting.co.za>


Berker Peksag added the comment:

LGTM. I left two minor comments on Rietveld. Sorry for the delay.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21717>
_______________________________________

From report at bugs.python.org  Wed Mar 25 08:46:59 2015
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 25 Mar 2015 07:46:59 +0000
Subject: [issue20181] Derby #12: Convert 50 sites to Argument Clinic across 4
 files
In-Reply-To: <1389140203.53.0.198441160626.issue20181@psf.upfronthosting.co.za>
Message-ID: <1427269619.39.0.156418217793.issue20181@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I read it quickly.  It looks basically okay, but I have one issue to discuss right now.  Changing from the format unit 'O!' and calling "getuchar" to the format unit 'C' means a change in semantics.  The text in the exception will change.  Unfortunately, people do depend on that in real-world code.

It'd be nice if we could change those semantics; this won't ship until 3.5 so maybe it's okay.  I don't know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20181>
_______________________________________

From report at bugs.python.org  Wed Mar 25 08:53:41 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 07:53:41 +0000
Subject: [issue23763] Chain exceptions in C
In-Reply-To: <1427266147.07.0.711306102943.issue23763@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaygdzVKFzEPRXckmxaa3pSFzN+B0_7U_2V6x0PP00-Mw@mail.gmail.com>


STINNER Victor added the comment:

Le mercredi 25 mars 2015, Serhiy Storchaka <report at bugs.python.org> a
?crit :
>
> I think it would be safer to defer automatically chaining exceptions to
> 3.6. After releasing 3.5 we can got reports about exceptions ignored by
> mistake.
>

Hum, what change can ignore exceptions by mistake?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23763>
_______________________________________

From report at bugs.python.org  Wed Mar 25 08:54:56 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 07:54:56 +0000
Subject: [issue23775] Fix pprint of OrderedDict
Message-ID: <1427270096.56.0.104555413271.issue23775@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently pprint prints the repr of OrderedDict if it fits in one line, and prints the repr of dict if it is wrapped.

>>> import collections, pprint
>>> pprint.pprint(collections.OrderedDict([(4, 3), (2, 1)]))
OrderedDict([(4, 3), (2, 1)])
>>> pprint.pprint(collections.OrderedDict([(4, 3), (2, 1)]), width=25)
{4: 3,
 2: 1}

Proposed patch makes pprint always produce an output compatible with OrderedDict's repr.

>>> pprint.pprint(collections.OrderedDict([(4, 3), (2, 1)]), width=25)
OrderedDict([(4, 3),
             (2, 1)])

----------
assignee: serhiy.storchaka
components: Library (Lib)
files: pprint_ordered_dict.patch
keywords: patch
messages: 239234
nosy: fdrake, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix pprint of OrderedDict
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38683/pprint_ordered_dict.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23775>
_______________________________________

From report at bugs.python.org  Wed Mar 25 09:10:26 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Mar 2015 08:10:26 +0000
Subject: [issue21717] Exclusive mode for ZipFile and TarFile
In-Reply-To: <1402482380.66.0.687307266587.issue21717@psf.upfronthosting.co.za>
Message-ID: <20150325081023.30740.52790@psf.io>


Roundup Robot added the comment:

New changeset b2a8c30d8ddb by Serhiy Storchaka in branch 'default':
Issue #21717: The zipfile.ZipFile.open function now supports 'x' (exclusive
https://hg.python.org/cpython/rev/b2a8c30d8ddb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21717>
_______________________________________

From report at bugs.python.org  Wed Mar 25 09:11:46 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 08:11:46 +0000
Subject: [issue21717] Exclusive mode for ZipFile and TarFile
In-Reply-To: <1402482380.66.0.687307266587.issue21717@psf.upfronthosting.co.za>
Message-ID: <1427271106.96.0.918799169279.issue21717@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21717>
_______________________________________

From report at bugs.python.org  Wed Mar 25 09:25:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 08:25:28 +0000
Subject: [issue20181] Derby #12: Convert 50 sites to Argument Clinic across 4
 files
In-Reply-To: <1389140203.53.0.198441160626.issue20181@psf.upfronthosting.co.za>
Message-ID: <1427271928.64.0.665277905014.issue20181@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The only difference is in error message.

For now:

>>> unicodedata.name(123)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be str, not int
>>> unicodedata.name('123')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: need a single Unicode character as parameter

Patched:

>>> unicodedata.name(123)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be a unicode character, not int
>>> unicodedata.name('123')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be a unicode character, not str

If you think old messages were better, we can change standard error messages for 'C' format unit. We already changed standard and specialized error messages in 3.5 and earlier. In 3.4 it looks as:

>>> unicodedata.name(123)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be str, not int
>>> unicodedata.name('123')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: need a single Unicode character as parameter

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20181>
_______________________________________

From report at bugs.python.org  Wed Mar 25 09:39:29 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 08:39:29 +0000
Subject: [issue23774] Test failures when unable to write to install location
In-Reply-To: <1427265696.1.0.371099529167.issue23774@psf.upfronthosting.co.za>
Message-ID: <1427272769.88.0.996104967043.issue23774@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is a guard for zipfile tests (requiresWriteAccess). The question is why it doesn't work for this test but works for other tests.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23774>
_______________________________________

From report at bugs.python.org  Wed Mar 25 10:15:11 2015
From: report at bugs.python.org (Robert Kuska)
Date: Wed, 25 Mar 2015 09:15:11 +0000
Subject: [issue23769] valgrind reports leaks for test_zipimport
In-Reply-To: <1427236334.27.0.200472101868.issue23769@psf.upfronthosting.co.za>
Message-ID: <1427274911.3.0.293621781585.issue23769@psf.upfronthosting.co.za>


Robert Kuska added the comment:

I tried leak2.py with valgrind, I've uncommented the lines you mentioned.

> $ valgrind python3 leak2.py                                                                                                                                                                   
==28421== Memcheck, a memory error detector
==28421== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==28421== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==28421== Command: python3 leak2.py
==28421== 
==28421== 
==28421== HEAP SUMMARY:
==28421==     in use at exit: 1,599,354 bytes in 11,594 blocks
==28421==   total heap usage: 284,971 allocs, 273,377 frees, 37,976,898 bytes allocated
==28421== 
==28421== LEAK SUMMARY:
==28421==    definitely lost: 0 bytes in 0 blocks
==28421==    indirectly lost: 0 bytes in 0 blocks
==28421==      possibly lost: 597,482 bytes in 2,319 blocks
==28421==    still reachable: 1,001,872 bytes in 9,275 blocks
==28421==         suppressed: 0 bytes in 0 blocks
==28421== Rerun with --leak-check=full to see details of leaked memory
==28421== 
==28421== For counts of detected and suppressed errors, rerun with: -v
==28421== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I've removed `import readline` from leak2.py, everything else left as in previous run (also ofc removed tracemalloc).

> $ valgrind python3 leak3.py                                                                                                                                                                  
==28515== Memcheck, a memory error detector
==28515== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==28515== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==28515== Command: python3 leak2.py
==28515== 
==28515== 
==28515== HEAP SUMMARY:
==28515==     in use at exit: 1,599,384 bytes in 11,595 blocks
==28515==   total heap usage: 285,648 allocs, 274,053 frees, 38,126,379 bytes allocated
==28515== 
==28515== LEAK SUMMARY:
==28515==    definitely lost: 30 bytes in 1 blocks
==28515==    indirectly lost: 0 bytes in 0 blocks
==28515==      possibly lost: 597,375 bytes in 2,317 blocks
==28515==    still reachable: 1,001,979 bytes in 9,277 blocks
==28515==         suppressed: 0 bytes in 0 blocks
==28515== Rerun with --leak-check=full to see details of leaked memory
==28515== 
==28515== For counts of detected and suppressed errors, rerun with: -v
==28515== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


Duh? Why does readline have this effect?

----------
Added file: http://bugs.python.org/file38684/leak3.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23769>
_______________________________________

From report at bugs.python.org  Wed Mar 25 10:24:13 2015
From: report at bugs.python.org (eryksun)
Date: Wed, 25 Mar 2015 09:24:13 +0000
Subject: [issue23765] Remove IsBadStringPtr calls in ctypes
In-Reply-To: <1427222345.86.0.728447674961.issue23765@psf.upfronthosting.co.za>
Message-ID: <1427275453.18.0.284487534801.issue23765@psf.upfronthosting.co.za>


eryksun added the comment:

c_char_p.__repr__ (defined in __init__.py) also checks IsBadStringPtrA via FFI. 

Defining the repr differently on Windows is a wart, IMO. The following repr should be used on all platforms for c_char_p:

    "%s(%s)" % (self.__class__.__name__, 
                c_void_p.from_buffer(self).value)

On a related note, wide-character c_wchar_p uses the default _SimpleCData.__repr__, which calls the getfunc. It should be overridden in the same manner as c_char_p because this can easily segfault Python on a non-Windows platform. Even on Windows, calling IsBadStringPtrW in Z_get can't make guarantees given multiple threads. The GIL helps, but with ctypes there's a good chance that many threads are running concurrently.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23765>
_______________________________________

From report at bugs.python.org  Wed Mar 25 10:29:19 2015
From: report at bugs.python.org (Paul Moore)
Date: Wed, 25 Mar 2015 09:29:19 +0000
Subject: [issue21319] WindowsRegistryFinder never added to sys.meta_path
In-Reply-To: <1398056666.81.0.531490496163.issue21319@psf.upfronthosting.co.za>
Message-ID: <1427275759.56.0.825099096126.issue21319@psf.upfronthosting.co.za>


Paul Moore added the comment:

I think the main (only?) user of having sys.path entries in the registry is pywin32. It might be worth asking them if they can switch to a more mainstream approach, and then maybe the whole registry finder thing can be removed completely.

----------
nosy: +paul.moore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21319>
_______________________________________

From report at bugs.python.org  Wed Mar 25 10:37:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 09:37:42 +0000
Subject: [issue23776] Don't use assert for checking arguments in pprint
Message-ID: <1427276262.37.0.171943179164.issue23776@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The assert statement should be used only for checking internal logic, and not for checking user data. These assertions should be either removed or converted into explicit raising ValueError.

----------
components: Library (Lib)
messages: 239241
nosy: fdrake, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Don't use assert for checking arguments in pprint
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23776>
_______________________________________

From report at bugs.python.org  Wed Mar 25 10:37:56 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 09:37:56 +0000
Subject: [issue23776] Don't use assert for checking arguments in pprint
In-Reply-To: <1427276262.37.0.171943179164.issue23776@psf.upfronthosting.co.za>
Message-ID: <1427276276.22.0.957097844341.issue23776@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file38685/pprint_args_check.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23776>
_______________________________________

From report at bugs.python.org  Wed Mar 25 10:46:08 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Mar 2015 09:46:08 +0000
Subject: [issue23712] Experiment: Assume that exact unicode hashes are perfect
 discriminators
In-Reply-To: <1426795062.72.0.102774381262.issue23712@psf.upfronthosting.co.za>
Message-ID: <1427276768.72.0.570949278602.issue23712@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Given interned strings can already be compared by pointer, I'd recommend people call sys.intern() on their strings if they want really fast equality comparisons.

----------
nosy: +pitrou, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23712>
_______________________________________

From report at bugs.python.org  Wed Mar 25 10:55:53 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Mar 2015 09:55:53 +0000
Subject: [issue23776] Don't use assert for checking arguments in pprint
In-Reply-To: <1427276262.37.0.171943179164.issue23776@psf.upfronthosting.co.za>
Message-ID: <1427277353.25.0.0978390780149.issue23776@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Looks good. Two things:

* I'd apply this only to the default branch. Changing exceptions from AssertionError to ValueError in bugfix releases may break third party code. I couldn't find a similar bug report in the tracker, so it's probably not worth to take that risk.
* We should audit the standard library for similar issues

----------
assignee:  -> serhiy.storchaka
nosy: +berker.peksag
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23776>
_______________________________________

From report at bugs.python.org  Wed Mar 25 11:18:29 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 10:18:29 +0000
Subject: [issue23776] Don't use assert for checking arguments in pprint
In-Reply-To: <1427276262.37.0.171943179164.issue23776@psf.upfronthosting.co.za>
Message-ID: <1427278709.23.0.820083532385.issue23776@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Similar issues are issue8361 and issue17840.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23776>
_______________________________________

From report at bugs.python.org  Wed Mar 25 11:20:25 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 25 Mar 2015 10:20:25 +0000
Subject: [issue23529] Limit decompressed data when reading from LZMAFile and
 BZ2File
In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za>
Message-ID: <1427278825.03.0.463354967143.issue23529@psf.upfronthosting.co.za>


Martin Panter added the comment:

Another behaviour change in v7 is the seekable() return value is now inherited from underlying file, instead of always being True. I mentioned on Reitveld why this could be a bad idea, but as it is undocumented and untested and will leave the new behaviour unless someone complains.

Posting v8, with these changes from v7:

* Reverted _read_exact() and read() loop changes to fix tests
* Restored myfileobj attribute and test that it is closed
* Clean up gzip read() loop so that it always returns data if available, rather than raising EOFError
* Document the read(None) is now allowed
* Other minor changes addressing review comments

----------
Added file: http://bugs.python.org/file38686/LZMAFile-etc.v8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23529>
_______________________________________

From report at bugs.python.org  Wed Mar 25 11:26:10 2015
From: report at bugs.python.org (Alexei Romanov)
Date: Wed, 25 Mar 2015 10:26:10 +0000
Subject: [issue23775] Fix pprint of OrderedDict
In-Reply-To: <1427270096.56.0.104555413271.issue23775@psf.upfronthosting.co.za>
Message-ID: <1427279170.44.0.221791241053.issue23775@psf.upfronthosting.co.za>


Changes by Alexei Romanov <drednout.by at gmail.com>:


----------
nosy: +alexei.romanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23775>
_______________________________________

From report at bugs.python.org  Wed Mar 25 11:37:25 2015
From: report at bugs.python.org (SpaceOne)
Date: Wed, 25 Mar 2015 10:37:25 +0000
Subject: [issue23777] argparse subcommand action can't be specified
Message-ID: <1427279845.4.0.291157397861.issue23777@psf.upfronthosting.co.za>


New submission from SpaceOne:

parser.add_subparsers(dest='arguments', action='append')
will raise the following exception:

  File "/usr/lib/python2.7/argparse.py", line 1675, in add_subparsers
    action = parsers_class(option_strings=[], **kwargs)
TypeError: __init__() got an unexpected keyword argument 'prog'

Instead of 'argparse._SubParsersAction' the class 'argparse._AppendAction' is used.
Could maybe fixed by passing the 'action' parameter to the _SubParsersAction class which then instanciates a _AppendAction and somehow uses this internally for further things.

----------
components: Library (Lib)
messages: 239246
nosy: spaceone
priority: normal
severity: normal
status: open
title: argparse subcommand action can't be specified
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23777>
_______________________________________

From report at bugs.python.org  Wed Mar 25 11:44:38 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Mar 2015 10:44:38 +0000
Subject: [issue23777] argparse subcommand action can't be specified
In-Reply-To: <1427279845.4.0.291157397861.issue23777@psf.upfronthosting.co.za>
Message-ID: <1427280278.09.0.458940886122.issue23777@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report. This is a duplicate of issue 23487.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> argparse: add_subparsers 'action' broken
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23777>
_______________________________________

From report at bugs.python.org  Wed Mar 25 11:45:04 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Mar 2015 10:45:04 +0000
Subject: [issue23487] argparse: add_subparsers 'action' broken
In-Reply-To: <1424417043.22.0.71313795028.issue23487@psf.upfronthosting.co.za>
Message-ID: <1427280304.61.0.291616294941.issue23487@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag, spaceone

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23487>
_______________________________________

From report at bugs.python.org  Wed Mar 25 11:49:24 2015
From: report at bugs.python.org (SpaceOne)
Date: Wed, 25 Mar 2015 10:49:24 +0000
Subject: [issue23487] argparse: add_subparsers 'action' broken
In-Reply-To: <1424417043.22.0.71313795028.issue23487@psf.upfronthosting.co.za>
Message-ID: <1427280564.31.0.457142174933.issue23487@psf.upfronthosting.co.za>


SpaceOne added the comment:

In replay to msg238931 from paul j3 (paul.j3) *
> And specifying something other than the default 'store' action class for the arguments of the parsers doesn't make sense.
Of course it makes sense. If you e.g. want the action to be 'append' so that the subparser-name is appended to a already existing list / or to create a new list with the subparser-name as first argument.
E.g.:

parser.add_subparser(dest='foo', action='append')
parser.parse_args('bar').__dict__ == {'foo': ['bar']}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23487>
_______________________________________

From report at bugs.python.org  Wed Mar 25 13:27:41 2015
From: report at bugs.python.org (Bob)
Date: Wed, 25 Mar 2015 12:27:41 +0000
Subject: [issue20160] broken ctypes calling convention on MSVC / 64-bit
 Windows (large structs)
In-Reply-To: <1389087474.06.0.281853443562.issue20160@psf.upfronthosting.co.za>
Message-ID: <1427286461.67.0.260887007353.issue20160@psf.upfronthosting.co.za>


Bob added the comment:

What I see is that structs lager that 8 bytes are not passed correctly to a callback funtion.

I've attached a patchfile that includes my fix and a test to demonstrate the problem.

----------
Added file: http://bugs.python.org/file38687/large_struct_callback.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20160>
_______________________________________

From report at bugs.python.org  Wed Mar 25 14:02:22 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 25 Mar 2015 13:02:22 +0000
Subject: [issue23765] Remove IsBadStringPtr calls in ctypes
In-Reply-To: <1427222345.86.0.728447674961.issue23765@psf.upfronthosting.co.za>
Message-ID: <1427288542.93.0.174898531734.issue23765@psf.upfronthosting.co.za>


Steve Dower added the comment:

Thanks, I forgot to scan .py files.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23765>
_______________________________________

From report at bugs.python.org  Wed Mar 25 14:05:36 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 25 Mar 2015 13:05:36 +0000
Subject: [issue23764] functools.wraps should be able to change function
 argspec as well
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427288736.6.0.212208866326.issue23764@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Correctly processing a function's signature involves following the __wrapped__ chains to get to the underlying callable (or to a callable that defines an explicitly modified __signature__ value).

inspect.signature follows these chains automatically, and in 3.4+ inspect.getargspec and inspect.getfullargspec have been updated to use inspect.signature internally.

Using these functions will also allow introspection of builtin and extension module functions that have been processed through Argument Clinic to produce appropriate signature information in their docstrings.

If an IDE or other tool is still producing incorrect signature information for functions wrapped with functools.wraps in 3.4+ then that's either a bug in the affected tool, or else a bug report against the inspect module.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23764>
_______________________________________

From report at bugs.python.org  Wed Mar 25 14:22:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 13:22:15 +0000
Subject: [issue23712] Experiment: Assume that exact unicode hashes are perfect
 discriminators
In-Reply-To: <1426795062.72.0.102774381262.issue23712@psf.upfronthosting.co.za>
Message-ID: <1427289735.73.0.250848866729.issue23712@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In case of class or module dicts attribute names usually are interned. So no string comparison is needed if the key is found. It is needed only when the key is not found, but found a key with the same hash (with the chance 5e-28). The benefit of optimization is 5e-28 * time of string comparison per key lookup.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23712>
_______________________________________

From report at bugs.python.org  Wed Mar 25 14:23:57 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 25 Mar 2015 13:23:57 +0000
Subject: [issue23773] importlib does not properly remove frames when invoking
 external import hooks
In-Reply-To: <1427254138.42.0.76544892287.issue23773@psf.upfronthosting.co.za>
Message-ID: <1427289837.65.0.945695453646.issue23773@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23773>
_______________________________________

From report at bugs.python.org  Wed Mar 25 14:40:07 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 25 Mar 2015 13:40:07 +0000
Subject: [issue23712] Experiment: Assume that exact unicode hashes are perfect
 discriminators
In-Reply-To: <1426795062.72.0.102774381262.issue23712@psf.upfronthosting.co.za>
Message-ID: <1427290807.68.0.158321626734.issue23712@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

I wouldn't make this the default, since the probability is small, but not zero.

However, it may be worth exploring this as dict sub-type for applications to use which could benefit from it.

For internal strings, we already use interning, so no win there. The probabilistic approach would only make sense for dictionaries which store non-interned Unicode keys and get lots of dict lookups.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23712>
_______________________________________

From report at bugs.python.org  Wed Mar 25 14:41:11 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Mar 2015 13:41:11 +0000
Subject: [issue23766] json.dumps: solidus ("/") should be escaped
In-Reply-To: <1427226223.82.0.96478521351.issue23766@psf.upfronthosting.co.za>
Message-ID: <1427290871.16.0.849453032447.issue23766@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> json encoder does not support JSONP/JavaScript safe escaping

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23766>
_______________________________________

From report at bugs.python.org  Wed Mar 25 14:46:12 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Mar 2015 13:46:12 +0000
Subject: [issue23764] functools.wraps should be able to change function
 argspec as well
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427291172.01.0.918098942497.issue23764@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think you need to explain exactly what it is you are looking for, because it doesn't seem to me that you can change the argspec of a function.  What is it that decorator is doing that is helpful?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23764>
_______________________________________

From report at bugs.python.org  Wed Mar 25 14:49:51 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Mar 2015 13:49:51 +0000
Subject: [issue23743] Python crashes upon exit if importing g++ compiled mod
 after importing gcc compiled mod
In-Reply-To: <1427087434.95.0.234111642557.issue23743@psf.upfronthosting.co.za>
Message-ID: <1427291391.12.0.186112548341.issue23743@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, clearly you are the interested party that solved it :)  Thanks.

Unfortunately I don't know that we have a place where this could be documented, since currently mingw isn't a fully supported platform.  Perhaps in the distutils docs somewhere?

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
type: crash -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23743>
_______________________________________

From report at bugs.python.org  Wed Mar 25 14:53:12 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Wed, 25 Mar 2015 13:53:12 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1427291592.08.0.740301212346.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

Ryan,
>From where do you want me to download Python for testing?
I'm assuming I need to test by a) downloading an unpatched 3.4.2, b) applying patches, c) running ./configure && make && make install.. If this is not correct let me know

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Wed Mar 25 14:54:42 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Mar 2015 13:54:42 +0000
Subject: [issue23774] Test failures when unable to write to install location
In-Reply-To: <1427265696.1.0.371099529167.issue23774@psf.upfronthosting.co.za>
Message-ID: <1427291682.91.0.125609887224.issue23774@psf.upfronthosting.co.za>


R. David Murray added the comment:

We need a buildbot that runs tests on an installed python.  The general problem is not windows-only.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23774>
_______________________________________

From report at bugs.python.org  Wed Mar 25 15:42:00 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Mar 2015 14:42:00 +0000
Subject: [issue23742] expandvars removes single quotes ( ' )
In-Reply-To: <1427074537.6.0.869076773491.issue23742@psf.upfronthosting.co.za>
Message-ID: <20150325144156.120044.88141@psf.io>


Roundup Robot added the comment:

New changeset 9f4d2bdced9c by Serhiy Storchaka in branch '2.7':
Issue #23742: ntpath.expandvars() no longer loses unbalanced single quotes.
https://hg.python.org/cpython/rev/9f4d2bdced9c

New changeset 613c4bd1c29c by Serhiy Storchaka in branch '3.4':
Issue #23742: ntpath.expandvars() no longer loses unbalanced single quotes.
https://hg.python.org/cpython/rev/613c4bd1c29c

New changeset 16e6515c9476 by Serhiy Storchaka in branch 'default':
Issue #23742: ntpath.expandvars() no longer loses unbalanced single quotes.
https://hg.python.org/cpython/rev/16e6515c9476

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23742>
_______________________________________

From report at bugs.python.org  Wed Mar 25 15:44:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 14:44:26 +0000
Subject: [issue23742] expandvars removes single quotes ( ' )
In-Reply-To: <1427074537.6.0.869076773491.issue23742@psf.upfronthosting.co.za>
Message-ID: <1427294666.89.0.532709317228.issue23742@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23742>
_______________________________________

From report at bugs.python.org  Wed Mar 25 15:51:26 2015
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 25 Mar 2015 14:51:26 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1427295086.53.0.728108298347.issue2211@psf.upfronthosting.co.za>


Demian Brecht added the comment:

> it would be better to consolidate the three adjacent versionchanged entries into one

I created the three versionchanged items because there's no visual distinction between the second and third lines and the rest of the doc tests in the rendered output. I've changed it as suggested as you're obviously more familiar with other instances of this, but I would still suggest reverting it to the three individual points if this isn't a docs best practice (or updating the versionchanged CSS class to have some visual distinction between it and the rest of the docs).

----------
Added file: http://bugs.python.org/file38688/http_cookies_morsel_deprecated_set_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Wed Mar 25 16:09:17 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Mar 2015 15:09:17 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1427296157.09.0.641201654222.issue2211@psf.upfronthosting.co.za>


R. David Murray added the comment:

The body of the versionchanged has to be a single paragraph (no blank lines).  Usually we start each sentence on a newline in the source, but it comes out rendered as a single flowed paragraph.  Perhaps eventually someone will add support to Sphinx for unordered lists in a directive, but a single paragraph is good enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Wed Mar 25 16:22:15 2015
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 25 Mar 2015 15:22:15 +0000
Subject: [issue23778] Add a visual distinction to multiline versionchanged
 blocks
Message-ID: <1427296935.3.0.719629949286.issue23778@psf.upfronthosting.co.za>


New submission from Demian Brecht:

This came up during #2211, where a multiline versionchanged entry was suggested. Currently, there is no visual distinction between any but the first line of the description and the rest of the body of the docs. The attached patch adds a consistent level of indentation (30px) to all but the first child. This change makes it much more obvious where the versionchanged block ends and the rest of the docs continue.

----------
assignee: docs at python
components: Documentation
files: versionchanged_indent.patch
keywords: patch
messages: 239261
nosy: demian.brecht, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: Add a visual distinction to multiline versionchanged blocks
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38689/versionchanged_indent.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23778>
_______________________________________

From report at bugs.python.org  Wed Mar 25 16:24:20 2015
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 25 Mar 2015 15:24:20 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1427297060.08.0.11294535378.issue2211@psf.upfronthosting.co.za>


Demian Brecht added the comment:

FWIW, I created #23778 to address the indentation issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Wed Mar 25 16:34:27 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Mar 2015 15:34:27 +0000
Subject: [issue23778] Add a visual distinction to multiline versionchanged
 blocks
In-Reply-To: <1427296935.3.0.719629949286.issue23778@psf.upfronthosting.co.za>
Message-ID: <1427297667.48.0.164338217819.issue23778@psf.upfronthosting.co.za>


R. David Murray added the comment:

Heh, you clearly know more about docutils/css than I do.

I don't think we want multiple blank delimited paragraphs under a versionchanged directive, though, from a style point of view.  A compact unordered list would be best.

----------
nosy: +georg.brandl, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23778>
_______________________________________

From report at bugs.python.org  Wed Mar 25 16:41:20 2015
From: report at bugs.python.org (Ryan Gonzalez)
Date: Wed, 25 Mar 2015 15:41:20 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1427298080.62.0.309307773567.issue23496@psf.upfronthosting.co.za>


Ryan Gonzalez added the comment:

No; you need the CPython tip. You can use https://github.com/python/cpython. Other than that, it's the configure+make thing.

As I said before, the pyconfig.h changes aren't there yet. Trying to figure out how I want to approach those.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Wed Mar 25 16:53:06 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 25 Mar 2015 15:53:06 +0000
Subject: [issue23743] Python crashes upon exit if importing g++ compiled mod
 after importing gcc compiled mod
In-Reply-To: <1427087434.95.0.234111642557.issue23743@psf.upfronthosting.co.za>
Message-ID: <1427298786.99.0.241317905648.issue23743@psf.upfronthosting.co.za>


Steve Dower added the comment:

I think these days as soon as a repro includes "import distutils" or "import setuptools" the docs go straight to http://pypa.io :)

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23743>
_______________________________________

From report at bugs.python.org  Wed Mar 25 17:15:11 2015
From: report at bugs.python.org (Tim Golden)
Date: Wed, 25 Mar 2015 16:15:11 +0000
Subject: [issue21319] WindowsRegistryFinder never added to sys.meta_path
In-Reply-To: <1427275759.56.0.825099096126.issue21319@psf.upfronthosting.co.za>
Message-ID: <5512DF0B.3080502@timgolden.me.uk>


Tim Golden added the comment:

I think they stopped using them a while back in favour of a pywin32.pth
file.

I don't think I even knew you could use the registry for sys.path.

If no-one's shouted since the changes to importlib (which was 3.3?) I
think we can quietly drop this and hope no-one notices...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21319>
_______________________________________

From report at bugs.python.org  Wed Mar 25 17:15:52 2015
From: report at bugs.python.org (Tim Golden)
Date: Wed, 25 Mar 2015 16:15:52 +0000
Subject: [issue21319] WindowsRegistryFinder never added to sys.meta_path
In-Reply-To: <1398056666.81.0.531490496163.issue21319@psf.upfronthosting.co.za>
Message-ID: <1427300152.49.0.558235892655.issue21319@psf.upfronthosting.co.za>


Tim Golden added the comment:

Adding Mark Hammond in case I'm wrong about the (lack of) impact on pywin32

----------
nosy: +mhammond

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21319>
_______________________________________

From report at bugs.python.org  Wed Mar 25 17:23:56 2015
From: report at bugs.python.org (paul j3)
Date: Wed, 25 Mar 2015 16:23:56 +0000
Subject: [issue23487] argparse: add_subparsers 'action' broken
In-Reply-To: <1424417043.22.0.71313795028.issue23487@psf.upfronthosting.co.za>
Message-ID: <1427300636.98.0.928900497665.issue23487@psf.upfronthosting.co.za>


paul j3 added the comment:

OK, so you are thinking about what happens to the subparsers `dest` when the user names a command.  That isn't handled by the `store` action, but by the call of the subparsers action

    class _SubParsersAction(Action):    
        ....
        def __call__
            ....
            # set the parser name if requested
                if self.dest is not SUPPRESS:
                    setattr(namespace, self.dest, parser_name)
            ...
            namespace, arg_strings = parser.parse_known_args(arg_strings, namespace)

Storing the parser_name is a minor part of this action.  The important, distinctive part is passing the parsing action to that subparser.

That storing could be done in an append way, but why?  There can only one `subparsers`, and it can be invoked only once.

None of the existing Action classes can replace _SubParsersAction, which is entered in the `registry` as `parsers`:

    In [11]: parser._registry_get('action','parsers')
    Out[11]: argparse._SubParsersAction
 
If you want to write your own version of this action, you can use it, either by replacing the existing class, or by changing this registry entry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23487>
_______________________________________

From report at bugs.python.org  Wed Mar 25 17:24:29 2015
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 25 Mar 2015 16:24:29 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1427300669.2.0.0640445670997.issue2211@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Problem (pretty much) solved. Nested unordered lists are supported. I've updated the versionchanged information to use the list.

----------
Added file: http://bugs.python.org/file38690/http_cookies_morsel_deprecated_set_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Wed Mar 25 17:27:33 2015
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 25 Mar 2015 16:27:33 +0000
Subject: [issue23778] Add a visual distinction to multiline versionchanged
 blocks
In-Reply-To: <1427296935.3.0.719629949286.issue23778@psf.upfronthosting.co.za>
Message-ID: <1427300853.78.0.308229059806.issue23778@psf.upfronthosting.co.za>


Demian Brecht added the comment:

I noted in #2211 that nested lists are supported by Sphinx, so that solves that specific issue. Perhaps it /may/ still be useful to have this though in order to support multiple paragraphs for more detailed change descriptions when needed? That said, I'm not sure that's something that's necessarily even wanted as such messages are intended to be terse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23778>
_______________________________________

From report at bugs.python.org  Wed Mar 25 17:30:12 2015
From: report at bugs.python.org (paul j3)
Date: Wed, 25 Mar 2015 16:30:12 +0000
Subject: [issue23487] argparse: add_subparsers 'action' broken
In-Reply-To: <1424417043.22.0.71313795028.issue23487@psf.upfronthosting.co.za>
Message-ID: <1427301012.1.0.114743750655.issue23487@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23487>
_______________________________________

From report at bugs.python.org  Wed Mar 25 17:30:17 2015
From: report at bugs.python.org (Tim Graham)
Date: Wed, 25 Mar 2015 16:30:17 +0000
Subject: [issue22931] cookies with square brackets in value
In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za>
Message-ID: <1427301017.55.0.556881984927.issue22931@psf.upfronthosting.co.za>


Tim Graham added the comment:

Will this regression be fixed in Python 2.7, 3.2, and 3.3? If not, Django may need to vendor Python's cookie class to workaround this bug to prevent users from losing sessions and/or being unable to login to Django powered sites as reported in https://code.djangoproject.com/ticket/24492.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22931>
_______________________________________

From report at bugs.python.org  Wed Mar 25 17:33:04 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Mar 2015 16:33:04 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1427301184.48.0.412477164539.issue2211@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I think David's suggestion in msg239260 was good enough for now :) You'll need to create a custom versionchanged directive to generate a valid and semantic markup for the usage in http_cookies_morsel_deprecated_set_2.patch. I also left a couple comments on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Wed Mar 25 17:42:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Mar 2015 16:42:01 +0000
Subject: [issue23778] Add a visual distinction to multiline versionchanged
 blocks
In-Reply-To: <1427296935.3.0.719629949286.issue23778@psf.upfronthosting.co.za>
Message-ID: <1427301721.4.0.108650111597.issue23778@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, exactly, they are supposed to be terse.  So I think we should reject this.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23778>
_______________________________________

From report at bugs.python.org  Wed Mar 25 17:48:06 2015
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 25 Mar 2015 16:48:06 +0000
Subject: [issue23778] Add a visual distinction to multiline versionchanged
 blocks
In-Reply-To: <1427296935.3.0.719629949286.issue23778@psf.upfronthosting.co.za>
Message-ID: <1427302086.25.0.322771668829.issue23778@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Sounds good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23778>
_______________________________________

From report at bugs.python.org  Wed Mar 25 17:53:44 2015
From: report at bugs.python.org (paul j3)
Date: Wed, 25 Mar 2015 16:53:44 +0000
Subject: [issue23487] argparse: add_subparsers 'action' broken
In-Reply-To: <1424417043.22.0.71313795028.issue23487@psf.upfronthosting.co.za>
Message-ID: <1427302424.38.0.707435715743.issue23487@psf.upfronthosting.co.za>


paul j3 added the comment:

As to the nature of the error when 'add_subparsers' is given an 'action' parameter:

'add_subparsers' does several things to 'kwargs' before it passes them to the relevant Action class.

     def add_subparsers(self, **kwargs):
        # adds 'parser_class'
        # removes 'title', 'description' (used in an argument group)
        # add 'prog'
        parsers_class = self._pop_action_class(kwargs, 'parsers')
        action = parsers_class(option_strings=[], **kwargs)

What I wrote earlier about using the registry is partly wrong.  The Action class is determined by either the 'action' parameter or the registry entry.

     In [17]: p._pop_action_class({}, 'parsers')
     Out[17]: argparse._SubParsersAction

     In [18]: p._pop_action_class({'action':'test'}, 'parsers')
     Out[18]: 'test'

So the 'action' parameter works - if you specify a compatible Action class.

    sp=p.add_subparsers(dest='cmd',action=argparse._SubParsersAction)

Such a class must have the same __init__ signature, otherwise you'll get errors such the OP's.

It might be worth rewriting the documentation line so this is clearer.  Otherwise I recommend closing this issue.






     action = parsers_class(option_strings=[], **kwargs)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23487>
_______________________________________

From report at bugs.python.org  Wed Mar 25 18:31:41 2015
From: report at bugs.python.org (Dan O'Reilly)
Date: Wed, 25 Mar 2015 17:31:41 +0000
Subject: [issue8800] add threading.RWLock
In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za>
Message-ID: <1427304701.15.0.700274810237.issue8800@psf.upfronthosting.co.za>


Changes by Dan O'Reilly <oreilldf at gmail.com>:


----------
nosy: +dan.oreilly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8800>
_______________________________________

From report at bugs.python.org  Wed Mar 25 19:04:37 2015
From: report at bugs.python.org (Liam Marsh)
Date: Wed, 25 Mar 2015 18:04:37 +0000
Subject: [issue23546] Windows, 'Edit withIDLE', and multiple installed versions
In-Reply-To: <1425110367.06.0.532868119558.issue23546@psf.upfronthosting.co.za>
Message-ID: <1427306677.19.0.717722519261.issue23546@psf.upfronthosting.co.za>


Liam Marsh added the comment:

thank you for all this hard work.
really.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23546>
_______________________________________

From report at bugs.python.org  Wed Mar 25 19:16:02 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Mar 2015 18:16:02 +0000
Subject: [issue17305] IDNA2008 encoding missing
In-Reply-To: <1361928766.42.0.728949411958.issue17305@psf.upfronthosting.co.za>
Message-ID: <1427307362.41.0.284625401181.issue17305@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
versions: +Python 3.5 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17305>
_______________________________________

From report at bugs.python.org  Wed Mar 25 19:32:19 2015
From: report at bugs.python.org (Josiah Carlson)
Date: Wed, 25 Mar 2015 18:32:19 +0000
Subject: [issue1191964] add non-blocking read and write methods to
 subprocess.Popen
Message-ID: <1427308339.85.0.885121028309.issue1191964@psf.upfronthosting.co.za>


Josiah Carlson added the comment:

I'm going to be honest; seeing None being returned from a pipe read feels *really* broken to me. When I get None returned from an IO read operation, my first instinct is "there can't be anything else coming, why else would it return None?"

After changing writing to raise BrokenPipeError on a closed pipe, I've also changed reading to do the same and added a test to verify the behavior.

----------
Added file: http://bugs.python.org/file38691/subprocess_8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1191964>
_______________________________________

From report at bugs.python.org  Wed Mar 25 19:46:52 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 18:46:52 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>
Message-ID: <1427309212.75.0.848557044566.issue22609@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch for UserDict, that keep current behavior, but allows to pass keys "self" and "dict" if positional parameter dict is specified.

>>> UserDict(self=42)
{'self': 42}
>>> UserDict({}, dict=42)
{'dict': 42}
>>> UserDict(dict={'a': 42})
{'a': 42}

----------
Added file: http://bugs.python.org/file38692/UserDict_self_and_dict_keywords.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22609>
_______________________________________

From report at bugs.python.org  Wed Mar 25 20:04:39 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Mar 2015 19:04:39 +0000
Subject: [issue22364] Improve some re error messages using regex for hints
In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za>
Message-ID: <20150325190436.7509.61876@psf.io>


Roundup Robot added the comment:

New changeset 068365acbe73 by Serhiy Storchaka in branch 'default':
Issue #22364: Improved some re error messages using regex for hints.
https://hg.python.org/cpython/rev/068365acbe73

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22364>
_______________________________________

From report at bugs.python.org  Wed Mar 25 20:05:44 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 19:05:44 +0000
Subject: [issue22364] Improve some re error messages using regex for hints
In-Reply-To: <1410178976.27.0.421938794422.issue22364@psf.upfronthosting.co.za>
Message-ID: <1427310344.33.0.358292091539.issue22364@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22364>
_______________________________________

From report at bugs.python.org  Wed Mar 25 20:56:08 2015
From: report at bugs.python.org (Akira Li)
Date: Wed, 25 Mar 2015 19:56:08 +0000
Subject: [issue1191964] add non-blocking read and write methods to
 subprocess.Popen
Message-ID: <1427313368.37.0.616039602945.issue1191964@psf.upfronthosting.co.za>


Akira Li added the comment:

> I'm going to be honest; seeing None being returned from a pipe read feels *really* broken to me. When I get None returned from an IO read operation, my first instinct is "there can't be anything else coming, why else would it return None?"

It is how it is done in similar cases (returning `None` to indicate 
"would block"). Do you know a better method that would allow to 
distinguish between EOF (no future data, ever) and "would block"
(future data possible) without calling process.poll()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1191964>
_______________________________________

From report at bugs.python.org  Wed Mar 25 21:53:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 20:53:55 +0000
Subject: [issue433028] SRE: (?flag:...) is not supported
Message-ID: <1427316835.68.0.095845561027.issue433028@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated to the tip.

Could anyone please help with documentation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue433028>
_______________________________________

From report at bugs.python.org  Wed Mar 25 21:54:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Mar 2015 20:54:17 +0000
Subject: [issue433028] SRE: (?flag:...) is not supported
Message-ID: <1427316857.08.0.943311075528.issue433028@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file38693/re_scoped_flags_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue433028>
_______________________________________

From report at bugs.python.org  Wed Mar 25 22:55:30 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 Mar 2015 21:55:30 +0000
Subject: [issue1191964] add non-blocking read and write methods to
 subprocess.Popen
In-Reply-To: <1427313368.37.0.616039602945.issue1191964@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaVWm14LZmcf1qW5t1zz=k2KO559dm5XVBOrMcw22VmxQ@mail.gmail.com>


STINNER Victor added the comment:

Returning None for non blocking I/O is standard in Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1191964>
_______________________________________

From report at bugs.python.org  Wed Mar 25 23:21:23 2015
From: report at bugs.python.org (Craig Holmquist)
Date: Wed, 25 Mar 2015 22:21:23 +0000
Subject: [issue23779] imaplib authenticate raises TypeError if authenticator
 tries to abort
Message-ID: <1427322083.72.0.863898159285.issue23779@psf.upfronthosting.co.za>


New submission from Craig Holmquist:

If the authenticator object passed to the IMAP authenticate method tries to abort the handshake by returning None, TypeError is raised instead of sending the * line to the server.

>>> import imaplib
>>> imap = imaplib.IMAP4_SSL('imap.gmail.com')
>>> imap.authenticate(b'PLAIN', lambda x: None)
Traceback (most recent call last):
  File "<pyshell#5>", line 1, in <module>
    imap.authenticate(b'PLAIN', lambda x: None)
  File "C:\Python34\lib\imaplib.py", line 380, in authenticate
    typ, dat = self._simple_command('AUTHENTICATE', mech)
  File "C:\Python34\lib\imaplib.py", line 1133, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "C:\Python34\lib\imaplib.py", line 940, in _command
    self.send(literal)
  File "C:\Python34\lib\imaplib.py", line 276, in send
    self.sock.sendall(data)
  File "C:\Python34\lib\ssl.py", line 723, in sendall
    v = self.send(data[count:])
  File "C:\Python34\lib\ssl.py", line 684, in send
    v = self._sslobj.write(data)
TypeError: 'str' does not support the buffer interface

The problem is that _Authenticator.process returns a string instead of bytes in this case.

----------
components: Library (Lib)
files: imap_auth.patch
keywords: patch
messages: 239283
nosy: craigh
priority: normal
severity: normal
status: open
title: imaplib authenticate raises TypeError if authenticator tries to abort
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file38694/imap_auth.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23779>
_______________________________________

From report at bugs.python.org  Wed Mar 25 23:47:09 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 25 Mar 2015 22:47:09 +0000
Subject: [issue23765] Remove IsBadStringPtr calls in ctypes
In-Reply-To: <1427222345.86.0.728447674961.issue23765@psf.upfronthosting.co.za>
Message-ID: <1427323629.92.0.879483673563.issue23765@psf.upfronthosting.co.za>


Steve Dower added the comment:

So the repr that's there for c_char_p is currently::

    "%s(%s)" % (self.__class__.__name__, cast(self, c_void_p).value)

But if I remove the override then it renders the value as b'abc'. Basically, we can have one of:

>>> from ctypes import *
>>> cast(create_string_buffer(b'abc'), c_char_p)
c_char_p(b'abc')

or

>>> cast(create_string_buffer(b'abc'), c_char_p)
c_char_p(52808208)

I prefer the former (remove c_char_p.__repr__ completely), but the latter is clearly there for some reason. Any opinions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23765>
_______________________________________

From report at bugs.python.org  Wed Mar 25 23:54:40 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 Mar 2015 22:54:40 +0000
Subject: [issue23775] Fix pprint of OrderedDict
In-Reply-To: <1427270096.56.0.104555413271.issue23775@psf.upfronthosting.co.za>
Message-ID: <1427324080.15.0.970600809712.issue23775@psf.upfronthosting.co.za>


Berker Peksag added the comment:

LGTM. Added minor comments on Rietveld.

----------
nosy: +berker.peksag
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23775>
_______________________________________

From report at bugs.python.org  Thu Mar 26 00:10:36 2015
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 25 Mar 2015 23:10:36 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1427325036.41.0.0167430977554.issue2211@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Updated patch should address review comments. I did run with David's suggestion as I also noticed that my initial assessment was wrong (thanks for the note/review Berker).

----------
Added file: http://bugs.python.org/file38695/http_cookies_morsel_deprecated_set_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Thu Mar 26 00:16:22 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 25 Mar 2015 23:16:22 +0000
Subject: [issue23779] imaplib authenticate raises TypeError if authenticator
 tries to abort
In-Reply-To: <1427322083.72.0.863898159285.issue23779@psf.upfronthosting.co.za>
Message-ID: <1427325382.27.0.757151739695.issue23779@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23779>
_______________________________________

From report at bugs.python.org  Thu Mar 26 00:17:21 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 25 Mar 2015 23:17:21 +0000
Subject: [issue23779] imaplib authenticate raises TypeError if authenticator
 tries to abort
In-Reply-To: <1427322083.72.0.863898159285.issue23779@psf.upfronthosting.co.za>
Message-ID: <1427325441.17.0.756921208554.issue23779@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23779>
_______________________________________

From report at bugs.python.org  Thu Mar 26 00:43:26 2015
From: report at bugs.python.org (eryksun)
Date: Wed, 25 Mar 2015 23:43:26 +0000
Subject: [issue23765] Remove IsBadStringPtr calls in ctypes
In-Reply-To: <1427222345.86.0.728447674961.issue23765@psf.upfronthosting.co.za>
Message-ID: <1427327006.44.0.62112861975.issue23765@psf.upfronthosting.co.za>


eryksun added the comment:

> So the repr that's there for c_char_p is currently::
>    "%s(%s)" % (self.__class__.__name__, cast(self, c_void_p).value)

I suggested switching to using from_buffer:

    c_void_p.from_buffer(self).value 

from_buffer is more efficient. cast() is imlemented as an FFI call. There's also another approach using the buffer protocol:

    int.from_bytes(self, sys.byteorder)

> I prefer the former (remove c_char_p.__repr__ completely), but 
> the latter is clearly there for some reason. Any opinions?

It's there for same reason I suggested overriding c_wchar_p.__repr__. Getting the repr of an object shouldn't segfault the interpreter. The existing check with IsBadStringPtrA is bogus in a multithreaded environment. The repr should just show the address. At least that won't crash.

A topic for another discussion is disabling the SEH handler because it's not used consistently anyway (e.g. to guard pointer and CData base pointer access). To compensate, the faulthandler could be enhanced. It could call the CRT's __pxcptinfoptrs (not documented, but it should be) to get the Windows EXCEPTION_POINTERS record. This would enable at least an improved error message, e.g. "Segmentation fault reading [addr]" and "Segmentation fault writing [addr]". The funny thing is the current faulthandler example uses ctypes.string_at, which, because it's implemented as an FFI call guarded by the SEH handler, just raises OSError on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23765>
_______________________________________

From report at bugs.python.org  Thu Mar 26 00:50:07 2015
From: report at bugs.python.org (productivememberofsociety666)
Date: Wed, 25 Mar 2015 23:50:07 +0000
Subject: [issue23764] functools.wraps should be able to change function
 argspec as well
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427327407.06.0.489640186048.issue23764@psf.upfronthosting.co.za>


productivememberofsociety666 added the comment:

You're probably right and it's next to impossible to implement what I want in a clean manner. I'll get back to that at the end, but first for completeness's sake two examples to illustrate what this issue is even about.


````
import functools

def wrapper(func):
  @functools.wraps(func)
  def new_func(*args, **kwargs):
    pass
  return new_func

def to_be_wrapped(a):
  pass

wrapped = wrapper(to_be_wrapped)

wrapped(1) # Ok
wrapped(1, 2, 3) # Also ok, but shouldn't be! Should raise TypeError
````

The second call to wrapped() should fail because it's supposed to be a wrapper around to_be_wrapped(), which only takes 1 argument. But it succeeds because functools.wraps only changes "superficial" function attributes such as its signature or docstring. This creates a mismatch between expected and actual behaviour of wrapped().

Contrast this with how it works when using the decorator package I mentioned:

````
import decorator

def to_be_wrapped(x):
  print("f(x) called")
  pass

def _wrapper(func, *args, **kwargs):
  # Put actual functionality of your decorator here
  pass

def wrapper(func):
  return decorator.decorator(_wrapper, func)

wrapped = wrapper(to_be_wrapped)

wrapped(1) # Ok, because to_be_wrapped takes exactly 1 argument
wrapped(1, 2, 3) # raises TypeError for too many arguments, as it should
````

Like I said, the details of how it is used are different from those of functools.wraps. But the important thing is that, at the end, wrapped()'s argspec matches that of to_be_wrapped() and an appropriate error is raised by the second call.
Note that this does NOT work via propagation from a call to to_be_wrapped() or anything of the sort, as can be verified by the lack of output to stdout.


Now, the only problem is: I had a look at how this is achieved in the decorator package's source code and if I understand it correctly, they are doing some nasty nasty things with exec() to create a function with an argspec of their choosing at runtime. If this is in fact the only way to do it, I agree that it has no place in the standard library and should only be available via 3rd party libraries. Sorry for wasting your time then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23764>
_______________________________________

From report at bugs.python.org  Thu Mar 26 00:50:56 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 25 Mar 2015 23:50:56 +0000
Subject: [issue23764] functools.wraps should be able to change function
 argspec as well
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427327456.76.0.00357743687584.issue23764@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I double checked the current behaviour, and rediscovered something I had forgotten: when inspect.getargspec and inspect.getfullargspec were converted to be based on the inspect.signature machinery, we had to decide whether or not to follow wrapper chains to report the underlying signature or not.

We opted to continue reporting the "surface signature" for compatibility with the behaviour of these APIs in previous versions of Python (including introspection tools that handle wrapper chains themselves), while encouraging introspection tools to migrate to using the more capable inspect.signature API instead: https://docs.python.org/3/library/inspect.html#inspect.getfullargspec

If a particular introspection tool reports incorrect signatures in 3.4+, then that's an issue with that particular tool needing to be made wrapper chain aware.

I'll also ping Aaron Iles about potentially bringing https://funcsigs.readthedocs.org/ up to date with the features in the Python 3.4 version of the library, including the helper to traverse wrapper chains correctly: https://docs.python.org/3/library/inspect.html#inspect.unwrap

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23764>
_______________________________________

From report at bugs.python.org  Thu Mar 26 00:55:12 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 25 Mar 2015 23:55:12 +0000
Subject: [issue23764] functools.wraps should be able to change function
 argspec as well
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427327712.6.0.229032010359.issue23764@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Regarding the PyPI decorator module, the difference there is between using a "def f(*args, **kwargs)" wrapper (which requires following wrapper chains to read the signature correctly) and using functools.partial (which reports the correct surface signature directly).

You can define your own wrapper decorators like this to reproduce that behaviour with standard library components:

  def wrapper(func):
    return functools.wraps(func)(functools.partial(func))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23764>
_______________________________________

From report at bugs.python.org  Thu Mar 26 01:02:29 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Mar 2015 00:02:29 +0000
Subject: [issue23764] functools.wraps should be able to change function
 argspec as well
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427328149.69.0.79067806927.issue23764@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Backport proposal: https://github.com/aliles/funcsigs/issues/12

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23764>
_______________________________________

From report at bugs.python.org  Thu Mar 26 01:28:24 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Mar 2015 00:28:24 +0000
Subject: [issue23764] functools.wraps should be able to change function
 argspec as well
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427329703.99.0.72953058912.issue23764@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Full example showing the functools.partial based implementation:

>>> def wrapper(func):
...     return functools.wraps(func)(functools.partial(func))
... 
>>> def to_be_wrapped(x):
...     pass
...                                                                     
>>> import inspect
>>> inspect.getargspec(wrapper(to_be_wrapped))
ArgSpec(args=['x'], varargs=None, keywords=None, defaults=None)

Th usage of functools.partial is also what gives the PyPI decorator module eager validation of the argument structure, even if the original function is never actually called.

When you use the pass-through "*args, **kwds" signature on a wrapper function it really is just a pass-through - even setting __signature__ won't get the *interpreter* to change the way it processes the arguments, as that's baked directly into the compiled code object:

>>> def f(*args, **kwds):
...     pass
... 
>>> import dis
>>> dis.show_code(f)
Name:              f
Filename:          <stdin>
Argument count:    0
Kw-only arguments: 0
Number of locals:  2
Stack size:        1
Flags:             OPTIMIZED, NEWLOCALS, VARARGS, VARKEYWORDS, NOFREE
Constants:
   0: None
Variable names:
   0: args
   1: kwds

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23764>
_______________________________________

From report at bugs.python.org  Thu Mar 26 01:30:12 2015
From: report at bugs.python.org (productivememberofsociety666)
Date: Thu, 26 Mar 2015 00:30:12 +0000
Subject: [issue23764] functools.wraps should be able to change function
 argspec as well
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427329812.97.0.0984401545189.issue23764@psf.upfronthosting.co.za>


productivememberofsociety666 added the comment:

def wrapper(func):
    return functools.wraps(func)(functools.partial(func))

^ doesn't that just return something that is completely equivalent to func itself? Where do I put the actual wrapper functionality, i.e. code that is executed with each call to the "new" (wrapped) function?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23764>
_______________________________________

From report at bugs.python.org  Thu Mar 26 01:38:03 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Mar 2015 00:38:03 +0000
Subject: [issue23764] Accept a separate "target
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427330283.16.0.244193084062.issue23764@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Right, I started asking myself the same question, and then began poking around in the functools.partial implementation (https://hg.python.org/cpython/file/9be2405385ec/Modules/_functoolsmodule.c#l12)

----------
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open
title: functools.wraps should be able to change function argspec as well -> Accept a separate "target

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23764>
_______________________________________

From report at bugs.python.org  Thu Mar 26 01:43:45 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Mar 2015 00:43:45 +0000
Subject: [issue23764] Accept a separate "call_target" parameter to
 functools.partial
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427330625.18.0.219846891209.issue23764@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Well, there's an expected keyboard shortcut (accidentally hitting Shift-Enter submits the page...)

Anyway, the idea I came up with after looking at that is potentially adjusting functools.partial to accept a "call_target" parameter, which would allow it to *claim* to be a partial object calling "func" (and reporting its signature accordingly) while *actually* calling "wrapped_func" (which may not have accurate signature information).

That underlying feature could then be used as the basis for a new "wraps_validated" API that works by creating a partial object around the underlying function with the call target set to the decorated wrapper function.

----------
title: Accept a separate "target -> Accept a separate "call_target" parameter to functools.partial

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23764>
_______________________________________

From report at bugs.python.org  Thu Mar 26 02:05:34 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Mar 2015 01:05:34 +0000
Subject: [issue23764] Reference inspect.Signature.bind from functools.wraps
 documentation
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427331934.56.0.414849367769.issue23764@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Ah, unfortunately, on closer inspection, even partial itself ends up suffering from the same problem as the current inspect.wraps - validation ultimately happens at the point of calling the original wrapper function, so if you don't actually call it, you won't get any argument validation.

You can use https://docs.python.org/3/library/inspect.html#inspect.Signature.bind to force early validation without actually calling the underlying callable, but that's always going to be substantially slower than "just try it and see if it works". functools is also further down in the stdlib dependency hierarchy than the inspect module so it isn't possible to offer that behaviour without creating a circular dependency.

What would be possible is to point out explicitly that "wraps" only updates introspection metadata, and if you're after eager argument validation (e.g. before queuing a command for delayed execution), then you likely want inspect.Signature.bind.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
title: Accept a separate "call_target" parameter to functools.partial -> Reference inspect.Signature.bind from functools.wraps documentation
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23764>
_______________________________________

From report at bugs.python.org  Thu Mar 26 02:12:28 2015
From: report at bugs.python.org (Nikolaus Rath)
Date: Thu, 26 Mar 2015 01:12:28 +0000
Subject: [issue23529] Limit decompressed data when reading from LZMAFile and
 BZ2File
In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za>
Message-ID: <1427332348.69.0.0657778717591.issue23529@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

Except for the pointless 'myfileobj' stuff in gzip.py, rev 8 of the patch looks good to me.

(Btw, I'm not actually in favor of e.g. the seekable() change. The previous patch was intended as a proof-of-concept to see what would be necessary to inherit more from DecompressReader and if it's actually worth it. But having thought about it for a while more, I don't think there's a significant gain. But I'm happy to see that you were able to cherry-pick some useful pieces out of it nevertheless).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23529>
_______________________________________

From report at bugs.python.org  Thu Mar 26 02:13:02 2015
From: report at bugs.python.org (productivememberofsociety666)
Date: Thu, 26 Mar 2015 01:13:02 +0000
Subject: [issue23764] Reference inspect.Signature.bind from functools.wraps
 documentation
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427332382.1.0.661900163292.issue23764@psf.upfronthosting.co.za>


productivememberofsociety666 added the comment:

Sounds good! I think the docs on functools.wraps already list precisely which data is updated, but maybe mentioning explicitly that it can not affect the argspec could indeed make it clearer.
Either way, thank you for your help!

----------
components: +Library (Lib) -Documentation
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23764>
_______________________________________

From report at bugs.python.org  Thu Mar 26 03:02:03 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 Mar 2015 02:02:03 +0000
Subject: [issue1191964] add non-blocking read and write methods to
 subprocess.Popen
Message-ID: <1427335323.05.0.189374875565.issue1191964@psf.upfronthosting.co.za>


Martin Panter added the comment:

Josiah?s code now seems to handle the four special cases like this:

* Reading a closed pipe raises BrokenPipeError. This is novel to me, and bends the current definition of the exception. But it appears to be the way Windows works at a lower level, and does make a bit of sense to me. However it is inconsistent with how normal reading from files, pipes and sockets works, which return the special value b"" in the equivalent case. Also various communications protocols use an empty packet to signal EOF.

* Reading an empty pipe returns b"". This is consistent with partial reads, which I like. However it could be surprising for someone used to b"" signalling EOF. Alternatives are returning None like RawIOBase.read(), and raising BlockingIOError like os.write() and socket.send().

* Writing to a closed pipe raises BrokenPipeError. This is consistent with how other APIs work, but since it is an asynchronous condition, a naive program may work sometimes without handling it, and then see suprious tracebacks or worse in other situations. Maybe dropping the data and setting a flag could be an alternative.

* Writing to a full pipe returns zero. This is consistent with partial writes, which I like. Alternatives are returning None like RawIOBase.write(), and raising BlockingIOError like os.write(), socket.send(), BufferedIOBase.write().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1191964>
_______________________________________

From report at bugs.python.org  Thu Mar 26 03:06:26 2015
From: report at bugs.python.org (productivememberofsociety666)
Date: Thu, 26 Mar 2015 02:06:26 +0000
Subject: [issue23764] Reference inspect.Signature.bind from functools.wraps
 documentation
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427335586.57.0.70625901922.issue23764@psf.upfronthosting.co.za>


productivememberofsociety666 added the comment:

Sorry, did not mean to change the Components and Versions thingies...

----------
components: +Documentation -Library (Lib)
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23764>
_______________________________________

From report at bugs.python.org  Thu Mar 26 03:19:18 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Mar 2015 02:19:18 +0000
Subject: [issue23743] Python crashes upon exit if importing g++ compiled mod
 after importing gcc compiled mod
In-Reply-To: <1427087434.95.0.234111642557.issue23743@psf.upfronthosting.co.za>
Message-ID: <1427336358.47.0.890858742797.issue23743@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

pypa.io hosts the internal dev docs for PyPA, I believe you meant packaging.python.org, and that would indeed be the right home.

However, this kind of C/C++ linker related problem is way too advanced for the current state of the binary extension docs which basically say "C/C++ is hard relative to Python, let someone else deal with creating your extension modules for you": https://packaging.python.org/en/latest/extensions.html

For the scientific stack in particular we go even further and say to get someone else to build and link the extension modules for you: https://packaging.python.org/en/latest/science.html

Folks encountering the kind of problem described in this issue is thus mostly useful as a data point in *why* we give those instructions: because DIY cross-platform C/C++ development is a teeming morass of "fun" interoperability bugs like this one just waiting to be discovered :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23743>
_______________________________________

From report at bugs.python.org  Thu Mar 26 03:34:31 2015
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 26 Mar 2015 02:34:31 +0000
Subject: [issue22931] cookies with square brackets in value
In-Reply-To: <1427301017.55.0.556881984927.issue22931@psf.upfronthosting.co.za>
Message-ID: <CAE+T62Zj_8bmwe3GzqHTfx4A6bnS2xXXyG7iNT9DgOwqnkCLSQ@mail.gmail.com>


Demian Brecht added the comment:

As I understand it, the change should also be applied to security releases
as the regression manifested by a security related patch being applied.
That said, there may be some debate as there apparently isn't much (if
anything) in the way of precedence here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22931>
_______________________________________

From report at bugs.python.org  Thu Mar 26 05:10:49 2015
From: report at bugs.python.org (Eric McDonald)
Date: Thu, 26 Mar 2015 04:10:49 +0000
Subject: [issue23159] argparse: Provide equivalent of
 optparse.OptionParser.{option_groups, option_list, get_option}
In-Reply-To: <1420355263.97.0.969710352141.issue23159@psf.upfronthosting.co.za>
Message-ID: <1427343049.1.0.256251880032.issue23159@psf.upfronthosting.co.za>


Eric McDonald added the comment:

@paul.j3, thanks for the sample code for argparse extension. I agree that subclassing is a way to go for use in third-party projects. But, if someone ever wanted to add an abstraction layer in front of argparse.ArgumentParser and configparser.ConfigParser in the standard library, then modification of the argparse module might be more convenient.

However, in the intervening months since I originally filed this ticket, I ended up exploring an alternative to inspecting populated argparse.ArgumentParser instances for this use case (parser abstraction layer). The module I ended up writing is more of a framework in that it lets you supply argument and config parsers and then populate them via a common interface. While this design is perhaps higher maintenance, I think that it gives more flexibility and control than inspecting already-populated parsers. So, from my perspective, I no longer consider this use case to be a compelling reason for adding more optparse-like behavior to argparse.

(If there interest in the little framework that I wrote, I can share my code and take the discussion to an appropriate mailing list.)

Again, thanks for taking the time to write the argparse_extended.py code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23159>
_______________________________________

From report at bugs.python.org  Thu Mar 26 05:54:52 2015
From: report at bugs.python.org (Steve Dower)
Date: Thu, 26 Mar 2015 04:54:52 +0000
Subject: [issue23765] Remove IsBadStringPtr calls in ctypes
In-Reply-To: <1427222345.86.0.728447674961.issue23765@psf.upfronthosting.co.za>
Message-ID: <1427345692.8.0.991662652056.issue23765@psf.upfronthosting.co.za>


Steve Dower added the comment:

Ah okay, I understand better what your suggestion was trying to achieve now. I agree, we should just show the address in repr - I'll make that change to both c_char_p and c_wchar_p.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23765>
_______________________________________

From report at bugs.python.org  Thu Mar 26 05:58:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Mar 2015 04:58:55 +0000
Subject: [issue23765] Remove IsBadStringPtr calls in ctypes
In-Reply-To: <1427222345.86.0.728447674961.issue23765@psf.upfronthosting.co.za>
Message-ID: <20150326045851.7503.5718@psf.io>


Roundup Robot added the comment:

New changeset 339d90983e29 by Steve Dower in branch 'default':
Issue #23765: Removed IsBadStringPtr calls in ctypes
https://hg.python.org/cpython/rev/339d90983e29

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23765>
_______________________________________

From report at bugs.python.org  Thu Mar 26 07:40:11 2015
From: report at bugs.python.org (Emil Styrke)
Date: Thu, 26 Mar 2015 06:40:11 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1427352011.32.0.763547542427.issue4944@psf.upfronthosting.co.za>


Emil Styrke added the comment:

I have experienced this issue with Python 2.7.8 and 2.7.9.  It is almost the same issue as the OP experiences as far as I can tell: spawn some Python threads that each create a file, flush, fsync, close, then start a subprocess which uses the file through the Windows API.  One thing that may differ is that I create the file and spawn the child from the same thread.

I tried with close_fds=True, and it indeed works then, but like the OP, in my production code I need to get the output from the process, so it is not a usable workaround for me.

Test script and child program code is available at https://gist.github.com/anonymous/5d7d198cd3c22b31fa2a (the file upload button doesn't work for me it seems).  Running the script on my machine will print at least one failure most of the time, but not always.

----------
nosy: +Emil.Styrke
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Thu Mar 26 07:45:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Mar 2015 06:45:32 +0000
Subject: [issue23776] Don't use assert for checking arguments in pprint
In-Reply-To: <1427276262.37.0.171943179164.issue23776@psf.upfronthosting.co.za>
Message-ID: <20150326064530.24256.63818@psf.io>


Roundup Robot added the comment:

New changeset bf570ff87c60 by Serhiy Storchaka in branch 'default':
Issue #23776: Removed asserts from pprint.PrettyPrinter constructor.
https://hg.python.org/cpython/rev/bf570ff87c60

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23776>
_______________________________________

From report at bugs.python.org  Thu Mar 26 07:52:13 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Mar 2015 06:52:13 +0000
Subject: [issue23775] Fix pprint of OrderedDict
In-Reply-To: <1427270096.56.0.104555413271.issue23775@psf.upfronthosting.co.za>
Message-ID: <20150326065210.74140.5974@psf.io>


Roundup Robot added the comment:

New changeset afc21da5935f by Serhiy Storchaka in branch 'default':
Issue #23775: pprint() of OrderedDict now outputs the same representation
https://hg.python.org/cpython/rev/afc21da5935f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23775>
_______________________________________

From report at bugs.python.org  Thu Mar 26 07:56:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 06:56:17 +0000
Subject: [issue23776] Don't use assert for checking arguments in pprint
In-Reply-To: <1427276262.37.0.171943179164.issue23776@psf.upfronthosting.co.za>
Message-ID: <1427352977.98.0.546141409841.issue23776@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23776>
_______________________________________

From report at bugs.python.org  Thu Mar 26 07:56:44 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 06:56:44 +0000
Subject: [issue23776] Don't use assert for checking arguments in pprint
In-Reply-To: <1427276262.37.0.171943179164.issue23776@psf.upfronthosting.co.za>
Message-ID: <1427353004.25.0.379537338776.issue23776@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
versions:  -Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23776>
_______________________________________

From report at bugs.python.org  Thu Mar 26 07:57:06 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 06:57:06 +0000
Subject: [issue23775] Fix pprint of OrderedDict
In-Reply-To: <1427270096.56.0.104555413271.issue23775@psf.upfronthosting.co.za>
Message-ID: <1427353026.97.0.970971863683.issue23775@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Berker.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23775>
_______________________________________

From report at bugs.python.org  Thu Mar 26 07:59:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 06:59:20 +0000
Subject: [issue15133] tkinter.BooleanVar.get() behavior and docstring disagree
In-Reply-To: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za>
Message-ID: <1427353160.26.0.51316686534.issue15133@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What are your thoughts about the patch Terry?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15133>
_______________________________________

From report at bugs.python.org  Thu Mar 26 07:59:32 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 06:59:32 +0000
Subject: [issue15133] tkinter.BooleanVar.get() behavior and docstring disagree
In-Reply-To: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za>
Message-ID: <1427353172.65.0.425642447819.issue15133@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15133>
_______________________________________

From report at bugs.python.org  Thu Mar 26 08:26:06 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 07:26:06 +0000
Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol
In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za>
Message-ID: <1427354766.27.0.701292409225.issue2175@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated to the tip, added whatsnew entry and fixed the documentation.

What parts of this patch besides tests are worth to be applied to maintained releases?

----------
Added file: http://bugs.python.org/file38696/sax_character_stream_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2175>
_______________________________________

From report at bugs.python.org  Thu Mar 26 08:29:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 07:29:04 +0000
Subject: [issue2174] xml.sax.xmlreader does not support the InputSource
 protocol
In-Reply-To: <1203861152.32.0.18277152276.issue2174@psf.upfronthosting.co.za>
Message-ID: <1427354944.09.0.0210093460211.issue2174@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Issue2175 has a patch that covers all three issues: issue1483, issue2174 and issue2175. I hesitate what parts of the patch are worth to be applied to maintained releases.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2174>
_______________________________________

From report at bugs.python.org  Thu Mar 26 08:32:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 07:32:59 +0000
Subject: [issue22721] pprint output for sets and dicts is not stable
In-Reply-To: <1414170050.02.0.186594262536.issue22721@psf.upfronthosting.co.za>
Message-ID: <1427355179.48.0.524889842727.issue22721@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22721>
_______________________________________

From report at bugs.python.org  Thu Mar 26 09:02:03 2015
From: report at bugs.python.org (Florian Bruhin)
Date: Thu, 26 Mar 2015 08:02:03 +0000
Subject: [issue23780] Surprising behaviour when passing list to os.path.join.
Message-ID: <1427356923.25.0.682691905774.issue23780@psf.upfronthosting.co.za>


New submission from Florian Bruhin:

I just accidentally passed a list (instead of unpacking it) to os.path.join. I was surprised when it just returned the list unmodified:

>>> os.path.join([1, 2, 3])
[1, 2, 3]

Looking at the source, it simply returns the first argument (path = a; ...; return path) when the '*p' part is empty.

I think a "genericpath._check_arg_types('join', a)" or similiar should be added at the top, or it should ensure the "*p" part is not empty (as the docstring says "two or more pathname components").

----------
components: Library (Lib)
messages: 239314
nosy: The Compiler, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Surprising behaviour when passing list to os.path.join.
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23780>
_______________________________________

From report at bugs.python.org  Thu Mar 26 09:41:01 2015
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak_=28Pikec=29?=)
Date: Thu, 26 Mar 2015 08:41:01 +0000
Subject: [issue23780] Surprising behaviour when passing list to os.path.join.
In-Reply-To: <1427356923.25.0.682691905774.issue23780@psf.upfronthosting.co.za>
Message-ID: <1427359261.28.0.585696368614.issue23780@psf.upfronthosting.co.za>


Bo?tjan Mejak (Pikec) added the comment:

Using Python 3.4.3 on Windows 7 Home Premium 64 bit, Service Pack 1:

>>> import os
>>> os.path.join([1, 2, 3])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Program Files\Python 3.4\lib\ntpath.py", line 108, in join
    result_drive, result_path = splitdrive(path)
  File "C:\Program Files\Python 3.4\lib\ntpath.py", line 161, in splitdrive
    normp = p.replace(_get_altsep(p), sep)
AttributeError: 'list' object has no attribute 'replace'

I think this atribute error should be handled differently, like informing the programmer that you cannot use a list in the join method.

----------
nosy: +Bo?tjan Mejak (Pikec)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23780>
_______________________________________

From report at bugs.python.org  Thu Mar 26 09:46:07 2015
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Thu, 26 Mar 2015 08:46:07 +0000
Subject: [issue23780] Surprising behaviour when passing list to os.path.join.
In-Reply-To: <1427356923.25.0.682691905774.issue23780@psf.upfronthosting.co.za>
Message-ID: <1427359567.38.0.799020542499.issue23780@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.xperia at gmail.com>:


----------
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23780>
_______________________________________

From report at bugs.python.org  Thu Mar 26 09:49:25 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Mar 2015 08:49:25 +0000
Subject: [issue18408] Fixes crashes found by pyfailmalloc
In-Reply-To: <1373314243.02.0.649080681154.issue18408@psf.upfronthosting.co.za>
Message-ID: <20150326084922.120066.1847@psf.io>


Roundup Robot added the comment:

New changeset b742c1c5c0bf by Victor Stinner in branch 'default':
PEP 490: add issue 18408
https://hg.python.org/peps/rev/b742c1c5c0bf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18408>
_______________________________________

From report at bugs.python.org  Thu Mar 26 10:49:48 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 09:49:48 +0000
Subject: [issue23781] Add private _PyErr_ReplaceException() in 2.7
Message-ID: <1427363388.22.0.986381006689.issue23781@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds internal private function _PyErr_ReplaceException() in 2.7. This functions is like _PyErr_ChainExceptions() in 3.x, but doesn't set the context. It makes the code of 2.x simpler and more similar to 3.x and makes the backporting from 3.x easier.

----------
components: Interpreter Core
files: capi_PyErr_ReplaceException.patch
keywords: patch
messages: 239317
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add private _PyErr_ReplaceException() in 2.7
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file38697/capi_PyErr_ReplaceException.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23781>
_______________________________________

From report at bugs.python.org  Thu Mar 26 10:52:48 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Mar 2015 09:52:48 +0000
Subject: [issue23781] Add private _PyErr_ReplaceException() in 2.7
In-Reply-To: <1427363388.22.0.986381006689.issue23781@psf.upfronthosting.co.za>
Message-ID: <1427363568.72.0.931394241286.issue23781@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FIY I'm working on a draft of new PEP to chain exceptions at C level: PEP 490.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23781>
_______________________________________

From report at bugs.python.org  Thu Mar 26 11:25:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 10:25:02 +0000
Subject: [issue23782] Leak in _PyTraceback_Add
Message-ID: <1427365502.47.0.105321888995.issue23782@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There is a leak of fetched exception in _PyTraceback_Add() (Python/traceback.c:146).

----------
messages: 239319
nosy: georg.brandl, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Leak in _PyTraceback_Add
type: resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23782>
_______________________________________

From report at bugs.python.org  Thu Mar 26 11:36:56 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 10:36:56 +0000
Subject: [issue23783] Leak in PyObject_ClearWeakRefs
Message-ID: <1427366216.42.0.852268629074.issue23783@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

If restore_error == 1 in PyObject_ClearWeakRefs() (Objects/weakrefobject.c:883) and PyTuple_New() fails in Objects/weakrefobject.c:923, PyErr_Fetch is called twice and both exceptions leak.

----------
components: Extension Modules
messages: 239320
nosy: fdrake, haypo, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Leak in PyObject_ClearWeakRefs
type: resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23783>
_______________________________________

From report at bugs.python.org  Thu Mar 26 12:16:32 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Mar 2015 11:16:32 +0000
Subject: [issue23782] Leak in _PyTraceback_Add
In-Reply-To: <1427365502.47.0.105321888995.issue23782@psf.upfronthosting.co.za>
Message-ID: <1427368592.67.0.0890296044996.issue23782@psf.upfronthosting.co.za>


STINNER Victor added the comment:

If a new exception is raised by _PyTraceback_Add(), the original exception is lost. It's sad because _PyTraceback_Add() is supposed to enhance the current exception, not to drop it.

In the draft of my PEP 490, I propose to chain the two exceptions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23782>
_______________________________________

From report at bugs.python.org  Thu Mar 26 12:17:57 2015
From: report at bugs.python.org (David Marks)
Date: Thu, 26 Mar 2015 11:17:57 +0000
Subject: [issue23784] Reloading tokenize module leads to error
Message-ID: <1427368677.31.0.668766566103.issue23784@psf.upfronthosting.co.za>


New submission from David Marks:

On 432 in tokenize.py there is an assignment

_builtin_open = open

Followed in 434 with a redefinition of open

def open(filename):

If the module is reloaded, _builtin_open gets reassigned to the new function and subsequent calls to _builtin_open fail.

----------
components: Library (Lib)
messages: 239322
nosy: dmarks
priority: normal
severity: normal
status: open
title: Reloading tokenize module leads to error
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23784>
_______________________________________

From report at bugs.python.org  Thu Mar 26 12:22:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 11:22:42 +0000
Subject: [issue23784] Reloading tokenize module leads to error
In-Reply-To: <1427368677.31.0.668766566103.issue23784@psf.upfronthosting.co.za>
Message-ID: <1427368962.31.0.147814352996.issue23784@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed in issue23615.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23784>
_______________________________________

From report at bugs.python.org  Thu Mar 26 12:26:37 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 Mar 2015 11:26:37 +0000
Subject: [issue18828] urljoin behaves differently with custom and standard
 schemas
In-Reply-To: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za>
Message-ID: <1427369197.67.0.173397597731.issue18828@psf.upfronthosting.co.za>


Martin Panter added the comment:

The current behaviour when no scheme is present is fairly sensible to me and should not be changed to do string concatenation nor raise an exception:

>>> urljoin("//netloc/old/path", "new/path")
'//netloc/old/new/path'

I am posting urljoin-non-hier.patch as an alternative to my first patch. This one changes urljoin() to work on any URL scheme not in the existing ?non_hierarchical? blacklist. I removed the gopher, wais, and imap schemes from the list, and added tel, so that urljoin() continues to treat these special cases as before. Out of the schemes mentioned in the module but missing from uses_relative, I think non_hierarchical now has all those without directory components: hdl, mailto, news, sip, sips, snews, tel, telnet.

However I am still not really convinced that my first urljoin-scheme.patch is a bad idea. Do people actually use urljoin() with these schemes like mailto in the first place?

----------
Added file: http://bugs.python.org/file38698/urljoin-non-hier.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18828>
_______________________________________

From report at bugs.python.org  Thu Mar 26 12:29:44 2015
From: report at bugs.python.org (Masayuki Yamamoto)
Date: Thu, 26 Mar 2015 11:29:44 +0000
Subject: [issue23663] Crash on failure in ctypes on Cygwin
In-Reply-To: <1426370668.97.0.493459472376.issue23663@psf.upfronthosting.co.za>
Message-ID: <1427369384.13.0.288503221884.issue23663@psf.upfronthosting.co.za>


Masayuki Yamamoto added the comment:

similar issue #23338: PyErr_Format in ctypes uses invalid parameter

----------
nosy: +masamoto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23663>
_______________________________________

From report at bugs.python.org  Thu Mar 26 13:33:16 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Mar 2015 12:33:16 +0000
Subject: [issue23784] Reloading tokenize module leads to error
In-Reply-To: <1427368677.31.0.668766566103.issue23784@psf.upfronthosting.co.za>
Message-ID: <1427373196.85.0.0594139318164.issue23784@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution: out of date -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23784>
_______________________________________

From report at bugs.python.org  Thu Mar 26 13:38:46 2015
From: report at bugs.python.org (David Macek)
Date: Thu, 26 Mar 2015 12:38:46 +0000
Subject: [issue23663] Crash on failure in ctypes on Cygwin
In-Reply-To: <1426370668.97.0.493459472376.issue23663@psf.upfronthosting.co.za>
Message-ID: <1427373526.66.0.285790234103.issue23663@psf.upfronthosting.co.za>


David Macek added the comment:

Yeah, looks like exactly the same issue. Sorry for the duplicate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23663>
_______________________________________

From report at bugs.python.org  Thu Mar 26 14:04:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 13:04:41 +0000
Subject: [issue23785] Leak in TextIOWrapper.tell()
Message-ID: <1427375081.85.0.443670344357.issue23785@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

If an exception was raised in TextIOWrapper.tell() and then restoring state is failed, original exception is lost and leaked.

----------
components: Extension Modules
messages: 239327
nosy: benjamin.peterson, haypo, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
status: open
title: Leak in TextIOWrapper.tell()
type: resource usage
versions: Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23785>
_______________________________________

From report at bugs.python.org  Thu Mar 26 14:10:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 13:10:27 +0000
Subject: [issue23785] Leak in TextIOWrapper.tell()
In-Reply-To: <1427375081.85.0.443670344357.issue23785@psf.upfronthosting.co.za>
Message-ID: <1427375427.51.0.563871188371.issue23785@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch chain original exception to the exception raised by setstate(saved_state). This matches the behavior of Python implementation.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23785>
_______________________________________

From report at bugs.python.org  Thu Mar 26 14:10:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 13:10:54 +0000
Subject: [issue23785] Leak in TextIOWrapper.tell()
In-Reply-To: <1427375081.85.0.443670344357.issue23785@psf.upfronthosting.co.za>
Message-ID: <1427375454.22.0.667945414664.issue23785@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file38699/issue23785.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23785>
_______________________________________

From report at bugs.python.org  Thu Mar 26 14:26:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 13:26:00 +0000
Subject: [issue23783] Leak in PyObject_ClearWeakRefs
In-Reply-To: <1427366216.42.0.852268629074.issue23783@psf.upfronthosting.co.za>
Message-ID: <1427376360.05.0.681225553747.issue23783@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch should fix the issue.

----------
keywords: +patch
stage:  -> patch review
versions: +Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38700/issue23783.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23783>
_______________________________________

From report at bugs.python.org  Thu Mar 26 14:47:28 2015
From: report at bugs.python.org (Peter)
Date: Thu, 26 Mar 2015 13:47:28 +0000
Subject: [issue23786] test_unaligned_buffers
 (test.test_hash.HashEqualityTestCase) ... Fatal Python error:
 Bus error
Message-ID: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za>


New submission from Peter:

I compiled Python 3.4.3 on Solaris 11, and when I ran the regression test, I get a core dump when the hash() function was being used. I went through the bug database looking for something similar but couldn't find anything.

Tests like:
test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error

Current thread 0x00000001 (most recent call first):
  File "/usr/local/lib/python3.4/test/test_hash.py", line 89 in test_unaligned_buffers
  File "/usr/local/lib/python3.4/unittest/case.py", line 577 in run
  File "/usr/local/lib/python3.4/unittest/case.py", line 625 in __call__
  File "/usr/local/lib/python3.4/unittest/suite.py", line 122 in run
  File "/usr/local/lib/python3.4/unittest/suite.py", line 84 in __call__
  File "/usr/local/lib/python3.4/unittest/suite.py", line 122 in run
  File "/usr/local/lib/python3.4/unittest/suite.py", line 84 in __call__
  File "/usr/local/lib/python3.4/unittest/suite.py", line 122 in run
  File "/usr/local/lib/python3.4/unittest/suite.py", line 84 in __call__
  File "/usr/local/lib/python3.4/unittest/runner.py", line 168 in run
  File "/usr/local/lib/python3.4/test/support/__init__.py", line 1769 in _run_suite
  File "/usr/local/lib/python3.4/test/support/__init__.py", line 1803 in run_unittest
  File "/usr/local/lib/python3.4/test/regrtest.py", line 1279 in test_runner
  File "/usr/local/lib/python3.4/test/regrtest.py", line 1280 in runtest_inner
  File "/usr/local/lib/python3.4/test/regrtest.py", line 978 in runtest
  File "/usr/local/lib/python3.4/test/regrtest.py", line 763 in main
  File "/usr/local/lib/python3.4/test/regrtest.py", line 1564 in main_in_temp_cwd
  File "/usr/local/lib/python3.4/test/__main__.py", line 3 in <module>
  File "/usr/local/lib/python3.4/runpy.py", line 85 in _run_code
  File "/usr/local/lib/python3.4/runpy.py", line 170 in _run_module_as_main
Bus Error (core dumped)


and


test_hash_equality (test.datetimetester.TestTime_Fast) ... Fatal Python error: Bus error

Current thread 0x00000001 (most recent call first):
  File "/usr/local/lib/python3.4/test/datetimetester.py", line 2155 in test_hash_equality
  File "/usr/local/lib/python3.4/unittest/case.py", line 577 in run
  File "/usr/local/lib/python3.4/unittest/case.py", line 625 in __call__
  File "/usr/local/lib/python3.4/unittest/suite.py", line 122 in run
  File "/usr/local/lib/python3.4/unittest/suite.py", line 84 in __call__
  File "/usr/local/lib/python3.4/unittest/suite.py", line 122 in run
  File "/usr/local/lib/python3.4/unittest/suite.py", line 84 in __call__
  File "/usr/local/lib/python3.4/unittest/runner.py", line 168 in run
  File "/usr/local/lib/python3.4/test/support/__init__.py", line 1769 in _run_suite
  File "/usr/local/lib/python3.4/test/support/__init__.py", line 1803 in run_unittest
  File "/usr/local/lib/python3.4/test/test_datetime.py", line 45 in test_main
  File "/usr/local/lib/python3.4/test/regrtest.py", line 1280 in runtest_inner
  File "/usr/local/lib/python3.4/test/regrtest.py", line 978 in runtest
  File "/usr/local/lib/python3.4/test/regrtest.py", line 763 in main
  File "/usr/local/lib/python3.4/test/regrtest.py", line 1564 in main_in_temp_cwd
  File "/usr/local/lib/python3.4/test/__main__.py", line 3 in <module>
  File "/usr/local/lib/python3.4/runpy.py", line 85 in _run_code
  File "/usr/local/lib/python3.4/runpy.py", line 170 in _run_module_as_main
Bus Error (core dumped)



I then ran the same test through gdb:
$ gdb /usr/local/bin/python3.4
GNU gdb (GDB) 7.8.1
<snip>
(gdb) run -m test -v test_hash
Starting program: /usr/local/bin/python3.4 -m test -v test_hash
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
== CPython 3.4.3 (default, Mar 25 2015, 17:35:25) [GCC 4.6.2]
==   Solaris-2.11-sun4v-sparc-32bit-ELF big-endian
==   hash algorithm: fnv 32bit
==   /tmp/test_python_12329
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_
site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[1/1] test_hash
test_empty_string (test.test_hash.BytesHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_long_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_null_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.DatetimeDateTests) ... ok
test_randomized_hash (test.test_hash.DatetimeDatetimeTests) ... FAIL
test_randomized_hash (test.test_hash.DatetimeTimeTests) ... FAIL
test_hashes (test.test_hash.HashBuiltinsTestCase) ... ok
test_hash_distribution (test.test_hash.HashDistributionTestCase) ... ok
test_coerced_floats (test.test_hash.HashEqualityTestCase) ... ok
test_coerced_integers (test.test_hash.HashEqualityTestCase) ... ok
test_numeric_literals (test.test_hash.HashEqualityTestCase) ... ok
test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xff25d14c in fnv (src=0x1d2289, len=127) at Python/pyhash.c:267
267             x = (_PyHASH_MULTIPLIER * x) ^ block.value;
(gdb) bt
#0  0xff25d14c in fnv (src=0x1d2289, len=127) at Python/pyhash.c:267
#1  0xff25d3f8 in _Py_HashBytes (src=0x1d2289, len=127) at Python/pyhash.c:186
#2  0xff1a7ce4 in memory_hash (self=0xfdff5570) at Objects/memoryobject.c:2793
#3  0xff1afa40 in PyObject_Hash (v=0xfdff5570) at Objects/object.c:757
#4  0xff22b6fc in builtin_hash (self=0xfee23600, v=0xfdff5570) at Python/bltinmodule.c:1269
#5  0xff236a70 in call_function (oparg=<optimized out>, pp_stack=0xffbfcc94) at Python/ceval.c:4224
#6  PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2838
#7  0xff237790 in fast_function (nk=<optimized out>, na=<optimized out>, n=1, pp_stack=0xffbfcd8c,
    func=<optimized out>) at Python/ceval.c:4334
<snip>


(gdb) list
262
263         x = (Py_uhash_t) _Py_HashSecret.fnv.prefix;
264         x ^= (Py_uhash_t) *p << 7;
265         while (blocks--) {
266             PY_UHASH_CPY(block.bytes, p);
267             x = (_PyHASH_MULTIPLIER * x) ^ block.value;
268             p += SIZEOF_PY_UHASH_T;
269         }
270         /* add remainder */
271         for (; remainder > 0; remainder--)



Further info:
$ uname -a
SunOS vstrlily1d 5.11 11.1 sun4v sparc sun4v Solaris

$ gcc --verbose
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sparc-sun-solaris2.11/4.6.2/lto-wrapper
Target: sparc-sun-solaris2.11
Configured with: ../gcc-4.6.2/configure --prefix=/usr/local --enable-languages=c,c++ --disable-nls --with-gnu-as --with-gnu-ld --target=sparc-sun-solaris2.11
Thread model: posix
gcc version 4.6.2 (GCC)

----------
components: Interpreter Core, Tests
messages: 239330
nosy: petriborg
priority: normal
severity: normal
status: open
title: test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error
type: crash
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23786>
_______________________________________

From report at bugs.python.org  Thu Mar 26 14:50:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 13:50:30 +0000
Subject: [issue23786] test_unaligned_buffers
 (test.test_hash.HashEqualityTestCase) ... Fatal Python error:
 Bus error
In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za>
Message-ID: <1427377830.78.0.382868105275.issue23786@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +christian.heimes, jcea
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23786>
_______________________________________

From report at bugs.python.org  Thu Mar 26 14:56:03 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 26 Mar 2015 13:56:03 +0000
Subject: [issue23785] Leak in TextIOWrapper.tell()
In-Reply-To: <1427375081.85.0.443670344357.issue23785@psf.upfronthosting.co.za>
Message-ID: <1427378163.66.0.979827931888.issue23785@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

lgtm with a test

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23785>
_______________________________________

From report at bugs.python.org  Thu Mar 26 15:07:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 14:07:01 +0000
Subject: [issue23785] Leak in TextIOWrapper.tell()
In-Reply-To: <1427375081.85.0.443670344357.issue23785@psf.upfronthosting.co.za>
Message-ID: <1427378821.48.0.807318459077.issue23785@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It would be not easy to reproduce without special broken decoder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23785>
_______________________________________

From report at bugs.python.org  Thu Mar 26 15:07:59 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 26 Mar 2015 14:07:59 +0000
Subject: [issue23785] Leak in TextIOWrapper.tell()
In-Reply-To: <1427375081.85.0.443670344357.issue23785@psf.upfronthosting.co.za>
Message-ID: <1427378879.14.0.544943248153.issue23785@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

How did you notice it, btw?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23785>
_______________________________________

From report at bugs.python.org  Thu Mar 26 15:36:58 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 14:36:58 +0000
Subject: [issue23785] Leak in TextIOWrapper.tell()
In-Reply-To: <1427375081.85.0.443670344357.issue23785@psf.upfronthosting.co.za>
Message-ID: <1427380618.8.0.783327686892.issue23785@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Just reading the code that uses PyErr_Restore(). I found 3 issues and may be the fourth in sqlite (it is more complicate than other 3).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23785>
_______________________________________

From report at bugs.python.org  Thu Mar 26 15:56:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 Mar 2015 14:56:55 +0000
Subject: [issue23780] Surprising behaviour when passing list to os.path.join.
In-Reply-To: <1427356923.25.0.682691905774.issue23780@psf.upfronthosting.co.za>
Message-ID: <1427381815.98.0.143267465466.issue23780@psf.upfronthosting.co.za>


R. David Murray added the comment:

Python's philosophy is one of duck typing, which means that in general we just let the functions fail with whatever error they produce when the in put datatype is wrong.  The error message in this case is fairly straightforward: you passed a list and it says that that data type doesn't work.  The linux case is a bit more problematic in that it *doesn't* produce an error for invalid input.  The problem there is that we can't raise an error if there's only one argument for backward compatibility reasons: there almost certainly exists code that depends on single argument path returning the argument.  

In theory there shouldn't be code that depends on that single argument being an incorrect data type, but it would still only be something we'd consider changing in a feature release.

I'm not sure it is worth fixing, frankly, but I've attached a patch we could consider applying to 3.5.  (aside: the isinstance check in _get_sep looks like a bug report waiting to happen...it will do the wrong thing if passed a bytearray or memoryview...)

There may be others who will advocate for a stricter type check or a try/except with a "better" error message...I'd be OK with the better error message as long as it doesn't break the duck typing rule.

----------
keywords: +patch
nosy: +r.david.murray
Added file: http://bugs.python.org/file38701/join_datatype_check.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23780>
_______________________________________

From report at bugs.python.org  Thu Mar 26 16:01:10 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 Mar 2015 15:01:10 +0000
Subject: [issue23784] Reloading tokenize module leads to error
In-Reply-To: <1427368677.31.0.668766566103.issue23784@psf.upfronthosting.co.za>
Message-ID: <1427382070.12.0.817789231946.issue23784@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution: fixed -> duplicate
superseder:  -> Reloading tokenize breaks tokenize.open()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23784>
_______________________________________

From report at bugs.python.org  Thu Mar 26 16:09:10 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Thu, 26 Mar 2015 15:09:10 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1427382550.36.0.00707014467092.issue23602@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

actually, I'm not sure whether formatting Decimals gives correct output under all conditions (correctly rounded yes, but maybe not formatted correctly?).

compare:

>>> format(float('1.481e-6'),'.3g')
'1.48e-06'

>>> format(Decimal('1.481e-6'),'.3g')
'0.00000148'

>>> format(float('1.481e-7'),'.3g')
'1.48e-07'

>>> format(Decimal('1.481e-7'),'.3g')
'1.48e-7'

So with the 'g' specifier the switch between floating point and scientific notation seems to be broken.
Also note the slightly different formatting of the exponent: the leading zero is missing for all specifiers, i.e. 'g', 'G', 'e', 'E'.

Are these bugs ?

----------
nosy: +wolma

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Thu Mar 26 16:14:11 2015
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 26 Mar 2015 15:14:11 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1427382851.14.0.852289468251.issue23602@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Decimal formatting intentionally differs from float formatting, see #23460.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Thu Mar 26 16:19:44 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Thu, 26 Mar 2015 15:19:44 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1427383184.19.0.549038912185.issue23602@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

> Decimal formatting intentionally differs from float formatting, see #23460.

I see. Thanks for the pointer. What about the missing zero in the exponent ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Thu Mar 26 16:19:46 2015
From: report at bugs.python.org (SpaceOne)
Date: Thu, 26 Mar 2015 15:19:46 +0000
Subject: [issue9698] When reusing an handler,
 urllib(2)'s digest authentication fails after multiple regative
 replies
In-Reply-To: <1282892368.57.0.758322534297.issue9698@psf.upfronthosting.co.za>
Message-ID: <1427383186.92.0.388837687063.issue9698@psf.upfronthosting.co.za>


Changes by SpaceOne <python at florianbest.de>:


----------
nosy: +spaceone

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9698>
_______________________________________

From report at bugs.python.org  Thu Mar 26 16:32:40 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 26 Mar 2015 15:32:40 +0000
Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1427383960.43.0.100922646469.issue23484@psf.upfronthosting.co.za>


Davin Potts added the comment:

Attaching patches for 3.5/default, 3.4, and 2.7 which update the documentation on multiprocessing.Lock, RLock, Semaphore, and BoundedSemaphore to describe their actual implemented behavior, replacing the existing, misleading claim that they are clones of threading.Lock, etc., respectively.

Specific changes:
* Lock and RLock now have their acquire and release methods drawn out so as to best explain the significant behavioral differences (versus threading) in return values, potential exceptions being raised, and passing arguments.
* Semaphore and BoundedSemaphore are not as drawn out because their behaviors are indeed the same in every regard except for the difference in block-vs-blocking (and in the case of 2.7, timeout is novel in multiprocessing and doesn't appear until 3.2 in threading).
* In 3.4 and 3.5, the inaccurate note block at the end of the synchronization section no longer misrepresents the treatment of the timeout argument in threading analogs.

It is worth noting that in 3.x, the behavior around the timeout argument in multiprocessing.{Lock,RLock,Semaphore,BoundedSemaphore} already matches that of threading.Semaphore and BoundedSemaphore.  The threading module appears inconsistent in its use of the timeout argument when comparing Semaphore/BoundedSemaphore with Lock/RLock.  It would be interesting to investigate whether in 3.x this inconsistency within threading could be brought in line with the rest of multiprocessing.

In issue21342 the notion of unifying the implementations of these synchronization primitives across threading and multiprocessing is suggested.  If that is pursued, it would reasonably be attempted on default/3.5 and not backported to 2.7 (nor probably 3.4).  Thus this patch to update the documentation is still highly valuable for 2.7 and 3.4 and 3.5 (at least until such time as a unification effort might be undertaken in the case of 3.5).

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file38702/issue_23484_doc_locks_py35_and_py34.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23484>
_______________________________________

From report at bugs.python.org  Thu Mar 26 16:33:31 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 26 Mar 2015 15:33:31 +0000
Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1427384011.16.0.654337872406.issue23484@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


Added file: http://bugs.python.org/file38703/issue_23484_doc_locks_py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23484>
_______________________________________

From report at bugs.python.org  Thu Mar 26 16:33:52 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 15:33:52 +0000
Subject: [issue23780] Surprising behaviour when passing list to os.path.join.
In-Reply-To: <1427356923.25.0.682691905774.issue23780@psf.upfronthosting.co.za>
Message-ID: <1427384032.74.0.576774820618.issue23780@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Error message for ntpath is improved in 3.5.

>>> import ntpath
>>> ntpath.join([1, 2, 3])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/ntpath.py", line 111, in join
    genericpath._check_arg_types('join', path, *paths)
  File "/home/serhiy/py/cpython/Lib/genericpath.py", line 143, in _check_arg_types
    (funcname, s.__class__.__name__)) from None
TypeError: join() argument must be str or bytes, not 'list'

I'm not sure that the case of single argument in posixpath.join needs a fix. First, any argument checks have a cost. Second, currently os.path works with string-like objects if they implement enough string methods.

But David's proposition looks enough harmless (but this line should be added inside the try block). Do you want to add tests David? If apply it to posixpath, it should by applied to ntpath too, because currently ntpath.join doesn't raise an exceptions for empty list.

> (aside: the isinstance check in _get_sep looks like a bug report waiting to happen...it will do the wrong thing if passed a bytearray or memoryview...)

It is documented that os.path only works with strings and bytes objects. It also can work with str-like objects if lucky.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23780>
_______________________________________

From report at bugs.python.org  Thu Mar 26 16:35:09 2015
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 26 Mar 2015 15:35:09 +0000
Subject: [issue18828] urljoin behaves differently with custom and standard
 schemas
In-Reply-To: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za>
Message-ID: <1427384109.68.0.968448347243.issue18828@psf.upfronthosting.co.za>


Demian Brecht added the comment:

> The current behaviour when no scheme is present is fairly sensible to me and should not be changed to do string concatenation nor raise an exception

Agreed. Defaulting to relative behaviour makes sense as I imagine that'll be the general use case.

> I removed the gopher, wais, and imap schemes from the list

I'd be concerned about removing items as non_hierarchical /is/ public facing and it's reasonable to assume that there are libraries out there that depend on these. Additionally, at a glance through their respective RFCs, it seems that these three protocols /do/ belong in the non_hierarchical list. While WAIS and IMAP do use / as a delimiter, they're not hierarchical and therefore relative joining doesn't make sense. For example, with the following definition in mind (RFC4156):

wais://<host>:<port>/<database>/<wtype>/<wpath>

The following will result in an incorrect URL:

urljoin('wais://foo at bar.com/mydb/type/path', '/newpath')


> However I am still not really convinced that my first urljoin-scheme.patch is a bad idea. Do people actually use urljoin() with these schemes like mailto in the first place?

I'd be inclined to agree that it's far from common practice. That said, I did find one instance of a project that seems to depend on current behaviour (although it's only in tests and I haven't looked any deeper): https://github.com/chfoo/wpull/blob/32837d7c5614d7f90b8242e1fbb41f8da9bc7ce7/wpull/url_test.py#L637. I imagine that the current behaviour may possibly be useful for utilities such as web crawlers. In light of that and the fact that the urllib.parse docs currently has a list of protocols that are intended to be supported across the entire module's API, I think that it's important to not break backwards compatibility in cases where the relative URL would have been returned. Your second patch seems to have this behaviour which I think is preferable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18828>
_______________________________________

From report at bugs.python.org  Thu Mar 26 16:37:25 2015
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 26 Mar 2015 15:37:25 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1427384245.22.0.789020788943.issue23602@psf.upfronthosting.co.za>


Stefan Krah added the comment:

The zero isn't missing. :)  We are following http://speleotrove.com/decimal/decarith.html, with thousands of test cases.

We could decide to do something special for "g", but there are good reasons not to do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Thu Mar 26 16:37:48 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 26 Mar 2015 15:37:48 +0000
Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1427384268.34.0.769288208884.issue23484@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23484>
_______________________________________

From report at bugs.python.org  Thu Mar 26 16:44:18 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 26 Mar 2015 15:44:18 +0000
Subject: [issue18620] multiprocessing page leaves out important part of Pool
 example
In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za>
Message-ID: <1427384658.65.0.0514286468779.issue18620@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18620>
_______________________________________

From report at bugs.python.org  Thu Mar 26 16:48:10 2015
From: report at bugs.python.org (Masayuki Yamamoto)
Date: Thu, 26 Mar 2015 15:48:10 +0000
Subject: [issue21085] compile error Python3.3 on Cygwin
In-Reply-To: <1396019829.85.0.386935527155.issue21085@psf.upfronthosting.co.za>
Message-ID: <1427384890.88.0.257880895963.issue21085@psf.upfronthosting.co.za>


Masayuki Yamamoto added the comment:

I wrote improved patch to remove the 'si_band'.  This patch modifies the 'n_in_sequence' to conform to the number of structure members.
And I tested manually for struct_siginfo.  struct_siginfo objects builds well.
That's all for now.

$ python3.4.exe
Python 3.4.3 (default, Mar  2 2015, 22:23:56)
[GCC 4.9.2] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import signal
>>> signal.struct_siginfo([1, 2, 3, 4, 5, 6])
signal.struct_siginfo(si_signo=1, si_code=2, si_errno=3, si_pid=4, si_uid=5, si_status=6)
>>> signal.sigwaitinfo({signal.SIGINT})
^C
signal.struct_siginfo(si_signo=2, si_code=6, si_errno=0, si_pid=3352, si_uid=1000, si_status=0)
>>> signal.alarm(1); signal.sigwaitinfo({signal.SIGALRM})
0
signal.struct_siginfo(si_signo=14, si_code=4, si_errno=0, si_pid=5816, si_uid=1000, si_status=1629189728)

----------
nosy: +masamoto
type:  -> compile error
versions: +Python 3.5
Added file: http://bugs.python.org/file38704/3.4-issue21085-cygwin-struct_siginfo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21085>
_______________________________________

From report at bugs.python.org  Thu Mar 26 16:58:27 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 Mar 2015 15:58:27 +0000
Subject: [issue23780] Surprising behaviour when passing list to os.path.join.
In-Reply-To: <1427356923.25.0.682691905774.issue23780@psf.upfronthosting.co.za>
Message-ID: <1427385507.01.0.95360250735.issue23780@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, I'm not going to write tests...my goal is to commit other people's patches, and I haven't even found time for that lately.  And like you, I'm not convinced the fix is needed.  There is one argument I can think  of in favor, though: currently code that doesn't raise an error on posix will raise an error on Windows, and there is some portability value in making this consistent.

(Side note: the fact that join works with things that look enough like strings is important, because I'm sure that there are pathlib-like libraries out there that pretend to be strings so that they can be used in things like path.join.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23780>
_______________________________________

From report at bugs.python.org  Thu Mar 26 18:23:06 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Mar 2015 17:23:06 +0000
Subject: [issue21085] compile error Python3.3 on Cygwin
In-Reply-To: <1396019829.85.0.386935527155.issue21085@psf.upfronthosting.co.za>
Message-ID: <1427390586.25.0.574339177007.issue21085@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Could you please use a define like SIGINFO_HAS_SI_BAND?

Something like:

#if defined(HAVE_SIGINFO) && !defined(__CYGWIN__)
   /* Issue #21085: In Cygwin, siginfo_t does not have si_band field. */
#  define SIGINFO_HAS_SI_BAND
#endif

And please generate patches not the git format. Otherwise, Rietveld is unable to generated the "review" link.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21085>
_______________________________________

From report at bugs.python.org  Thu Mar 26 18:37:16 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Mar 2015 17:37:16 +0000
Subject: [issue23771] Timeouts on "x86 Ubuntu Shared 3.x" buildbot
In-Reply-To: <1427251322.87.0.815245923642.issue23771@psf.upfronthosting.co.za>
Message-ID: <1427391436.92.0.891413125647.issue23771@psf.upfronthosting.co.za>


STINNER Victor added the comment:

A new failure test_subprocess.test_double_close_on_error:

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/11411/steps/test/logs/stdio
---
Timeout (1:00:00)!
Thread 0x55aafdc0 (most recent call first):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 1407 in _execute_child
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/subprocess.py", line 855 in __init__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_subprocess.py", line 1074 in test_double_close_on_error
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 577 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/case.py", line 625 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 122 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/suite.py", line 84 in __call__
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/unittest/runner.py", line 176 in run
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1773 in _run_suite
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/support/__init__.py", line 1807 in run_unittest
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_subprocess.py", line 2532 in test_main
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1284 in runtest_inner
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 967 in runtest
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 763 in main
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/regrtest.py", line 1568 in main_in_temp_cwd
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/__main__.py", line 3 in <module>
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/runpy.py", line 85 in _run_code
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/runpy.py", line 170 in _run_module_as_main
make: *** [buildbottest] Error 1
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23771>
_______________________________________

From report at bugs.python.org  Thu Mar 26 18:57:05 2015
From: report at bugs.python.org (Peter)
Date: Thu, 26 Mar 2015 17:57:05 +0000
Subject: [issue23786] test_unaligned_buffers
 (test.test_hash.HashEqualityTestCase) ... Fatal Python error:
 Bus error
In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za>
Message-ID: <1427392625.69.0.0373265565708.issue23786@psf.upfronthosting.co.za>


Peter added the comment:

I went and recompiled with:
$ ./configure --prefix=/usr/local --enable-shared --with-hash-algorithm=siphash24

But this crashed as well.

test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error

Current thread 0x00000001 (most recent call first):
  File "/usr/local/src/Python-3.4.3/Lib/test/test_hash.py", line 89 in test_unaligned_buffers
  File "/usr/local/src/Python-3.4.3/Lib/unittest/case.py", line 577 in run
  File "/usr/local/src/Python-3.4.3/Lib/unittest/case.py", line 625 in __call__
  File "/usr/local/src/Python-3.4.3/Lib/unittest/suite.py", line 122 in run
  File "/usr/local/src/Python-3.4.3/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/local/src/Python-3.4.3/Lib/unittest/suite.py", line 122 in run
  File "/usr/local/src/Python-3.4.3/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/local/src/Python-3.4.3/Lib/unittest/suite.py", line 122 in run
  File "/usr/local/src/Python-3.4.3/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/local/src/Python-3.4.3/Lib/unittest/runner.py", line 168 in run
  File "/usr/local/src/Python-3.4.3/Lib/test/support/__init__.py", line 1769 in _run_suite
  File "/usr/local/src/Python-3.4.3/Lib/test/support/__init__.py", line 1803 in run_unittest
  File "/usr/local/src/Python-3.4.3/Lib/test/regrtest.py", line 1279 in test_runner
  File "/usr/local/src/Python-3.4.3/Lib/test/regrtest.py", line 1280 in runtest_inner
  File "/usr/local/src/Python-3.4.3/Lib/test/regrtest.py", line 978 in runtest
  File "/usr/local/src/Python-3.4.3/Lib/test/regrtest.py", line 763 in main
  File "/usr/local/src/Python-3.4.3/Lib/test/regrtest.py", line 1564 in main_in_temp_cwd
  File "/usr/local/src/Python-3.4.3/Lib/test/__main__.py", line 3 in <module>
  File "/usr/local/src/Python-3.4.3/Lib/runpy.py", line 85 in _run_code
  File "/usr/local/src/Python-3.4.3/Lib/runpy.py", line 170 in _run_module_as_main
Bus Error (core dumped)


test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xff25d3d8 in siphash24 (src=0x1d2809, src_sz=<optimized out>) at Python/pyhash.c:387
387             PY_UINT64_T mi = _le64toh(*in);
(gdb) bt
#0  0xff25d3d8 in siphash24 (src=0x1d2809, src_sz=<optimized out>) at Python/pyhash.c:387
#1  0xff25dfa0 in _Py_HashBytes (src=0x1d2809, len=127) at Python/pyhash.c:186
#2  0xff1a7ce4 in memory_hash (self=0xfdfc5dc0) at Objects/memoryobject.c:2793
#3  0xff1afa40 in PyObject_Hash (v=0xfdfc5dc0) at Objects/object.c:757
#4  0xff22b6fc in builtin_hash (self=0xfee23600, v=0xfdfc5dc0) at Python/bltinmodule.c:1269
#5  0xff236a70 in call_function (oparg=<optimized out>, pp_stack=0xffbfcd64) at Python/ceval.c:4224
#6  PyEval_EvalFrameEx (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:2838
#7  0xff237790 in fast_function (nk=<optimized out>, na=<optimized out>, n=1, pp_stack=0xffbfce5c,
    func=<optimized out>) at Python/ceval.c:4334


(gdb) list
382         PY_UINT64_T t;
383         PY_UINT8_T *pt;
384         PY_UINT8_T *m;
385
386         while (src_sz >= 8) {
387             PY_UINT64_T mi = _le64toh(*in);
388             in += 1;
389             src_sz -= 8;
390             v3 ^= mi;
391             DOUBLE_ROUND(v0,v1,v2,v3);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23786>
_______________________________________

From report at bugs.python.org  Thu Mar 26 19:18:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 18:18:18 +0000
Subject: [issue23786] test_unaligned_buffers
 (test.test_hash.HashEqualityTestCase) ... Fatal Python error:
 Bus error
In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za>
Message-ID: <1427393898.6.0.165279688986.issue23786@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Siphash24 implementation is not designed to work on platforms that require aligned access. But I'm surprised that fnv implementation crashes. I don't see anything wrong. May be gcc needs some special options to produce correct binaries on this platform?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23786>
_______________________________________

From report at bugs.python.org  Thu Mar 26 20:12:45 2015
From: report at bugs.python.org (Masayuki Yamamoto)
Date: Thu, 26 Mar 2015 19:12:45 +0000
Subject: [issue21085] compile error Python3.3 on Cygwin
In-Reply-To: <1396019829.85.0.386935527155.issue21085@psf.upfronthosting.co.za>
Message-ID: <1427397165.4.0.680147736273.issue21085@psf.upfronthosting.co.za>


Masayuki Yamamoto added the comment:

Victor,

In that case, May I edit configure script to generate the HAVE_* defines?
I'd like to add a statement to check the si_band to configure.ac.

> And please generate patches not the git format. Otherwise, Rietveld is unable to generated the "review" link.
I see.  I use the mercurial repository from next time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21085>
_______________________________________

From report at bugs.python.org  Thu Mar 26 20:42:14 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Mar 2015 19:42:14 +0000
Subject: [issue21085] compile error Python3.3 on Cygwin
In-Reply-To: <1427397165.4.0.680147736273.issue21085@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwY0N-WQfXMPzmUZ-UwCJT7qYfdq7kB=A-WaH5fhdGhO0A@mail.gmail.com>


STINNER Victor added the comment:

> In that case, May I edit configure script to generate the HAVE_* defines?
> I'd like to add a statement to check the si_band to configure.ac.

Does Cygwin use configure? If yes, go for configure.

You can copy/paste my recent change for dirent.d_type field.

> I see.  I use the mercurial repository from next time.

Are you using git or hg? If you use hg, just change the config to not use
git format. If you use git, don't worry, I can review without the review
button.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21085>
_______________________________________

From report at bugs.python.org  Thu Mar 26 20:58:33 2015
From: report at bugs.python.org (Peter)
Date: Thu, 26 Mar 2015 19:58:33 +0000
Subject: [issue23786] test_unaligned_buffers
 (test.test_hash.HashEqualityTestCase) ... Fatal Python error:
 Bus error
In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za>
Message-ID: <1427399913.78.0.0861357510972.issue23786@psf.upfronthosting.co.za>


Peter added the comment:

I've compiled Python 3.3.6 using the same options (./configure --prefix=/usr/local --enable-shared) and build system and that passes almost all the tests (test_uuid fails for an ignorable reason).

Specifically test_hash passes fully:

$ LD_LIBRARY_PATH=/usr/local/src/Python-3.3.6 ./python -m test -v test_hash
== CPython 3.3.6 (default, Mar 26 2015, 15:35:36) [GCC 4.6.2]
==   Solaris-2.11-sun4v-sparc-32bit-ELF big-endian
==   /usr/local/src/Python-3.3.6/build/test_python_4539
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1)
[1/1] test_hash
test_empty_string (test.test_hash.BytesHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_null_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.DatetimeDateTests) ... ok
test_randomized_hash (test.test_hash.DatetimeDatetimeTests) ... ok
test_randomized_hash (test.test_hash.DatetimeTimeTests) ... ok
test_hashes (test.test_hash.HashBuiltinsTestCase) ... ok
test_coerced_floats (test.test_hash.HashEqualityTestCase) ... ok
test_coerced_integers (test.test_hash.HashEqualityTestCase) ... ok
test_numeric_literals (test.test_hash.HashEqualityTestCase) ... ok
test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... ok
test_default_hash (test.test_hash.HashInheritanceTestCase) ... ok
test_error_hash (test.test_hash.HashInheritanceTestCase) ... ok
test_fixed_hash (test.test_hash.HashInheritanceTestCase) ... ok
test_hashable (test.test_hash.HashInheritanceTestCase) ... ok
test_not_hashable (test.test_hash.HashInheritanceTestCase) ... ok
test_empty_string (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_null_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_empty_string (test.test_hash.StrHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.StrHashRandomizationTests) ... ok
test_null_hash (test.test_hash.StrHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.StrHashRandomizationTests) ... ok

----------------------------------------------------------------------
Ran 25 tests in 1.356s

OK
1 test OK.


So any ideas what I should look for? Or perhaps it would be helpful if I posted config.log, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23786>
_______________________________________

From report at bugs.python.org  Thu Mar 26 22:31:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 21:31:00 +0000
Subject: [issue23786] test_unaligned_buffers
 (test.test_hash.HashEqualityTestCase) ... Fatal Python error:
 Bus error
In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za>
Message-ID: <1427405460.9.0.0486509143117.issue23786@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, 3.3 uses less efficient implementation.

Try to compile Python with gcc option -mno-unaligned-access.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23786>
_______________________________________

From report at bugs.python.org  Thu Mar 26 22:33:04 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Mar 2015 21:33:04 +0000
Subject: [issue23786] test_unaligned_buffers
 (test.test_hash.HashEqualityTestCase) ... Fatal Python error:
 Bus error
In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za>
Message-ID: <1427405584.44.0.999618149168.issue23786@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23786>
_______________________________________

From report at bugs.python.org  Thu Mar 26 22:52:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Mar 2015 21:52:05 +0000
Subject: [issue23676] Add support of UnicodeTranslateError in standard error
 handlers
In-Reply-To: <1426456748.16.0.28109004659.issue23676@psf.upfronthosting.co.za>
Message-ID: <1427406725.4.0.470899639319.issue23676@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm sorry, I don't understand this issue. Could you please elaborate the use case? Why do you want to support more error handlers? str.translate() calls _PyUnicode_TranslateCharmap() with errors="ignore", it's not possible to choose the error handler.

Many codecs are implemented in Python and some of them are implemented with "charmap". Does this issue enhance the codecs implemented with "charmap"?

"a\udc80".encode("latin9", "surrogatepass") raises UnicodeEncodeError with and without the patch, b"\x81".decode("cp1252", "surrogatepass") raises UnicodeDecodeError with and without the patch.

Hum, I'm not sure that codecs.charmap_build() is related str.translate().

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23676>
_______________________________________

From report at bugs.python.org  Thu Mar 26 22:57:38 2015
From: report at bugs.python.org (Peter)
Date: Thu, 26 Mar 2015 21:57:38 +0000
Subject: [issue23786] test_unaligned_buffers
 (test.test_hash.HashEqualityTestCase) ... Fatal Python error:
 Bus error
In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za>
Message-ID: <1427407058.27.0.883672017271.issue23786@psf.upfronthosting.co.za>


Peter added the comment:

That's not a valid option on SPARC, (see https://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html ) the flag is only available on ARM it seems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23786>
_______________________________________

From report at bugs.python.org  Thu Mar 26 23:20:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 22:20:59 +0000
Subject: [issue23676] Add support of UnicodeTranslateError in standard error
 handlers
In-Reply-To: <1426456748.16.0.28109004659.issue23676@psf.upfronthosting.co.za>
Message-ID: <1427408459.09.0.296909877347.issue23676@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

str.encode, bytes.decode and str.translate are unrelated to UnicodeTranslateError. But str.transform could be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23676>
_______________________________________

From report at bugs.python.org  Thu Mar 26 23:21:11 2015
From: report at bugs.python.org (Hammerite)
Date: Thu, 26 Mar 2015 22:21:11 +0000
Subject: [issue23550] Add to unicodedata a function to query the "Quick_Check"
 property for a character
In-Reply-To: <1425147670.05.0.762030398058.issue23550@psf.upfronthosting.co.za>
Message-ID: <1427408471.95.0.223213421492.issue23550@psf.upfronthosting.co.za>


Hammerite added the comment:

Here is a new patch. This version addresses several issues raised in review by Ezio Melotti and Berker Peksag. Where I have not (yet) addressed an issue, I have explained why not in my previous post.

I attempted to preview my changes to the documentation that are new in this patch, but processing the documentation seems to be quite an involved process, so I have not done this in the end. Therefore there might be syntax errors or other issues with the documentation changes in unicodedata.rst.

----------
Added file: http://bugs.python.org/file38705/quick_check_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23550>
_______________________________________

From report at bugs.python.org  Thu Mar 26 23:29:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Mar 2015 22:29:08 +0000
Subject: [issue23676] Add support of UnicodeTranslateError in standard error
 handlers
In-Reply-To: <1427408459.09.0.296909877347.issue23676@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb+fr7aV05WJdka=4eopNKLA6W_frVUboqBauPLrXirOg@mail.gmail.com>


STINNER Victor added the comment:

Serhiy Storchaka added the comment:
> str.encode, bytes.decode and str.translate are unrelated to UnicodeTranslateError. But str.transform could be.

Can you please give an example of Python code to show your change?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23676>
_______________________________________

From report at bugs.python.org  Thu Mar 26 23:45:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 22:45:41 +0000
Subject: [issue23676] Add support of UnicodeTranslateError in standard error
 handlers
In-Reply-To: <1426456748.16.0.28109004659.issue23676@psf.upfronthosting.co.za>
Message-ID: <1427409941.9.0.341913085415.issue23676@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

issue18814

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23676>
_______________________________________

From report at bugs.python.org  Thu Mar 26 23:51:08 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Mar 2015 22:51:08 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>
Message-ID: <20150326225104.16168.39772@psf.io>


Roundup Robot added the comment:

New changeset b7c0137cccbe by Victor Stinner in branch 'default':
Issue #23648: Document the PEP 475 in the "Porting to Python 3.5" section and
https://hg.python.org/cpython/rev/b7c0137cccbe

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Fri Mar 27 00:04:09 2015
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 26 Mar 2015 23:04:09 +0000
Subject: [issue23786] test_unaligned_buffers
 (test.test_hash.HashEqualityTestCase) ... Fatal Python error:
 Bus error
In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za>
Message-ID: <1427411049.18.0.0110141646854.issue23786@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I'm puzzled about the segfault. I'm pretty sure that I've compiled and tested the code on big endian machines as well as a SPARC machines that doesn't allow unaligned memory access. The FNV code copies the blocks to an aligned buffer to prevent exactly this bug. Serhiy spent days to optimize the code as humanly possible.

Please recompile Python again. This time create a debug build (--with-pydebug) and use the default hash function FNV for your platform. The debug build helps to pin point the bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23786>
_______________________________________

From report at bugs.python.org  Fri Mar 27 00:04:40 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Mar 2015 23:04:40 +0000
Subject: [issue23637] Warnings error with non-ascii chars.
In-Reply-To: <1426062904.63.0.0951614232281.issue23637@psf.upfronthosting.co.za>
Message-ID: <1427411080.6.0.590587411616.issue23637@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Only thing required to make this work is add "u" in front of the message so it is unicode.

The warnings module works with non-ASCII characters if you only use bytes strings. I'm not sure that we should enhance it to support the unicode type in some fields, and bytes fields in other fields.

This issue was already fixed in Python 3 with the global switch to Unicode by default for all strings.

I would prefer to not fix this issue.

Since it looks to a new feature, it's also not a good practice to add new features in minor python versions (2.7.x).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23637>
_______________________________________

From report at bugs.python.org  Fri Mar 27 00:08:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Mar 2015 23:08:57 +0000
Subject: [issue23611] Pickle nested names with protocols < 4
In-Reply-To: <1425837040.48.0.408829364916.issue23611@psf.upfronthosting.co.za>
Message-ID: <1427411337.04.0.494663414637.issue23611@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hum, I don't know well the pickle module. Is it backward compatible? Should Python 2 be able to unserialize data serialized by Python 3? If yes, can you patch break this compatibility?

It is unclear to me if it makes sense to even modify protocols different than the latest version.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23611>
_______________________________________

From report at bugs.python.org  Fri Mar 27 00:09:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 Mar 2015 23:09:49 +0000
Subject: [issue18828] urljoin behaves differently with custom and standard
 schemas
In-Reply-To: <1377435120.2.0.153064775964.issue18828@psf.upfronthosting.co.za>
Message-ID: <1427411389.22.0.584228132723.issue18828@psf.upfronthosting.co.za>


Martin Panter added the comment:

If necessary, we can add a new non_relative list, rather than changing non_hierarchical. The repository history shows that ?non_hierarchical? was updated with new schemes once or twice, but has never been used since it was added to Python as ?urlparse.py?.

IMAP, WAIS and Gopher URLs can have extra components added using slashes, which satisfies my idea of ?hierarchical?. For IMAP, I think this is explicitly mentioned in the RFC: <https://tools.ietf.org/html/rfc5092#section-7>. For WAIS, the hierarchy is not arbitrary, but your resulting URL wais://foo at bar.com/newpath probably matches the wais://<host>:<port>/<database> URL form, and I am not proposing to change that behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18828>
_______________________________________

From report at bugs.python.org  Fri Mar 27 00:17:34 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 23:17:34 +0000
Subject: [issue23611] Pickle nested names with protocols < 4
In-Reply-To: <1425837040.48.0.408829364916.issue23611@psf.upfronthosting.co.za>
Message-ID: <1427411854.77.0.197945500512.issue23611@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Pickle is backward compatible and Python 2 usually is able to unpickle data pickled by Python 3 with protocol < 3. The patch doesn't break compatibility. Current default protocol is 3 for compatibility with older Python 3 versions. It is used in multiprocessing and this is not configurable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23611>
_______________________________________

From report at bugs.python.org  Fri Mar 27 00:21:57 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Mar 2015 23:21:57 +0000
Subject: [issue23637] Warnings error with non-ascii chars.
In-Reply-To: <1426062904.63.0.0951614232281.issue23637@psf.upfronthosting.co.za>
Message-ID: <1427412117.08.0.281584603787.issue23637@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The problem is that the warnings module works with unicode message almost all time except rare circumstances. So for sure this feature is used in many programs and it works for authors and most of users. An exception can be considered as a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23637>
_______________________________________

From report at bugs.python.org  Fri Mar 27 00:39:11 2015
From: report at bugs.python.org (Josiah Carlson)
Date: Thu, 26 Mar 2015 23:39:11 +0000
Subject: [issue1191964] add non-blocking read and write methods to
 subprocess.Popen
Message-ID: <1427413151.91.0.156244400239.issue1191964@psf.upfronthosting.co.za>


Josiah Carlson added the comment:

Non-blocking IO returning a None on "no data currently available" is new to me. It is new to me simply because I don't recall it ever happening in Python 2.x with any socket IO that I ever dealt with, and socket IO is my primary source for non-blocking IO experience.

>From my experience, reading from a socket would always return a string, unless the connection was closed/broken, at which point you got a bad file descriptor exception. Writing would return 0 if the buffer was full, or a bad file descriptor exception if the connection was closed/broken. The implementation of asyncore/asynchat at least until 3.0 shows this in practice, and I doubt this has changed in the intervening years since I updated those libraries for 3.0.

My choice to implement this based on BrokenPipeError was based on reading Victor(haypo)'s comments from 2014-07-23 and 2014-07-24, in which he stated that in asyncio, when it comes to process management, .communicate() hides exceptions so that communication can finish, but direct reading and writing surface those exceptions.

I was attempting to mimic the asyncio interface simply because it made sense to me coming from the socket world, and because asyncio is where people are likely to go if the non-blocking subprocess support in subprocess is insufficient for their needs.

Note that I also initially resisted raising an exception in those methods, but Victor(haypo)'s comments changed my mind.

> Do you know a better method that would allow to distinguish between EOF (no future data, ever) and "would block" (future data possible) without calling process.poll()?

Better is subjective when it comes to API, but different? Yes, it's already implemented in patch #8. BrokenPipeError exception when no more data is sendable/receivable. A 0 or b'' when writing to a full buffer, or reading from an empty buffer. This API tries to be the same as the asyncio.subprocess.Process() behavior when accessing stdin, stdout, and stderr directly.

> Returning None for non blocking I/O is standard in Python.

In some contexts, yes. In others, no. The asyncio.StreamReader() coroutines .read(), .readline(), and .readexactly() return strings. Raw async or sync sockets don't return None on read. SSL-wrapped async or sync sockets don't return None on read. Asyncio low-level socket operations don't yield None on a (currently empty) read.


In the context of the subprocess module as it exists in 3.4 (and 3.5 as it is unpatched), the only object that returns None on read when no data is available, but where data *might* be available in the future, is an underlying posix pipe (on posix platforms) - which isn't generally used directly.

The purpose of this patch is to expose stdin, stdout, and stderr in a way that allows non-blocking reads and writes from the subprocess that also plays nicely with .communicate() as necessary. Directly exposing the pipes doesn't work due to API inconsistencies between Windows and posix, so we have to add a layer.

I would argue that this layer of non-blocking (Windows and posix) pipe abstraction has much more in common with how asyncio deals with process IO, or how sockets deal with IO, than it does with pipes in general (the vast majority of which are blocking), so I would contend that it should have a similar API (no returning None).

That said, considering that the expected use of non-blocking subprocess communication *does not* include using a multiplexer (select, poll, etc.), I have the sense that a few other higher-level methods might be warranted to ease use substantially, and which I would expect people would end up using much more often than the lower-level direct read/write operations (different names might make more sense here):
.write_all(data, timeout=None)
.read_available(bufsize=-1) (and .read_stderr_available)
.read_exactly(bufsize, timeout=None) (and .read_stderr_exactly)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1191964>
_______________________________________

From report at bugs.python.org  Fri Mar 27 01:15:37 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 Mar 2015 00:15:37 +0000
Subject: [issue23290] Faster set copying
In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za>
Message-ID: <1427415337.18.0.202062889537.issue23290@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Is msg234811 the result of set_faster_copy_3.patch? If yes, I see no reason to not apply the patch: the patch is short and looks always fast, and sometimes *much* faster.

I just leaved a small comment on the review.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23290>
_______________________________________

From report at bugs.python.org  Fri Mar 27 01:25:31 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 Mar 2015 00:25:31 +0000
Subject: [issue23611] Pickle nested names with protocols < 4
In-Reply-To: <1427411854.77.0.197945500512.issue23611@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ6w3YPUPEM7mjEfvAo7Eg-4wCUL8PMW3WMJtDQjMnEjg@mail.gmail.com>


STINNER Victor added the comment:

> It is used in multiprocessing and this is not configurable.

Oh, it would be nice to switch to version 4 by default, or make it
configurable. I read that the version 4 is faster.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23611>
_______________________________________

From report at bugs.python.org  Fri Mar 27 01:25:43 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Mar 2015 00:25:43 +0000
Subject: [issue23529] Limit decompressed data when reading from LZMAFile and
 BZ2File
In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za>
Message-ID: <1427415943.3.0.652126471619.issue23529@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Is it still work-in-progress or are you looking for a review?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23529>
_______________________________________

From report at bugs.python.org  Fri Mar 27 01:31:07 2015
From: report at bugs.python.org (Nikolaus Rath)
Date: Fri, 27 Mar 2015 00:31:07 +0000
Subject: [issue23529] Limit decompressed data when reading from LZMAFile and
 BZ2File
In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za>
Message-ID: <1427416267.84.0.416251871009.issue23529@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

I believe Martin's patch (v8) is ready for a core committer review. At least I can't find anything to criticize anymore :-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23529>
_______________________________________

From report at bugs.python.org  Fri Mar 27 02:10:36 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 Mar 2015 01:10:36 +0000
Subject: [issue13322] buffered read() and write() does not raise
 BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1427418636.24.0.0703339568531.issue13322@psf.upfronthosting.co.za>


Martin Panter added the comment:

See also Issue 1191964, discussing inconsistencies and how to differentiate the four non-blocking special results in a new API:

* read signals permanent EOF
* read signals no data temporarily available
* write signals a permanently broken pipe or connection
* write signals no buffer space temporarily available

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13322>
_______________________________________

From report at bugs.python.org  Fri Mar 27 02:31:12 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 Mar 2015 01:31:12 +0000
Subject: [issue1191964] add non-blocking read and write methods to
 subprocess.Popen
Message-ID: <1427419872.06.0.828019987541.issue1191964@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes, I think the special return value of None is only standard to the ?io? module, which was added in Python 2.6 and 3. And even there it is inconsistent.

For what it?s worth, don?t have strong opinions on the special non-blocking and broken pipe cases, as long as they can be differentiated. So the current situation is fine by me. Just that potentially surprising differences with other APIs [e.g. read() -> b"" means empty buffer, not closed pipe] need documenting.

The asyncio.StreamReader.read() etc methods are documented as coroutines, so the problem of differentiating an empty buffer from a closed pipe does not exist there.

Just a thought: would it make sense for these methods to be decoupled from the subprocess class, and generalized to apply to any pipes, as a kind of Windows vs POSIX abstraction layer? Then you wouldn?t have to add duplicate methods like read_stderr_available() and read_stderr_exactly() all the time. You might also have a more portable way of doing non-blocking reads from sys.stdin, etc as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1191964>
_______________________________________

From report at bugs.python.org  Fri Mar 27 03:16:37 2015
From: report at bugs.python.org (Ben Hoyt)
Date: Fri, 27 Mar 2015 02:16:37 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1427422597.73.0.399490895717.issue23605@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

Victor, great work on pushing this out, especially with the "modifying the directories" fix. (And thanks Serhiy for pushing on correctness here.)

Couple of comments/questions about your new os.walk() implementation.

1) The new implementation is more complex. Of course, most of this is necessary due to the topdown directory issue. However, one thing I'm not sure about is why you create scandir_it manually and use a while True loop, adding complexity and making it require two versions of the error handling. Why not a simple "for entry in scandir(top): ..." with a try/except OSError around the whole loop? I could well be missing something here though.

2) In this commit http://bugs.python.org/review/23605/diff/14181/Lib/os.py -- which is not the final one, I don't quite understand the catch_oserror thing. Presumably this turned out to be unnecessary, as it's not in the final version?

3) Really minor thing: in one of the comments, you misspell "symbolik". Should be "symbolic".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Fri Mar 27 05:15:18 2015
From: report at bugs.python.org (eryksun)
Date: Fri, 27 Mar 2015 04:15:18 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1427429718.39.0.708168334628.issue4944@psf.upfronthosting.co.za>


eryksun added the comment:

Emil,

Your example child process opens the file with only read sharing, which fails with a sharing violation if some other process inherits the file handle with write access. The `with` block only prevents this in a single-threaded environment. When you spawn 10 children, each from a separate thread, there's a good chance that one child will inherit a handle that triggers a sharing violation in another child.

Using close_fds is a blunt solution since it prevents inheriting all inheritable handles. What you really need here has actually already been done for you. Just use the file descriptor that mkstemp returns, i.e. use os.fdopen(infd, 'wb'). mkstemp opens the file with O_NOINHERIT set in the flags.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Fri Mar 27 07:01:42 2015
From: report at bugs.python.org (Emil Styrke)
Date: Fri, 27 Mar 2015 06:01:42 +0000
Subject: [issue4944] os.fsync() doesn't work as expect in Windows
In-Reply-To: <1231908179.96.0.0909501927453.issue4944@psf.upfronthosting.co.za>
Message-ID: <1427436102.08.0.942340919528.issue4944@psf.upfronthosting.co.za>


Emil Styrke added the comment:

eryksun, thank you for the explanation, the penny finally dropped for me.  It's the *other* child processes that keep the file open, not the parent.  Actually this bug started hitting me after I *stopped* doing exactly what you suggest (fdopen on the temp file), and instead started using file names generated by my program (opened with regular "open") and now I see why that is.  If I use os.fdopen with the O_NOINHERIT flag, it works as expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4944>
_______________________________________

From report at bugs.python.org  Fri Mar 27 08:37:46 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Mar 2015 07:37:46 +0000
Subject: [issue23290] Faster set copying
In-Reply-To: <1421848208.43.0.905402107396.issue23290@psf.upfronthosting.co.za>
Message-ID: <1427441866.46.0.858305144252.issue23290@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses Victor's comment. Thank you for your review Victor.

> Is msg234811 the result of set_faster_copy_3.patch?

Yes, it is. There are tests for sets with small and large number of hash conflicts, with and without dummy objects. The patch affects many operations that implicitly makes a copy, for example set1 | set2, set1 & set2, set1 - set2.

----------
Added file: http://bugs.python.org/file38706/set_faster_copy_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23290>
_______________________________________

From report at bugs.python.org  Fri Mar 27 08:38:56 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 Mar 2015 07:38:56 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1427422597.73.0.399490895717.issue23605@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbf7y1FSsyimy6fWx71NbEgoib5SuBmqjT=STDNmZxz-g@mail.gmail.com>


STINNER Victor added the comment:

Ben Hoyt added the comment:
> 1) The new implementation is more complex. Of course, most of this is
necessary due to the topdown directory issue.

Sure,  correctness matters more than performances.

> However, one thing I'm not sure about is why you create scandir_it
manually and use a while True loop,

The idea is to control lines where OSError is catched to call onerrror(),
without breaking backward compatibility. Especially, onerror() should only
be called once, even for recursive calls.

> 2) In this commit http://bugs.python.org/review/23605/diff/14181/Lib/os.py
-- which is not the final one, I don't quite understand the catch_oserror
thing.
It's just a try to write differently the same thing. It didn't convince
myself that it's more readable, so I picked the first version.

What's your point about complexity? Would you like to drop os.scandir
changes in os.walk(), or do you have a simpler version to propose?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Fri Mar 27 08:48:47 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 Mar 2015 07:48:47 +0000
Subject: [issue23290] Faster set copying
In-Reply-To: <1427441866.46.0.858305144252.issue23290@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwY7SAnNuAywDgQ2gySeUUTYaXuuUg_0+kMTOCZuwdHMpw@mail.gmail.com>


STINNER Victor added the comment:

New patch looks good to me. Great job on speedup. I didn't expect that it's
still possible to enhance set.

By the way, is it possible to report latest enhancement to the dict type? I
don't remember if tou tried that richard?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23290>
_______________________________________

From report at bugs.python.org  Fri Mar 27 08:58:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Mar 2015 07:58:55 +0000
Subject: [issue23488] Random objects twice as big as necessary on 64-bit builds
In-Reply-To: <1424427522.46.0.066480034722.issue23488@psf.upfronthosting.co.za>
Message-ID: <1427443135.48.0.646771720129.issue23488@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses some Victor's comments.

----------
Added file: http://bugs.python.org/file38707/random_uint32_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23488>
_______________________________________

From report at bugs.python.org  Fri Mar 27 09:26:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Mar 2015 08:26:23 +0000
Subject: [issue23509] Speed up Counter operators
In-Reply-To: <1424771022.43.0.932025143765.issue23509@psf.upfronthosting.co.za>
Message-ID: <1427444783.4.0.771181117539.issue23509@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added explanation comments to address Victor's comment.

----------
Added file: http://bugs.python.org/file38708/counter_faster_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23509>
_______________________________________

From report at bugs.python.org  Fri Mar 27 09:38:56 2015
From: report at bugs.python.org (Florian Bruhin)
Date: Fri, 27 Mar 2015 08:38:56 +0000
Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with
 VC Express
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1427445536.84.0.617680344707.issue7511@psf.upfronthosting.co.za>


Changes by Florian Bruhin <python.org at the-compiler.org>:


----------
nosy: +The Compiler

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Fri Mar 27 09:41:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Mar 2015 08:41:20 +0000
Subject: [issue23290] Faster set copying
In-Reply-To: <CAMpsgwY7SAnNuAywDgQ2gySeUUTYaXuuUg_0+kMTOCZuwdHMpw@mail.gmail.com>
Message-ID: <2240181.5X1aLjLSM8@raxxla>


Serhiy Storchaka added the comment:

> I didn't expect that it's still possible to enhance set.

Raymond made a lot of set optimizations recently.

> By the way, is it possible to report latest enhancement to the dict type? I
> don't remember if tou tried that richard?

May be when Raymond port his optimizations to dict (issue18898).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23290>
_______________________________________

From report at bugs.python.org  Fri Mar 27 09:54:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 Mar 2015 08:54:17 +0000
Subject: [issue18898] Apply the setobject optimizations to dictionaries
In-Reply-To: <1378012493.62.0.577402281969.issue18898@psf.upfronthosting.co.za>
Message-ID: <1427446457.39.0.569673753462.issue18898@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hi, what's the status of this issue? Is anyone working one it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18898>
_______________________________________

From report at bugs.python.org  Fri Mar 27 09:59:42 2015
From: report at bugs.python.org (Paul Moore)
Date: Fri, 27 Mar 2015 08:59:42 +0000
Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with
 VC Express
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1427446782.83.0.219233321007.issue7511@psf.upfronthosting.co.za>


Paul Moore added the comment:

The correct solution to this issue now is to install the Microsoft supplied "Visual C++ Compiler for Python 2.7" package (available as a free download from MSDN). That has all the components needed to build 32 and 64-bit extensions. Your setup.py needs to use setuptools (as there is a setuptools extension to recognise this compiler package) but otherwise the process should be seamless.

Note that in spite of the name, the process should also work for Python 3.2 and 3.3, which also use VS2008 (but I haven't tested that explicitly).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Fri Mar 27 10:59:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Mar 2015 09:59:26 +0000
Subject: [issue23786] test_unaligned_buffers
 (test.test_hash.HashEqualityTestCase) ... Fatal Python error:
 Bus error
In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za>
Message-ID: <1427450366.75.0.989012338617.issue23786@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What if add double field in the block union? (And may be compile with -munaligned-doubles)


diff -r a417d89fbc38 Python/pyhash.c
--- a/Python/pyhash.c   Thu Mar 26 09:37:23 2015 +0100
+++ b/Python/pyhash.c   Fri Mar 27 11:52:25 2015 +0200
@@ -247,6 +247,7 @@ fnv(const void *src, Py_ssize_t len)
     union {
         Py_uhash_t value;
         unsigned char bytes[SIZEOF_PY_UHASH_T];
+        double double_value;
     } block;
 
 #ifdef Py_DEBUG


What if add the __aligned__ attribute?

diff -r a417d89fbc38 Python/pyhash.c
--- a/Python/pyhash.c   Thu Mar 26 09:37:23 2015 +0100
+++ b/Python/pyhash.c   Fri Mar 27 11:58:30 2015 +0200
@@ -247,7 +247,7 @@ fnv(const void *src, Py_ssize_t len)
     union {
         Py_uhash_t value;
         unsigned char bytes[SIZEOF_PY_UHASH_T];
-    } block;
+    } block __attribute__ ((__aligned__(SIZEOF_PY_UHASH_T)));
 
 #ifdef Py_DEBUG
     assert(_Py_HashSecret_Initialized);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23786>
_______________________________________

From report at bugs.python.org  Fri Mar 27 11:04:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Mar 2015 10:04:01 +0000
Subject: [issue23786] test_unaligned_buffers
 (test.test_hash.HashEqualityTestCase) ... Fatal Python error:
 Bus error
In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za>
Message-ID: <1427450641.75.0.910095513534.issue23786@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Or may be better to use explicit alignment 8 if this is 32-bit platform.

diff -r a417d89fbc38 Python/pyhash.c
--- a/Python/pyhash.c   Thu Mar 26 09:37:23 2015 +0100
+++ b/Python/pyhash.c   Fri Mar 27 12:02:55 2015 +0200
@@ -247,7 +247,7 @@ fnv(const void *src, Py_ssize_t len)
     union {
         Py_uhash_t value;
         unsigned char bytes[SIZEOF_PY_UHASH_T];
-    } block;
+    } block __attribute__ ((__aligned__(8)));
 
 #ifdef Py_DEBUG
     assert(_Py_HashSecret_Initialized);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23786>
_______________________________________

From report at bugs.python.org  Fri Mar 27 11:40:36 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 Mar 2015 10:40:36 +0000
Subject: [issue23786] test_unaligned_buffers
 (test.test_hash.HashEqualityTestCase) ... Fatal Python error:
 Bus error
In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za>
Message-ID: <1427452836.64.0.0170897182166.issue23786@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The union trick is not portable, using memcpy() is safer. Compilers should be able to optimize it. Use Py_MEMCPY() for the stupid Visual Studio compiler unable to optimize memcpy() for small sizes.

----------
keywords: +patch
Added file: http://bugs.python.org/file38709/fnv_memcpy.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23786>
_______________________________________

From report at bugs.python.org  Fri Mar 27 12:08:32 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Mar 2015 11:08:32 +0000
Subject: [issue23786] test_unaligned_buffers
 (test.test_hash.HashEqualityTestCase) ... Fatal Python error:
 Bus error
In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za>
Message-ID: <1427454512.57.0.7237914709.issue23786@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

AFAIK it conforms the C standard and should be portable (but weird compiler bugs or misconfiguration can make it broken).

With Py_MEMCPY() the code is less optimal. Don't add regression on common platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23786>
_______________________________________

From report at bugs.python.org  Fri Mar 27 12:24:06 2015
From: report at bugs.python.org (Valentine Sinitsyn)
Date: Fri, 27 Mar 2015 11:24:06 +0000
Subject: [issue23787] sum() function docstring lists arguments incorrectly
Message-ID: <1427455446.97.0.658394608092.issue23787@psf.upfronthosting.co.za>


New submission from Valentine Sinitsyn:

sum() function doctstring describes expected arguments as follows (Python 2.7.6):

sum(...)
    sum(sequence[, start]) -> value
...

This implies sum() should accept str, unicode, list, tuple, bytearray, buffer, and xrange. However, you clearly can't use this function to sum strings (which is also mentioned in the docstring):

>>> sum('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'

I'd suggest to describe first argument as iterable, which is actually what sum() expects there.

----------
assignee: docs at python
components: Documentation
messages: 239388
nosy: docs at python, vsinitsyn
priority: normal
severity: normal
status: open
title: sum() function docstring lists arguments incorrectly
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23787>
_______________________________________

From report at bugs.python.org  Fri Mar 27 13:13:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Mar 2015 12:13:23 +0000
Subject: [issue23611] Pickle nested names with protocols < 4
In-Reply-To: <1425837040.48.0.408829364916.issue23611@psf.upfronthosting.co.za>
Message-ID: <1427458403.2.0.437159001081.issue23611@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Issue23403. But looks it is early yet for this.

Note that this patch doesn't modify protocols. It just makes the pickler more smart and able to serialize more objects with existing protocols. It is the same as add pickle support for some type that didn't support the pickling before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23611>
_______________________________________

From report at bugs.python.org  Fri Mar 27 13:18:21 2015
From: report at bugs.python.org (Raniere Silva)
Date: Fri, 27 Mar 2015 12:18:21 +0000
Subject: [issue23788] test_bad_address fails
Message-ID: <1427458701.93.0.881295834482.issue23788@psf.upfronthosting.co.za>


New submission from Raniere Silva:

Starting from Git commit 1996f3038458df2b6443c23e4705478ff5db43f8

$ ./configure
$ make
$ make test
======================================================================
FAIL: test_bad_address (test.test_urllib2_localnet.TestUrlopen)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/raniere/src/cpython/Lib/test/test_urllib2_localnet.py", line 656, in test_bad_address
    "http://sadflkjsasf.i.nvali.d./")
AssertionError: OSError not raised by urlopen

----------------------------------------------------------------------

----------
components: Tests
messages: 239390
nosy: raniere
priority: normal
severity: normal
status: open
title: test_bad_address fails
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23788>
_______________________________________

From report at bugs.python.org  Fri Mar 27 13:33:52 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 Mar 2015 12:33:52 +0000
Subject: [issue23788] test_urllib2_localnet.test_bad_address fails: OSError
 not raised by urlopen
In-Reply-To: <1427458701.93.0.881295834482.issue23788@psf.upfronthosting.co.za>
Message-ID: <1427459632.41.0.440616075378.issue23788@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: test_bad_address fails -> test_urllib2_localnet.test_bad_address fails: OSError not raised by urlopen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23788>
_______________________________________

From report at bugs.python.org  Fri Mar 27 13:41:32 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 Mar 2015 12:41:32 +0000
Subject: [issue23788] test_urllib2_localnet.test_bad_address fails: OSError
 not raised by urlopen
In-Reply-To: <1427458701.93.0.881295834482.issue23788@psf.upfronthosting.co.za>
Message-ID: <1427460092.52.0.204731420287.issue23788@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Starting from Git commit 1996f3038458df2b6443c23e4705478ff5db43f8

https://github.com/python/cpython/commit/1996f3038458df2b6443c23e4705478ff5db43f8

=> https://hg.python.org/cpython/rev/b7c0137cccbe

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23788>
_______________________________________

From report at bugs.python.org  Fri Mar 27 13:43:04 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 Mar 2015 12:43:04 +0000
Subject: [issue23788] test_urllib2_localnet.test_bad_address fails: OSError
 not raised by urlopen
In-Reply-To: <1427458701.93.0.881295834482.issue23788@psf.upfronthosting.co.za>
Message-ID: <1427460184.8.0.193099970073.issue23788@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hi,

Can you please complete your bug report? Can you specifiy your OS? Can you try to rerun the test manually with "./python -m test -u all test_urllib2_localnet"?

The test:

    def test_bad_address(self):
        # Make sure proper exception is raised when connecting to a bogus
        # address.

        # as indicated by the comment below, this might fail with some ISP,
        # so we run the test only when -unetwork/-uall is specified to
        # mitigate the problem a bit (see #17564)
        support.requires('network')
        self.assertRaises(OSError,
                          # Given that both VeriSign and various ISPs have in
                          # the past or are presently hijacking various invalid
                          # domain name requests in an attempt to boost traffic
                          # to their own sites, finding a domain name to use
                          # for this test is difficult.  RFC2606 leads one to
                          # believe that '.invalid' should work, but experience
                          # seemed to indicate otherwise.  Single character
                          # TLDs are likely to remain invalid, so this seems to
                          # be the best choice. The trailing '.' prevents a
                          # related problem: The normal DNS resolver appends
                          # the domain names from the search path if there is
                          # no '.' the end and, and if one of those domains
                          # implements a '*' rule a result is returned.
                          # However, none of this will prevent the test from
                          # failing if the ISP hijacks all invalid domain
                          # requests.  The real solution would be to be able to
                          # parameterize the framework with a mock resolver.
                          urllib.request.urlopen,
                          "http://sadflkjsasf.i.nvali.d./")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23788>
_______________________________________

From report at bugs.python.org  Fri Mar 27 13:53:43 2015
From: report at bugs.python.org (Peter)
Date: Fri, 27 Mar 2015 12:53:43 +0000
Subject: [issue23786] test_unaligned_buffers
 (test.test_hash.HashEqualityTestCase) ... Fatal Python error:
 Bus error
In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za>
Message-ID: <1427460823.64.0.558961130062.issue23786@psf.upfronthosting.co.za>


Peter added the comment:

OK I recompiled with "./configure --prefix=/usr/local --enable-shared --with-pydebug" and reran the test, unfortunately...

$ LD_LIBRARY_PATH=/usr/local/src/Python-3.4.3 ./python -m test  test_hash
[1/1] test_hash
1 test OK.


I then applied the patch in msg239385, this resulted in the same crash, I couldn't see any difference in gdb.

I then tried each of the patches in msg239384, with -munaligned-doubles and with -mnounaligned-doubles, again no difference.

I did notice that two tests failed in test_hash prior to the core dump, so here are the outputs from those in case that helps.

<3.4.3 ./python -m test  -v test_hash.DatetimeDatetimeTests test_hash.DatetimeTimeTests
== CPython 3.4.3 (default, Mar 27 2015, 08:45:04) [GCC 4.6.2]
==   Solaris-2.11-sun4v-sparc-32bit-ELF big-endian
==   hash algorithm: fnv 32bit
==   /usr/local/src/Python-3.4.3/build/test_python_10340
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[1/2] test_hash.DatetimeDatetimeTests
test test_hash.DatetimeDatetimeTests crashed -- Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 2218, 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 "/usr/local/src/Python-3.4.3/Lib/test/regrtest.py", line 1271, in runtest_inner
    the_module = importlib.import_module(abstest)
  File "/usr/local/src/Python-3.4.3/Lib/importlib/__init__.py", line 109, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 2254, in _gcd_import
  File "<frozen importlib._bootstrap>", line 2237, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2221, in _find_and_load_unlocked
ImportError: No module named 'test.test_hash.DatetimeDatetimeTests'; 'test.test_hash' is not a package

[2/2/1] test_hash.DatetimeTimeTests
test test_hash.DatetimeTimeTests crashed -- Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 2218, 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 "/usr/local/src/Python-3.4.3/Lib/test/regrtest.py", line 1271, in runtest_inner
    the_module = importlib.import_module(abstest)
  File "/usr/local/src/Python-3.4.3/Lib/importlib/__init__.py", line 109, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 2254, in _gcd_import
  File "<frozen importlib._bootstrap>", line 2237, in _find_and_load
  File "<frozen importlib._bootstrap>", line 2221, in _find_and_load_unlocked
ImportError: No module named 'test.test_hash.DatetimeTimeTests'; 'test.test_hash' is not a package

2 tests failed:
    test_hash.DatetimeDatetimeTests test_hash.DatetimeTimeTests



Thanks guys!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23786>
_______________________________________

From report at bugs.python.org  Fri Mar 27 14:01:14 2015
From: report at bugs.python.org (Paul Eckhardt)
Date: Fri, 27 Mar 2015 13:01:14 +0000
Subject: [issue23789] decimal.Decimal: __format__ behaviour
Message-ID: <1427461273.99.0.604875598845.issue23789@psf.upfronthosting.co.za>


New submission from Paul Eckhardt:

The bahaviour of __format__ for decimal.Decimal type differs in one detail from float:
The minimum number of digits used for the exponent is 1 for Decimal, and 2 for float.
e.g.: "{:8.2E}".format(1.0) --> "1.00E+00"
      "{:8.2E}".format(Decimal(1.0)) --> " 1.00E+0"

Is there any reason for this?
If not, the following patch should do:

--- /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/decimal.py	2015-03-27 12:55:22.000000000 +0100
+++ ./decimal.py	2015-03-27 14:00:09.000000000 +0100
@@ -6116,7 +6116,7 @@
 
     if exp != 0 or spec['type'] in 'eE':
         echar = {'E': 'E', 'e': 'e', 'G': 'E', 'g': 'e'}[spec['type']]
-        fracpart += "{0}{1:+}".format(echar, exp)
+        fracpart += "{0}{1:+03d}".format(echar, exp)
     if spec['type'] == '%':
         fracpart += '%'

----------
components: Library (Lib)
messages: 239394
nosy: MonsieurPaul
priority: normal
severity: normal
status: open
title: decimal.Decimal: __format__ behaviour
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23789>
_______________________________________

From report at bugs.python.org  Fri Mar 27 14:02:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Mar 2015 13:02:55 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <20150327130200.82166.2202@psf.io>


Roundup Robot added the comment:

New changeset 2309597e7a00 by Victor Stinner in branch 'default':
Issue #22117: Add a new Python timestamp format _PyTime_t to pytime.h
https://hg.python.org/cpython/rev/2309597e7a00

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Fri Mar 27 14:05:10 2015
From: report at bugs.python.org (Oskar Hahn)
Date: Fri, 27 Mar 2015 13:05:10 +0000
Subject: [issue23790] When xdrlib.Packer().pack_string() fails,
 the Packer is corrupted
Message-ID: <1427461510.09.0.808726067558.issue23790@psf.upfronthosting.co.za>


New submission from Oskar Hahn:

When xdrlib.Packer().pack_string() is called with an unsupported value, it raises a TypeError. But it calles self.pack_uint(n) before it raises the exception so the buffer is changed.

There are two possible solutions to solve this behaviour. The argument s can be tested to be supported, or undo the call of self.pack_uint(n).

I added two alternative patches for this two solutions.

This is my first patch for cpython, I hope it is ok.

----------
components: Library (Lib)
files: test_value.patch
keywords: patch
messages: 239396
nosy: ostcar
priority: normal
severity: normal
status: open
title: When xdrlib.Packer().pack_string() fails, the Packer is corrupted
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38710/test_value.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23790>
_______________________________________

From report at bugs.python.org  Fri Mar 27 14:05:29 2015
From: report at bugs.python.org (Oskar Hahn)
Date: Fri, 27 Mar 2015 13:05:29 +0000
Subject: [issue23790] When xdrlib.Packer().pack_string() fails,
 the Packer is corrupted
In-Reply-To: <1427461510.09.0.808726067558.issue23790@psf.upfronthosting.co.za>
Message-ID: <1427461529.87.0.242349390276.issue23790@psf.upfronthosting.co.za>


Changes by Oskar Hahn <mail at oshahn.de>:


Added file: http://bugs.python.org/file38711/reset_buffer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23790>
_______________________________________

From report at bugs.python.org  Fri Mar 27 14:05:46 2015
From: report at bugs.python.org (Peter)
Date: Fri, 27 Mar 2015 13:05:46 +0000
Subject: [issue23786] test_unaligned_buffers
 (test.test_hash.HashEqualityTestCase) ... Fatal Python error:
 Bus error
In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za>
Message-ID: <1427461546.89.0.427752376415.issue23786@psf.upfronthosting.co.za>


Peter added the comment:

Sorry I copied the wrong term buffer :-)
This is the output after I commented out the HashEqualityTestCase class which causes the core dump.

LD_LIBRARY_PATH=/usr/local/src/Python-3.4.3 ./python -m test -v test_hash
== CPython 3.4.3 (default, Mar 27 2015, 08:45:04) [GCC 4.6.2]
==   Solaris-2.11-sun4v-sparc-32bit-ELF big-endian
==   hash algorithm: fnv 32bit
==   /usr/local/src/Python-3.4.3/build/test_python_10730
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_
site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
[1/1] test_hash
test_empty_string (test.test_hash.BytesHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_long_fixed_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_null_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.BytesHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.DatetimeDateTests) ... ok
test_randomized_hash (test.test_hash.DatetimeDatetimeTests) ... FAIL
test_randomized_hash (test.test_hash.DatetimeTimeTests) ... FAIL
test_hashes (test.test_hash.HashBuiltinsTestCase) ... ok
test_hash_distribution (test.test_hash.HashDistributionTestCase) ... ok
test_default_hash (test.test_hash.HashInheritanceTestCase) ... ok
test_error_hash (test.test_hash.HashInheritanceTestCase) ... ok
test_fixed_hash (test.test_hash.HashInheritanceTestCase) ... ok
test_hashable (test.test_hash.HashInheritanceTestCase) ... ok
test_not_hashable (test.test_hash.HashInheritanceTestCase) ... ok
test_empty_string (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_long_fixed_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_null_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.MemoryviewHashRandomizationTests) ... ok
test_empty_string (test.test_hash.StrHashRandomizationTests) ... ok
test_fixed_hash (test.test_hash.StrHashRandomizationTests) ... ok
test_long_fixed_hash (test.test_hash.StrHashRandomizationTests) ... ok
test_null_hash (test.test_hash.StrHashRandomizationTests) ... ok
test_randomized_hash (test.test_hash.StrHashRandomizationTests) ... ok
test_ucs2_string (test.test_hash.StrHashRandomizationTests) ... ok

======================================================================
FAIL: test_randomized_hash (test.test_hash.DatetimeDatetimeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/src/Python-3.4.3/Lib/test/test_hash.py", line 193, in test_randomized_hash
    run1 = self.get_hash(self.repr_, seed='random')
  File "/usr/local/src/Python-3.4.3/Lib/test/test_hash.py", line 187, in get_hash
    **env)
  File "/usr/local/src/Python-3.4.3/Lib/test/script_helper.py", line 106, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/usr/local/src/Python-3.4.3/Lib/test/script_helper.py", line 92, in _assert_python
    err.decode('ascii', 'ignore')))
AssertionError: Process return code is -10, command line was: ['/usr/local/src/Python-3.4.3/python', '-X', 'faulthandle
r', '-c', 'import datetime; print(hash(datetime.datetime(1, 2, 3, 4, 5, 6, 7)))'], stderr follows:
Fatal Python error: Bus error

Current thread 0x00000001 (most recent call first):
  File "<string>", line 1 in <module>

======================================================================
FAIL: test_randomized_hash (test.test_hash.DatetimeTimeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/src/Python-3.4.3/Lib/test/test_hash.py", line 193, in test_randomized_hash
    run1 = self.get_hash(self.repr_, seed='random')
  File "/usr/local/src/Python-3.4.3/Lib/test/test_hash.py", line 187, in get_hash
    **env)
  File "/usr/local/src/Python-3.4.3/Lib/test/script_helper.py", line 106, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/usr/local/src/Python-3.4.3/Lib/test/script_helper.py", line 92, in _assert_python
    err.decode('ascii', 'ignore')))
AssertionError: Process return code is -10, command line was: ['/usr/local/src/Python-3.4.3/python', '-X', 'faulthandle
r', '-c', 'import datetime; print(hash(datetime.time(0, 0)))'], stderr follows:
Fatal Python error: Bus error

Current thread 0x00000001 (most recent call first):
  File "<string>", line 1 in <module>

----------------------------------------------------------------------
Ran 26 tests in 3.429s

FAILED (failures=2)
test test_hash failed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23786>
_______________________________________

From report at bugs.python.org  Fri Mar 27 14:07:58 2015
From: report at bugs.python.org (Raniere Silva)
Date: Fri, 27 Mar 2015 13:07:58 +0000
Subject: [issue23788] test_urllib2_localnet.test_bad_address fails: OSError
 not raised by urlopen
In-Reply-To: <1427458701.93.0.881295834482.issue23788@psf.upfronthosting.co.za>
Message-ID: <1427461678.73.0.387431035626.issue23788@psf.upfronthosting.co.za>


Raniere Silva added the comment:

> Can you please complete your bug report? Can you specifiy your OS?

GNU/Linux.

$ uname -a
Linux pupunha 3.19.2-1-ARCH #1 SMP PREEMPT Wed Mar 18 16:21:02 CET 2015 x86_64 GNU/Linux
$ gcc --version
gcc (GCC) 4.9.2 20150304 (prerelease)

> Can you try to rerun the test manually with "./python -m test -u all test_urllib2_localnet"?

$ ./python -m test -u all test_urllib2_localnet
[1/1] test_urllib2_localnet
test test_urllib2_localnet failed -- Traceback (most recent call last):
  File "/home/raniere/src/cpython/Lib/test/test_urllib2_localnet.py", line 656, in test_bad_address
    "http://sadflkjsasf.i.nvali.d./")
AssertionError: OSError not raised by urlopen

1 test failed:
    test_urllib2_localnet

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23788>
_______________________________________

From report at bugs.python.org  Fri Mar 27 14:13:57 2015
From: report at bugs.python.org (Peter)
Date: Fri, 27 Mar 2015 13:13:57 +0000
Subject: [issue23786] test_unaligned_buffers
 (test.test_hash.HashEqualityTestCase) ... Fatal Python error:
 Bus error
In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za>
Message-ID: <1427462037.57.0.25541618202.issue23786@psf.upfronthosting.co.za>


Peter added the comment:

Hi haypo,

I just realized you had created a patch too, the fnv_memcpy.patch worked!

$ LD_LIBRARY_PATH=/usr/local/src/Python-3.4.3 ./python -m test test_hash
[1/1] test_hash
1 test OK.

Running the full regression test now, but I bet everything passes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23786>
_______________________________________

From report at bugs.python.org  Fri Mar 27 14:20:48 2015
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 27 Mar 2015 13:20:48 +0000
Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with
 VC Express
In-Reply-To: <1427446782.83.0.219233321007.issue7511@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-MPQn_VcZ=HPnq4_ChZiz___NXFpHmhGVigPE98046z_A@mail.gmail.com>


Zachary Ware added the comment:

Paul Moore added the comment:
>
> Note that in spite of the name, the process should also work for Python
> 3.2 and 3.3, which also use VS2008 (but I haven't tested that explicitly).
>

Just 3.2; 3.3 was the first version to use VS2010.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7511>
_______________________________________

From report at bugs.python.org  Fri Mar 27 14:29:47 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Mar 2015 13:29:47 +0000
Subject: [issue23451] Deprecation warnings building 3.5 Visual Studio Windows
 8.1 64 bit
In-Reply-To: <1423697646.35.0.470486317043.issue23451@psf.upfronthosting.co.za>
Message-ID: <20150327132944.16924.56342@psf.io>


Roundup Robot added the comment:

New changeset f64d0b99d405 by Victor Stinner in branch 'default':
Issue #23451, #22117: Python 3.5 now requires Windows Vista or newer, so
https://hg.python.org/cpython/rev/f64d0b99d405

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23451>
_______________________________________

From report at bugs.python.org  Fri Mar 27 14:29:48 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Mar 2015 13:29:48 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <20150327132945.16924.23464@psf.io>


Roundup Robot added the comment:

New changeset f64d0b99d405 by Victor Stinner in branch 'default':
Issue #23451, #22117: Python 3.5 now requires Windows Vista or newer, so
https://hg.python.org/cpython/rev/f64d0b99d405

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Fri Mar 27 14:36:01 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Mar 2015 13:36:01 +0000
Subject: [issue23715] PEP 475: handle EINTR in the signal module
In-Reply-To: <1426814009.06.0.724045685729.issue23715@psf.upfronthosting.co.za>
Message-ID: <20150327133514.16170.51672@psf.io>


Roundup Robot added the comment:

New changeset 35bc15fa4930 by Victor Stinner in branch 'default':
Issue #23715: Fix test_sigtimedwait() of test_eintr
https://hg.python.org/cpython/rev/35bc15fa4930

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23715>
_______________________________________

From report at bugs.python.org  Fri Mar 27 15:21:18 2015
From: report at bugs.python.org (Paul Moore)
Date: Fri, 27 Mar 2015 14:21:18 +0000
Subject: [issue23789] decimal.Decimal: __format__ behaviour
In-Reply-To: <1427461273.99.0.604875598845.issue23789@psf.upfronthosting.co.za>
Message-ID: <1427466078.87.0.854075497528.issue23789@psf.upfronthosting.co.za>


Paul Moore added the comment:

I believe it's the way it is because Python follows the Standard Decimal Specification, which includes tests for conformance to the current formatting behaviour.

----------
nosy: +paul.moore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23789>
_______________________________________

From report at bugs.python.org  Fri Mar 27 15:44:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Mar 2015 14:44:55 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <20150327144452.24246.37799@psf.io>


Roundup Robot added the comment:

New changeset b0b4c4d365b1 by Victor Stinner in branch 'default':
Issue #22117: Fix test_gdb for the new time.sleep()
https://hg.python.org/cpython/rev/b0b4c4d365b1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Fri Mar 27 15:44:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Mar 2015 14:44:55 +0000
Subject: [issue23445] Use -Og for debug builds
In-Reply-To: <1423672122.39.0.391181135666.issue23445@psf.upfronthosting.co.za>
Message-ID: <20150327144452.24246.12246@psf.io>


Roundup Robot added the comment:

New changeset c663dbb84c8c by Victor Stinner in branch '3.4':
Issue #23445: Fix test.support.python_is_optimized() for CFLAGS=-Og
https://hg.python.org/cpython/rev/c663dbb84c8c

New changeset 5b5a22b9327b by Victor Stinner in branch '2.7':
Issue #23445: Fix test_gdb.python_is_optimized() for CFLAGS=-Og
https://hg.python.org/cpython/rev/5b5a22b9327b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23445>
_______________________________________

From report at bugs.python.org  Fri Mar 27 15:48:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 Mar 2015 14:48:51 +0000
Subject: [issue23445] Use -Og for debug builds
In-Reply-To: <1423672122.39.0.391181135666.issue23445@psf.upfronthosting.co.za>
Message-ID: <1427467731.61.0.786678810667.issue23445@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Done. It shouldn't break anything.

You're change skipped some test_gdb tests. I fixed the check in test_gdb/test.support.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23445>
_______________________________________

From report at bugs.python.org  Fri Mar 27 15:53:25 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Mar 2015 14:53:25 +0000
Subject: [issue23787] sum() function docstring lists arguments incorrectly
In-Reply-To: <1427455446.97.0.658394608092.issue23787@psf.upfronthosting.co.za>
Message-ID: <1427468005.39.0.347624565078.issue23787@psf.upfronthosting.co.za>


R. David Murray added the comment:

In python3 the docstring does say iterable.  It wouldn't be a bad thing to change it in 2.7, but it is not much of a priority.  iterable vs sequence makes no difference to the str question: a string is an iterable.  The docstring explicitly says strings are excepted, as you mentioned, so there's nothing to do about that.

I note that python3 also does not support iterables of byte-like objects.  I'm not sure if this would actually be helpful to add to the docstring, though, since sum(b'abc') works and a docstring is probably not an appropriate place to go into detail as to why.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23787>
_______________________________________

From report at bugs.python.org  Fri Mar 27 16:00:38 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Mar 2015 15:00:38 +0000
Subject: [issue23789] decimal.Decimal: __format__ behaviour
In-Reply-To: <1427461273.99.0.604875598845.issue23789@psf.upfronthosting.co.za>
Message-ID: <1427468438.94.0.597248808359.issue23789@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23789>
_______________________________________

From report at bugs.python.org  Fri Mar 27 16:01:45 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Mar 2015 15:01:45 +0000
Subject: [issue23788] test_urllib2_localnet.test_bad_address fails: OSError
 not raised by urlopen
In-Reply-To: <1427458701.93.0.881295834482.issue23788@psf.upfronthosting.co.za>
Message-ID: <1427468505.82.0.583185444025.issue23788@psf.upfronthosting.co.za>


R. David Murray added the comment:

How did you determine it was that commit?  It's a doc update, so it can't be affecting the code.  The test passes for me, on linux.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23788>
_______________________________________

From report at bugs.python.org  Fri Mar 27 16:06:13 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Mar 2015 15:06:13 +0000
Subject: [issue23790] When xdrlib.Packer().pack_string() fails,
 the Packer is corrupted
In-Reply-To: <1427461510.09.0.808726067558.issue23790@psf.upfronthosting.co.za>
Message-ID: <1427468773.41.0.9880716719.issue23790@psf.upfronthosting.co.za>


R. David Murray added the comment:

Your patches are great, thanks.  Now we have to decide which to use :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23790>
_______________________________________

From report at bugs.python.org  Fri Mar 27 16:12:56 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 Mar 2015 15:12:56 +0000
Subject: [issue23788] test_urllib2_localnet.test_bad_address fails: OSError
 not raised by urlopen
In-Reply-To: <1427458701.93.0.881295834482.issue23788@psf.upfronthosting.co.za>
Message-ID: <1427469176.97.0.86575156781.issue23788@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Can you try simply:

   socket.create_connection(("sadflkjsasf.i.nvali.d.", 80))

Here is raise: socket.gaierror: [Errno -2] Name or service not known

And what are your DNS servers?

   cat /etc/resolv.conf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23788>
_______________________________________

From report at bugs.python.org  Fri Mar 27 16:58:34 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 Mar 2015 15:58:34 +0000
Subject: [issue23671] string.Template doesn't work with the self keyword
 argument
In-Reply-To: <1426407694.34.0.298286807857.issue23671@psf.upfronthosting.co.za>
Message-ID: <1427471914.04.0.977396644136.issue23671@psf.upfronthosting.co.za>


?ric Araujo added the comment:

"descriptor 'substitute' of 'Template' object needs an argument"

These error messages don?t seem very user-friendly.  I think the style in the rest of the module is like "substitute method wants x y z".

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23671>
_______________________________________

From report at bugs.python.org  Fri Mar 27 17:02:47 2015
From: report at bugs.python.org (Valentine Sinitsyn)
Date: Fri, 27 Mar 2015 16:02:47 +0000
Subject: [issue23787] sum() function docstring lists arguments incorrectly
In-Reply-To: <1427455446.97.0.658394608092.issue23787@psf.upfronthosting.co.za>
Message-ID: <1427472167.1.0.13664600274.issue23787@psf.upfronthosting.co.za>


Valentine Sinitsyn added the comment:

Yes, strings aren't an issue. I only used them as an example.

I came across this issue during code review, discussing if it is okay to pass generator expression to sum() (like sum(x*2 for x in xrange(5)) or is it better to convert it to the list first (sum([x*2 for x in xrange(5)])). Both variants work so docstring is sort of specification here.

Surely, it's not a high priority task anyways.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23787>
_______________________________________

From report at bugs.python.org  Fri Mar 27 17:13:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Mar 2015 16:13:15 +0000
Subject: [issue23671] string.Template doesn't work with the self keyword
 argument
In-Reply-To: <1426407694.34.0.298286807857.issue23671@psf.upfronthosting.co.za>
Message-ID: <1427472795.23.0.691188620104.issue23671@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It matches error messages generated by builtin unbound methods.

>>> str.format()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: descriptor 'format' of 'str' object needs an argument

It would be incorrect to say "substitute method wants x y z", because the substitute method doesn't need any arguments.

>>> string.Template('spam').substitute()
'spam'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23671>
_______________________________________

From report at bugs.python.org  Fri Mar 27 17:13:27 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Mar 2015 16:13:27 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <20150327161317.74138.35290@psf.io>


Roundup Robot added the comment:

New changeset 0378c10ba164 by Victor Stinner in branch 'default':
Issue #22117: Fix rounding in _PyTime_FromSecondsObject()
https://hg.python.org/cpython/rev/0378c10ba164

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Fri Mar 27 17:25:20 2015
From: report at bugs.python.org (Brian)
Date: Fri, 27 Mar 2015 16:25:20 +0000
Subject: [issue23791] Identify Moved Lines with difflib
Message-ID: <1427473520.44.0.514545586028.issue23791@psf.upfronthosting.co.za>


New submission from Brian:

It would be a helpful feature to incorporate logic into the difflib module to optionally identify and ignore identical, but relocated lines when doing a diff. This would be used when the order of lines in a document is not critical, but rather just the overall content. The Notepad++ Compare plug-in has this feature for reference. 

I would be willing to help submit a patch for this change. The only drawbacks I see using this function is it will either have to increase processing time or increase memory usage.

----------
components: Library (Lib)
messages: 239416
nosy: bkiefer
priority: normal
severity: normal
status: open
title: Identify Moved Lines with difflib
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23791>
_______________________________________

From report at bugs.python.org  Fri Mar 27 18:09:23 2015
From: report at bugs.python.org (Rusi)
Date: Fri, 27 Mar 2015 17:09:23 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
Message-ID: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>


New submission from Rusi:

Start python3.4
Do help(something) which invokes the pager
Ctrl-C
A backtrace results and after that the terminal is in raw mode even after exiting python

[python 3.4 under debian testing with xfce4]

----------
components: IDLE
messages: 239417
nosy: RusiMody
priority: normal
severity: normal
status: open
title: help crash leaves terminal in raw mode
type: crash
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Fri Mar 27 18:14:14 2015
From: report at bugs.python.org (Oskar Hahn)
Date: Fri, 27 Mar 2015 17:14:14 +0000
Subject: [issue23790] When xdrlib.Packer().pack_string() fails,
 the Packer is corrupted
In-Reply-To: <1427461510.09.0.808726067558.issue23790@psf.upfronthosting.co.za>
Message-ID: <1427476454.52.0.424760237314.issue23790@psf.upfronthosting.co.za>


Oskar Hahn added the comment:

I would prefer the reset_buffer.patch because I do not like argument testing at the begin of a function/method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23790>
_______________________________________

From report at bugs.python.org  Fri Mar 27 18:33:58 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 Mar 2015 17:33:58 +0000
Subject: [issue23793] Support __add__ for deques.
Message-ID: <1427477638.63.0.2394294758.issue23793@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

One more step towards making the deque API a little closer to that for lists:
  
    >>> deque('abc') + deque('def')
    deque(['a', 'b', 'c', 'd', 'e', 'f'])

----------
assignee: rhettinger
components: Extension Modules
files: deque_add4.diff
keywords: patch
messages: 239419
nosy: rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Support __add__ for deques.
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38712/deque_add4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23793>
_______________________________________

From report at bugs.python.org  Fri Mar 27 18:37:17 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Mar 2015 17:37:17 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <1427477837.35.0.269545098453.issue23792@psf.upfronthosting.co.za>


R. David Murray added the comment:

I can't reproduce this.  Maybe it is a debian bug?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Fri Mar 27 18:43:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 Mar 2015 17:43:09 +0000
Subject: [issue23790] When xdrlib.Packer().pack_string() fails,
 the Packer is corrupted
In-Reply-To: <1427461510.09.0.808726067558.issue23790@psf.upfronthosting.co.za>
Message-ID: <1427478189.53.0.360721851653.issue23790@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I doubt that this issue is worth fixing. It is common that when error is happen inside complex operation, the output can be incomplete. When you pickle a list containing non-pickleable data, resulting file content will be not unpickleable. When you write a number of lines in text file, and one of lines contains non-encodable characters, resulting file content will be incomplete and may even don't contain complete lines.

And when other xdrlib.Packer methods that write complex data (pack_uhyper, pack_list, pack_farray, pack_array) fail, they left incomplete output.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23790>
_______________________________________

From report at bugs.python.org  Fri Mar 27 18:50:14 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 27 Mar 2015 17:50:14 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <1427478614.91.0.102121858133.issue23792@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This looks like a duplicate of issue 21398. I can reproduce it with Python 3.4.1 (compiled myself) on Ubuntu 12.04.

>>> help(str)

Ctrl-C

:Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.4/_sitebuiltins.py", line 103, in __call__
    return pydoc.help(*args, **kwds)
  File "/usr/local/lib/python3.4/pydoc.py", line 1817, in __call__
    self.help(request)
  File "/usr/local/lib/python3.4/pydoc.py", line 1867, in help
    else: doc(request, 'Help on %s:', output=self._output)
  File "/usr/local/lib/python3.4/pydoc.py", line 1603, in doc
    pager(render_doc(thing, title, forceload))
  File "/usr/local/lib/python3.4/pydoc.py", line 1411, in pager
    pager(text)
  File "/usr/local/lib/python3.4/pydoc.py", line 1431, in <lambda>
    return lambda text: pipepager(text, 'less')
  File "/usr/local/lib/python3.4/pydoc.py", line 1453, in pipepager
    pipe.close()
  File "/usr/local/lib/python3.4/os.py", line 957, in close
    returncode = self._proc.wait()
  File "/usr/local/lib/python3.4/subprocess.py", line 1565, in wait
    (pid, sts) = self._try_wait(0)
  File "/usr/local/lib/python3.4/subprocess.py", line 1513, in _try_wait
    (pid, sts) = _eintr_retry_call(os.waitpid, self.pid, wait_flags)
  File "/usr/local/lib/python3.4/subprocess.py", line 491, in _eintr_retry_call
    return func(*args)
KeyboardInterrupt

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Fri Mar 27 18:50:51 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 27 Mar 2015 17:50:51 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <1427478651.62.0.419449340661.issue23792@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I can reproduce on Python 3 on Ubuntu 14.10.
When I hit Ctrl+C I get:
>>> help(range)
...
 |  __hash__(self, /)
 |      Return hash(self).
 |  
:Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/wolf/dev/py/py3k/Lib/_sitebuiltins.py", line 103, in __call__
    return pydoc.help(*args, **kwds)
  File "/home/wolf/dev/py/py3k/Lib/pydoc.py", line 1833, in __call__
    self.help(request)
  File "/home/wolf/dev/py/py3k/Lib/pydoc.py", line 1886, in help
    else: doc(request, 'Help on %s:', output=self._output)
  File "/home/wolf/dev/py/py3k/Lib/pydoc.py", line 1619, in doc
    pager(render_doc(thing, title, forceload))
  File "/home/wolf/dev/py/py3k/Lib/pydoc.py", line 1409, in pager
    pager(text)
  File "/home/wolf/dev/py/py3k/Lib/pydoc.py", line 1431, in <lambda>
    return lambda text: pipepager(text, 'less')
  File "/home/wolf/dev/py/py3k/Lib/pydoc.py", line 1455, in pipepager
    pipe.write(text)
  File "/home/wolf/dev/py/py3k/Lib/subprocess.py", line 900, in __exit__
    self.wait()
  File "/home/wolf/dev/py/py3k/Lib/subprocess.py", line 1552, in wait
    (pid, sts) = self._try_wait(0)
  File "/home/wolf/dev/py/py3k/Lib/subprocess.py", line 1502, in _try_wait
    (pid, sts) = os.waitpid(self.pid, wait_flags)
KeyboardInterrupt
>>>

If I keep pressing Enter the rest of the help gets printed.  Once the pager is done, pressing enter doesn't go on a new line and the prompts (>>>) are printed one after the other on the same line.  The same happens on my shell prompt once I exit from the interpreter. `reset` fixes it.

On Python 2 Ctrl+C does nothing.

----------
nosy: +ezio.melotti
type: crash -> behavior
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Fri Mar 27 18:58:30 2015
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 27 Mar 2015 17:58:30 +0000
Subject: [issue23794] http package should support HTTP/2
Message-ID: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

The spec is available at https://http2.github.io/

----------
components: Library (Lib)
messages: 239424
nosy: alex
priority: normal
severity: normal
status: open
title: http package should support HTTP/2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23794>
_______________________________________

From report at bugs.python.org  Fri Mar 27 19:01:27 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 27 Mar 2015 18:01:27 +0000
Subject: [issue23794] http package should support HTTP/2
In-Reply-To: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za>
Message-ID: <1427479287.27.0.971193675886.issue23794@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23794>
_______________________________________

From report at bugs.python.org  Fri Mar 27 19:02:33 2015
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Ferreira?=)
Date: Fri, 27 Mar 2015 18:02:33 +0000
Subject: [issue23795] argparse -- incorrect usage for mutually exclusive
Message-ID: <1427479353.63.0.760069319945.issue23795@psf.upfronthosting.co.za>


New submission from Jo?o Ferreira:

The usage that is printed by argparse with the "--help" argument is slightly incorrect when using mutually exclusive groups. This happens in version 3.4.3 but did not happen in version 3.4.0.

I have this minimal example:

import argparse

p = argparse.ArgumentParser()

g1 = p.add_mutually_exclusive_group(required=False)
g1.add_argument("-a")
g1.add_argument("-b")

g2 = p.add_mutually_exclusive_group(required=False)
g2.add_argument("-c")
g2.add_argument("-d")

p.parse_args()

In python 3.4.0, "python test.py --help" produces the usage:

usage: test.py [-h] [-a A | -b B] [-c C | -d D]

In python 3.4.3, the usage is:

usage: test.py [-h] [-a A | -b B [-c C | -d D]

Note the absence of the closing square bracket after B.

----------
components: Library (Lib)
messages: 239425
nosy: jotomicron
priority: normal
severity: normal
status: open
title: argparse -- incorrect usage for mutually exclusive
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23795>
_______________________________________

From report at bugs.python.org  Fri Mar 27 19:14:57 2015
From: report at bugs.python.org (Ian Cordasco)
Date: Fri, 27 Mar 2015 18:14:57 +0000
Subject: [issue23794] http package should support HTTP/2
In-Reply-To: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za>
Message-ID: <1427480097.46.0.568575940503.issue23794@psf.upfronthosting.co.za>


Changes by Ian Cordasco <graffatcolmingov at gmail.com>:


----------
nosy: +icordasc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23794>
_______________________________________

From report at bugs.python.org  Fri Mar 27 19:25:04 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Mar 2015 18:25:04 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <1427480704.92.0.516068499241.issue23792@psf.upfronthosting.co.za>


R. David Murray added the comment:

I do see the anomalous behavior inside python, but on my gentoo system when I exit python the terminal is fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Fri Mar 27 19:33:58 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 Mar 2015 18:33:58 +0000
Subject: [issue23793] Support __add__ for deques.
In-Reply-To: <1427477638.63.0.2394294758.issue23793@psf.upfronthosting.co.za>
Message-ID: <1427481238.75.0.766260599802.issue23793@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file38713/deque_add5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23793>
_______________________________________

From report at bugs.python.org  Fri Mar 27 20:08:52 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Mar 2015 19:08:52 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <1427483332.39.0.815864720698.issue23792@psf.upfronthosting.co.za>


R. David Murray added the comment:

The attached patch fixes the issue for me.

----------
keywords: +patch
Added file: http://bugs.python.org/file38714/keyboardinterrupt_in_pydoc_pager.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Fri Mar 27 20:11:23 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 27 Mar 2015 19:11:23 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <1427483483.45.0.64737767504.issue23792@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Patch WFM too.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Fri Mar 27 20:19:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Mar 2015 19:19:55 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <1427483995.35.0.886428344668.issue23792@psf.upfronthosting.co.za>


R. David Murray added the comment:

The print of KeyboardInterrupt whould be dropped.  less itself does nothing if you press ctl-c, and the pager is used when pydoc is called from the shell command line, and printing KeyboardInterrupt there just looks wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Fri Mar 27 20:34:09 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 27 Mar 2015 19:34:09 +0000
Subject: [issue23789] decimal.Decimal: __format__ behaviour
In-Reply-To: <1427461273.99.0.604875598845.issue23789@psf.upfronthosting.co.za>
Message-ID: <1427484849.54.0.564175490943.issue23789@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> I believe it's the way it is because Python follows the Standard Decimal Specification

Yes, exactly.  This is behaving as designed and as tested.

----------
nosy: +mark.dickinson
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23789>
_______________________________________

From report at bugs.python.org  Fri Mar 27 20:35:03 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Mar 2015 19:35:03 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <1427484903.94.0.476656133771.issue23792@psf.upfronthosting.co.za>


R. David Murray added the comment:

Updated patch.

----------
Added file: http://bugs.python.org/file38715/keyboardinterrupt_in_pydoc_pager.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Fri Mar 27 20:35:14 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Mar 2015 19:35:14 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <1427484914.86.0.469595889269.issue23792@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Fri Mar 27 20:36:03 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 Mar 2015 19:36:03 +0000
Subject: [issue23787] sum() function docstring lists arguments incorrectly
In-Reply-To: <1427455446.97.0.658394608092.issue23787@psf.upfronthosting.co.za>
Message-ID: <1427484963.94.0.0221265585605.issue23787@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file38716/sum_doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23787>
_______________________________________

From report at bugs.python.org  Fri Mar 27 21:06:52 2015
From: report at bugs.python.org (paul j3)
Date: Fri, 27 Mar 2015 20:06:52 +0000
Subject: [issue23795] argparse -- incorrect usage for mutually exclusive
In-Reply-To: <1427479353.63.0.760069319945.issue23795@psf.upfronthosting.co.za>
Message-ID: <1427486812.44.0.74150911243.issue23795@psf.upfronthosting.co.za>


paul j3 added the comment:

I can't reproduce this with either 3.4.2 or the latest development 'argparse.py' file (that I just downloaded).

There have been some issues with the method used format the usage line, _format_actions_usage.  It formats the line with all the group brackets, and then tries to filter out the unnecessary ones.  As such it is fragile, and messed up by extra characters.

But I'm not aware of a relevant patch being applied and then latter removed.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23795>
_______________________________________

From report at bugs.python.org  Fri Mar 27 21:18:29 2015
From: report at bugs.python.org (paul j3)
Date: Fri, 27 Mar 2015 20:18:29 +0000
Subject: [issue23058] argparse silently ignores arguments
In-Reply-To: <1418677327.73.0.355612765077.issue23058@psf.upfronthosting.co.za>
Message-ID: <1427487509.31.0.404520608212.issue23058@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23058>
_______________________________________

From report at bugs.python.org  Fri Mar 27 21:36:04 2015
From: report at bugs.python.org (paul j3)
Date: Fri, 27 Mar 2015 20:36:04 +0000
Subject: [issue23058] argparse silently ignores arguments
In-Reply-To: <1418677327.73.0.355612765077.issue23058@psf.upfronthosting.co.za>
Message-ID: <1427488564.02.0.887334150381.issue23058@psf.upfronthosting.co.za>


paul j3 added the comment:

Without actually running this case I think it is caused by the  http://bugs.python.org/issue9351  patch.

You can check the __call__ method for class _SubParsersAction and how it handles invocation of the subparser.  Does it get the existing namespace, or a new one (None)?

There is an inherent ambiguity when the same argument ('dest' actually) is defined for both the parser and the subparser.  Doubly so when both get it via 'parents'.  Which default and which argument string has priority?

That other issue tried to fix the case where the subparser's default was being ignored, and in the process created a case where the parser's argument string is being ignored.

Wouldn't it be safer all around if the subparsers took different arguments, or at least different namespace 'dest', than the main parser?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23058>
_______________________________________

From report at bugs.python.org  Fri Mar 27 21:38:31 2015
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Rampin?=)
Date: Fri, 27 Mar 2015 20:38:31 +0000
Subject: [issue9351] argparse set_defaults on subcommands should override top
 level set_defaults
In-Reply-To: <1279894012.43.0.0678646409.issue9351@psf.upfronthosting.co.za>
Message-ID: <1427488711.28.0.0546882206242.issue9351@psf.upfronthosting.co.za>


Changes by R?mi Rampin <remirampin at gmail.com>:


----------
nosy: +remram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9351>
_______________________________________

From report at bugs.python.org  Fri Mar 27 21:42:41 2015
From: report at bugs.python.org (paul j3)
Date: Fri, 27 Mar 2015 20:42:41 +0000
Subject: [issue23555] behavioural change in argparse set_defaults in python
 2.7.9
In-Reply-To: <1425209556.02.0.589190597278.issue23555@psf.upfronthosting.co.za>
Message-ID: <1427488961.33.0.286457728431.issue23555@psf.upfronthosting.co.za>


paul j3 added the comment:

This is another manifestation of the
http://bugs.python.org/issue9351 partial patch  (on how the namespace of the parser relates to the namespace of the subparser).

see also
http://bugs.python.org/issue23058

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23555>
_______________________________________

From report at bugs.python.org  Fri Mar 27 21:43:08 2015
From: report at bugs.python.org (paul j3)
Date: Fri, 27 Mar 2015 20:43:08 +0000
Subject: [issue23555] behavioural change in argparse set_defaults in python
 2.7.9
In-Reply-To: <1425209556.02.0.589190597278.issue23555@psf.upfronthosting.co.za>
Message-ID: <1427488988.3.0.0172562265612.issue23555@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23555>
_______________________________________

From report at bugs.python.org  Fri Mar 27 21:51:18 2015
From: report at bugs.python.org (paul j3)
Date: Fri, 27 Mar 2015 20:51:18 +0000
Subject: [issue9334] argparse does not accept options taking arguments
 beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1427489478.62.0.0833941051818.issue9334@psf.upfronthosting.co.za>


paul j3 added the comment:

http://bugs.python.org/issue22672
float arguments in scientific notation not supported by argparse

is a newer complaint about the same issue.  I've closed it with link to here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9334>
_______________________________________

From report at bugs.python.org  Fri Mar 27 21:52:03 2015
From: report at bugs.python.org (paul j3)
Date: Fri, 27 Mar 2015 20:52:03 +0000
Subject: [issue22672] float arguments in scientific notation not supported by
 argparse
In-Reply-To: <1413742215.74.0.884028294997.issue22672@psf.upfronthosting.co.za>
Message-ID: <1427489523.85.0.826627998902.issue22672@psf.upfronthosting.co.za>


paul j3 added the comment:

closed with reference to #9334

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22672>
_______________________________________

From report at bugs.python.org  Fri Mar 27 21:54:26 2015
From: report at bugs.python.org (paul j3)
Date: Fri, 27 Mar 2015 20:54:26 +0000
Subject: [issue22500] Argparse always stores True for positional arguments
In-Reply-To: <1411697591.54.0.644462520859.issue22500@psf.upfronthosting.co.za>
Message-ID: <1427489666.73.0.564990145858.issue22500@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22500>
_______________________________________

From report at bugs.python.org  Fri Mar 27 22:10:13 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Mar 2015 21:10:13 +0000
Subject: [issue22672] float arguments in scientific notation not supported by
 argparse
In-Reply-To: <1413742215.74.0.884028294997.issue22672@psf.upfronthosting.co.za>
Message-ID: <1427490613.93.0.3158472533.issue22672@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> duplicate
stage: patch review -> resolved
superseder:  -> argparse does not accept options taking arguments beginning with dash (regression from optparse)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22672>
_______________________________________

From report at bugs.python.org  Fri Mar 27 22:23:16 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Mar 2015 21:23:16 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
In-Reply-To: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>
Message-ID: <1427491396.71.0.329608440399.issue23720@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

While this is not a bug, Antoine said he might look at improving the situation, so I leave it to him to close it or not.

----------
nosy: +terry.reedy
stage:  -> needs patch
type: behavior -> performance
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Fri Mar 27 22:25:32 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Mar 2015 21:25:32 +0000
Subject: [issue23760] Tkinter in Python 3.4 on Windows don't post internal
 clipboard data to the Windows clipboard on exit
In-Reply-To: <1427194076.59.0.225721138053.issue23760@psf.upfronthosting.co.za>
Message-ID: <1427491532.09.0.665640142698.issue23760@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +serhiy.storchaka, terry.reedy
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23760>
_______________________________________

From report at bugs.python.org  Fri Mar 27 22:28:39 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Mar 2015 21:28:39 +0000
Subject: [issue23762] python.org page on new-style classes should be updated
In-Reply-To: <1427207285.84.0.436806674049.issue23762@psf.upfronthosting.co.za>
Message-ID: <1427491719.16.0.629687113983.issue23762@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

"Unfortunately, new-style classes have not yet been integrated into Python's standard documention" is not even true for 2.7.  I think the page should be deleted.  Any of the reverences that are both useful and not in the docs could be added to the docs.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23762>
_______________________________________

From report at bugs.python.org  Fri Mar 27 22:30:28 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Mar 2015 21:30:28 +0000
Subject: [issue23762] python.org page on new-style classes should be updated
In-Reply-To: <1427207285.84.0.436806674049.issue23762@psf.upfronthosting.co.za>
Message-ID: <1427491828.62.0.227154075295.issue23762@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This tracker can only handle changes to the docs.  Deleting a web page would be an issue for the python.org tracker on github.  But we should not make a request there until the docs have been checked and we are sure it should go.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23762>
_______________________________________

From report at bugs.python.org  Fri Mar 27 22:34:21 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Mar 2015 21:34:21 +0000
Subject: [issue23791] Identify Moved Lines with difflib
In-Reply-To: <1427473520.44.0.514545586028.issue23791@psf.upfronthosting.co.za>
Message-ID: <1427492061.77.0.79914781715.issue23791@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> test needed
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23791>
_______________________________________

From report at bugs.python.org  Fri Mar 27 22:39:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Mar 2015 21:39:18 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <20150327213913.16154.42511@psf.io>


Roundup Robot added the comment:

New changeset 45d9093d259d by Victor Stinner in branch 'default':
Issue #22117: time.monotonic() now uses the new _PyTime_t API
https://hg.python.org/cpython/rev/45d9093d259d

New changeset a88735cbeb50 by Victor Stinner in branch 'default':
Issue #22117: time.time() now uses the new _PyTime_t API
https://hg.python.org/cpython/rev/a88735cbeb50

New changeset abf38a17d3a8 by Victor Stinner in branch 'default':
Issue #22117: The gc module now uses _PyTime_t timestamp
https://hg.python.org/cpython/rev/abf38a17d3a8

New changeset a3c5e05d2cef by Victor Stinner in branch 'default':
Issue #22117: The signal modules uses the new _PyTime_t API
https://hg.python.org/cpython/rev/a3c5e05d2cef

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Fri Mar 27 22:48:40 2015
From: report at bugs.python.org (Hammerite)
Date: Fri, 27 Mar 2015 21:48:40 +0000
Subject: [issue23550] Add to unicodedata a function to query the "Quick_Check"
 property for a character
In-Reply-To: <1425147670.05.0.762030398058.issue23550@psf.upfronthosting.co.za>
Message-ID: <1427492920.24.0.0694644922492.issue23550@psf.upfronthosting.co.za>


Hammerite added the comment:

My remark about the arrays not being static is not entirely accurate. _PyUnicode_CategoryNames, _PyUnicode_BidirectionalNames and _PyUnicode_EastAsianWidthNames are not static, however decomp_prefix is static. It would not add any significant bulk to the patch to make these three static in addition to the new array, but I will await another review before submitting a further patch, since I anticipate there will be a need for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23550>
_______________________________________

From report at bugs.python.org  Fri Mar 27 23:33:17 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 27 Mar 2015 22:33:17 +0000
Subject: [issue23762] python.org page on new-style classes should be updated
In-Reply-To: <1427207285.84.0.436806674049.issue23762@psf.upfronthosting.co.za>
Message-ID: <1427495597.09.0.29130286319.issue23762@psf.upfronthosting.co.za>


Berker Peksag added the comment:

IMHO, it can stay as a historical document. We just need to add a note to point out the correct documentation. So I think this can be handled on GitHub. I can't update the content since I don't have edit rights, so please open a new issue at https://github.com/python/pythondotorg/issues

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23762>
_______________________________________

From report at bugs.python.org  Fri Mar 27 23:44:11 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 Mar 2015 22:44:11 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
In-Reply-To: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>
Message-ID: <1427496251.36.0.306559865029.issue23720@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> pitrou
priority: normal -> low
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Sat Mar 28 01:29:19 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Mar 2015 00:29:19 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <20150328002916.55370.93746@psf.io>


Roundup Robot added the comment:

New changeset f841d3bc30ee by Victor Stinner in branch 'default':
Issue #23618, #22117: refactor socketmodule.c
https://hg.python.org/cpython/rev/f841d3bc30ee

New changeset ae551abe398d by Victor Stinner in branch 'default':
Issue #22117: Write unit tests for _PyTime_AsTimeval()
https://hg.python.org/cpython/rev/ae551abe398d

New changeset c0c7d258c1ed by Victor Stinner in branch 'default':
Issue #22117: The socket module uses _PyTime_t timestamp for timeouts
https://hg.python.org/cpython/rev/c0c7d258c1ed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Sat Mar 28 01:29:19 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Mar 2015 00:29:19 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <20150328002916.55370.30904@psf.io>


Roundup Robot added the comment:

New changeset f841d3bc30ee by Victor Stinner in branch 'default':
Issue #23618, #22117: refactor socketmodule.c
https://hg.python.org/cpython/rev/f841d3bc30ee

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Sat Mar 28 01:29:50 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 Mar 2015 00:29:50 +0000
Subject: [issue23796] BufferedReader.peek() crashes if closed
Message-ID: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za>


New submission from Martin Panter:

If the BufferedReader object has already been closed, calling peek() can cause a strange error message or a crash:

$ python3 -bWall
Python 3.4.2 (default, Oct  8 2014, 14:33:30) 
[GCC 4.9.1 20140903 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from io import *
>>> b = BufferedReader(BytesIO())
>>> b.close()
>>> b.peek()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: PyMemoryView_FromBuffer(): info->buf must not be NULL
>>> b = BufferedReader(BytesIO(b"12"))
>>> b.read(1)
b'1'
>>> b.close()
>>> b.peek()
Segmentation fault (core dumped)
[Exit 139]

I?m not able to check with 3.5 at the moment, but looking at the code, I suspect this also applies to 3.5 and there needs to be a CHECK_CLOSED() call added somewhere around Modules/_io/bufferedio.c:884.

----------
components: IO
messages: 239445
nosy: vadmium
priority: normal
severity: normal
status: open
title: BufferedReader.peek() crashes if closed
type: crash
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23796>
_______________________________________

From report at bugs.python.org  Sat Mar 28 01:44:33 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 Mar 2015 00:44:33 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <1427503473.61.0.0308073034942.issue23792@psf.upfronthosting.co.za>


Martin Panter added the comment:

I suspect you also need ignore signals while piping data to the child process. Similar to how the POSIX system() call ignores SIGINT and SIGQUIT soon after spawning the child, until after the child has exited.

Try with a large help text on Linux, like

import _pyio
help(_pyio)

Also, Python 2 still gets interrupted for me, it is just that it doesn?t seem to happen immediately if it is up to the pipe.close() call.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Sat Mar 28 02:16:19 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 Mar 2015 01:16:19 +0000
Subject: [issue23794] http package should support HTTP/2
In-Reply-To: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za>
Message-ID: <1427505379.41.0.353863641138.issue23794@psf.upfronthosting.co.za>


Martin Panter added the comment:

This project may be of use for the client side of things: <https://github.com/lukasa/hyper> (apparently MIT licensed).

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23794>
_______________________________________

From report at bugs.python.org  Sat Mar 28 02:21:09 2015
From: report at bugs.python.org (Ian Cordasco)
Date: Sat, 28 Mar 2015 01:21:09 +0000
Subject: [issue23794] http package should support HTTP/2
In-Reply-To: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za>
Message-ID: <1427505669.31.0.369268879313.issue23794@psf.upfronthosting.co.za>


Changes by Ian Cordasco <graffatcolmingov at gmail.com>:


----------
nosy: +Lukasa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23794>
_______________________________________

From report at bugs.python.org  Sat Mar 28 03:01:01 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Mar 2015 02:01:01 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <20150328020057.122181.44098@psf.io>


Roundup Robot added the comment:

New changeset 7605d9d262ca by Victor Stinner in branch 'default':
Issue #22117: remove _PyTime_INTERVAL() macro
https://hg.python.org/cpython/rev/7605d9d262ca

New changeset d1ef5ff79125 by Victor Stinner in branch 'default':
Issue #22117: Fix ssl to use _PyTime_t API on sock_timeout
https://hg.python.org/cpython/rev/d1ef5ff79125

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Sat Mar 28 03:22:18 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 Mar 2015 02:22:18 +0000
Subject: [issue23529] Limit decompressed data when reading from LZMAFile and
 BZ2File
In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za>
Message-ID: <1427509338.57.0.451131925915.issue23529@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes my patch should be ready, unless we want to work on factoring more common logic out of the gzip read() method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23529>
_______________________________________

From report at bugs.python.org  Sat Mar 28 03:37:59 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 Mar 2015 02:37:59 +0000
Subject: [issue23796] BufferedReader.peek() crashes if closed
In-Reply-To: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za>
Message-ID: <1427510279.39.0.929155393285.issue23796@psf.upfronthosting.co.za>


Martin Panter added the comment:

Confirmed it does indeed affect the current 3.5 (default) branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23796>
_______________________________________

From report at bugs.python.org  Sat Mar 28 03:58:57 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Mar 2015 02:58:57 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <20150328025854.26448.55133@psf.io>


Roundup Robot added the comment:

New changeset adbc9e6162fe by Victor Stinner in branch 'default':
Issue #22117: The thread module uses the new _PyTime_t timestamp API
https://hg.python.org/cpython/rev/adbc9e6162fe

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Sat Mar 28 04:21:56 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 28 Mar 2015 03:21:56 +0000
Subject: [issue17909] Autodetecting JSON encoding
In-Reply-To: <1367759430.76.0.988181674037.issue17909@psf.upfronthosting.co.za>
Message-ID: <1427512916.77.0.95864949203.issue17909@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17909>
_______________________________________

From report at bugs.python.org  Sat Mar 28 05:20:06 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Mar 2015 04:20:06 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <20150328042003.25933.14771@psf.io>


Roundup Robot added the comment:

New changeset 930be74bbae5 by Victor Stinner in branch 'default':
Issue #22117: Use the new _PyTime_t API in the select module
https://hg.python.org/cpython/rev/930be74bbae5

New changeset 5aa39b88bd55 by Victor Stinner in branch 'default':
Issue #22117: Use the _PyTime_t API for time.clock_settime()
https://hg.python.org/cpython/rev/5aa39b88bd55

New changeset 47123ac83733 by Victor Stinner in branch 'default':
Issue #22117: Add the new _PyTime_ROUND_FLOOR rounding method for the datetime
https://hg.python.org/cpython/rev/47123ac83733

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Sat Mar 28 05:27:08 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 Mar 2015 04:27:08 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <20150328042705.27944.53285@psf.io>


Roundup Robot added the comment:

New changeset 0850452048ec by Victor Stinner in branch 'default':
Issue #22117: Fix _PyTime_GetMonotonicClock() and
https://hg.python.org/cpython/rev/0850452048ec

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Sat Mar 28 05:59:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 Mar 2015 04:59:49 +0000
Subject: [issue23430] socketserver.BaseServer.handle_error() should not catch
 exiting exceptions
In-Reply-To: <1423539248.06.0.0190891390955.issue23430@psf.upfronthosting.co.za>
Message-ID: <1427518789.84.0.252707865001.issue23430@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch v3:

* Changed the structure of exception handling for the forking server so that there is only one os._exit(status) call site
* Rewrote tests to log results to a temporary file. This avoids sending a string of code to a Python subprocess. I use threading.Event and os.waitpid() to synchronize.
* Tests now call the handle_request() public API, and create a trivial TCP connection to trigger a request.
* Added doc string explaining simple_subprocess()

Let me know what you think.

----------
Added file: http://bugs.python.org/file38717/socketserver-exit.v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23430>
_______________________________________

From report at bugs.python.org  Sat Mar 28 06:04:26 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 Mar 2015 05:04:26 +0000
Subject: [issue23430] socketserver.BaseServer.handle_error() should not catch
 exiting exceptions
In-Reply-To: <1423539248.06.0.0190891390955.issue23430@psf.upfronthosting.co.za>
Message-ID: <1427519066.86.0.371234063069.issue23430@psf.upfronthosting.co.za>


Martin Panter added the comment:

Oops I forgot to refresh the patch. Patch v4 also closes the server in the tests.

----------
Added file: http://bugs.python.org/file38718/socketserver-exit.v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23430>
_______________________________________

From report at bugs.python.org  Sat Mar 28 07:38:13 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Mar 2015 06:38:13 +0000
Subject: [issue23796] BufferedReader.peek() crashes if closed
In-Reply-To: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za>
Message-ID: <1427524693.36.0.883686052461.issue23796@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Do you want provide a patch Martin?

----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23796>
_______________________________________

From report at bugs.python.org  Sat Mar 28 08:12:36 2015
From: report at bugs.python.org (Cory Benfield)
Date: Sat, 28 Mar 2015 07:12:36 +0000
Subject: [issue23794] http package should support HTTP/2
In-Reply-To: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za>
Message-ID: <1427526756.98.0.551033311731.issue23794@psf.upfronthosting.co.za>


Cory Benfield added the comment:

I'm happy to talk about bringing hyper's HTTP/2 layer into http.client. It's worth noting that at this point I have no current plans to build a server into hyper, though if there was interest in using hyper as a baseline then I could take a swing at it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23794>
_______________________________________

From report at bugs.python.org  Sat Mar 28 11:07:58 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Mar 2015 10:07:58 +0000
Subject: [issue23720] __del__() order is broken since 3.4.0
In-Reply-To: <1426856186.55.0.426766995956.issue23720@psf.upfronthosting.co.za>
Message-ID: <1427537278.13.0.852057288852.issue23720@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23720>
_______________________________________

From report at bugs.python.org  Sat Mar 28 11:47:55 2015
From: report at bugs.python.org (Barry Alan Scott)
Date: Sat, 28 Mar 2015 10:47:55 +0000
Subject: [issue23797] Mac OS X locale setup in thread happens sometime after
 run() is called
Message-ID: <1427539675.57.0.610869974475.issue23797@psf.upfronthosting.co.za>


New submission from Barry Alan Scott:

I'm seeing a random traceback when starting a new thread on Mac OS X 10.10.2 with python 3.4.3 final.

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threading.py", line 920, in _bootstrap_inner
    self.run()
  File "/Users/barry/wc/svn/pysvn-phoenix/WorkBench/Source/wb_background_thread.py", line 40, in run
    self.app.log.info( 'BackgroundThread locale %r' % (locale.getlocale(),) )
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/locale.py", line 575, in getlocale
    return _parse_localename(localename)
  File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/locale.py", line 484, in _parse_localename
    raise ValueError('unknown locale: %s' % localename)
ValueError: unknown locale: UTF-8

Adding a time.sleep( 5 ) prevents the traceback.

Using _locale.setlocale( locale.LC_ALL, None ) to see the state with locale.py interfering it looks like the locale is being initialised in the thread after run() is called. (Make no sense to me, but I can reproduce).

I have failed to create a small script to show this bug.

----------
messages: 239458
nosy: barry-scott
priority: normal
severity: normal
status: open
title: Mac OS X locale setup in thread happens sometime after run() is called
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23797>
_______________________________________

From report at bugs.python.org  Sat Mar 28 12:51:22 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Sat, 28 Mar 2015 11:51:22 +0000
Subject: [issue22672] float arguments in scientific notation not supported by
 argparse
In-Reply-To: <1413742215.74.0.884028294997.issue22672@psf.upfronthosting.co.za>
Message-ID: <1427543482.43.0.31382156146.issue22672@psf.upfronthosting.co.za>


Changes by Evgeny Kapun <abacabadabacaba at gmail.com>:


----------
nosy: +abacabadabacaba

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22672>
_______________________________________

From report at bugs.python.org  Sat Mar 28 13:34:26 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 28 Mar 2015 12:34:26 +0000
Subject: [issue23794] http package should support HTTP/2
In-Reply-To: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za>
Message-ID: <1427546066.83.0.543772955434.issue23794@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23794>
_______________________________________

From report at bugs.python.org  Sat Mar 28 15:41:42 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 28 Mar 2015 14:41:42 +0000
Subject: [issue17515] Add sys.setasthook() to allow to use a custom AST
 optimizer
In-Reply-To: <1363913891.37.0.731570464343.issue17515@psf.upfronthosting.co.za>
Message-ID: <1427553702.35.0.829183240598.issue17515@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The closing of this issue inspired me to think of a better way to do this, and I think providing something in importlib.util that accepted a NodeTransformer as an argument to a function that compiled source files to bytecode files would fill this issue thanks to PEP 488. It would mean that nothing is done dynamically and everything is done offline, but that also means startup costs are gone in regards to bytecode generation and it gets people to actually think about optimizations of Python instead of it just being an afterthought.

importlib.util.compile(path: Union[str, pathlib.Path], transformer: ast.NodeTransformer = None, *, optimization: Union[str, int] = None) -> pathlib.Path

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17515>
_______________________________________

From report at bugs.python.org  Sat Mar 28 17:59:52 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 28 Mar 2015 16:59:52 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <1427561992.6.0.933317894896.issue23792@psf.upfronthosting.co.za>


R. David Murray added the comment:

SIGINT *is* keyboard interrupt.  Since less at least seems to ignore SIGQUIT I suppose also ignoring that would be reasonable, since the user (should) by analogy expect that behavior while the pager is active.  Note, however, that the signals we are ignoring are in the parent process, not the child as is the case for system.  So one can argue that letting the python process die when SIGQUIT is received would also be reasonable, and arguably is the less surprising option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Sat Mar 28 18:10:28 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 28 Mar 2015 17:10:28 +0000
Subject: [issue23797] Mac OS X locale setup in thread happens sometime after
 run() is called
In-Reply-To: <1427539675.57.0.610869974475.issue23797@psf.upfronthosting.co.za>
Message-ID: <1427562628.36.0.364527457722.issue23797@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is probably related to or effectively a duplicate of issue 18378, which looks to be an Apple bug.

Do you have the problem if you remove the getlocale() call?

----------
components: +Macintosh
nosy: +ned.deily, r.david.murray, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23797>
_______________________________________

From report at bugs.python.org  Sat Mar 28 19:00:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Mar 2015 18:00:54 +0000
Subject: [issue23798] NameError in the encode fixer
Message-ID: <1427565654.6.0.111247541.issue23798@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

======================================================================
ERROR: test_all_project_files (lib2to3.tests.test_all_fixers.Test_all)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/lib2to3/tests/test_all_fixers.py", line 25, in test_all_project_files
    self.refactor.refactor_file(filepath)
  File "/home/serhiy/py/cpython/Lib/lib2to3/refactor.py", line 354, in refactor_file
    tree = self.refactor_string(input, filename)
  File "/home/serhiy/py/cpython/Lib/lib2to3/refactor.py", line 386, in refactor_string
    self.refactor_tree(tree, name)
  File "/home/serhiy/py/cpython/Lib/lib2to3/refactor.py", line 460, in refactor_tree
    new = fixer.transform(node, results)
  File "/home/serhiy/py/cpython/Lib/lib2to3/fixes/fix_encode.py", line 50, in transform
    if negation:
NameError: name 'negation' is not defined

----------------------------------------------------------------------

Variable 'negation' is never set.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 239462
nosy: benjamin.peterson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: NameError in the encode fixer
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23798>
_______________________________________

From report at bugs.python.org  Sat Mar 28 19:28:21 2015
From: report at bugs.python.org (Eric Snow)
Date: Sat, 28 Mar 2015 18:28:21 +0000
Subject: [issue23731] Implement PEP 488
In-Reply-To: <1426944831.0.0.593089874415.issue23731@psf.upfronthosting.co.za>
Message-ID: <1427567301.04.0.315768848147.issue23731@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23731>
_______________________________________

From report at bugs.python.org  Sat Mar 28 20:25:31 2015
From: report at bugs.python.org (Hammerite)
Date: Sat, 28 Mar 2015 19:25:31 +0000
Subject: [issue23550] Add to unicodedata a function to query the "Quick_Check"
 property for a character
In-Reply-To: <1425147670.05.0.762030398058.issue23550@psf.upfronthosting.co.za>
Message-ID: <1427570731.7.0.312848775596.issue23550@psf.upfronthosting.co.za>


Hammerite added the comment:

For good measure, here is a patch that makes all of Berker's suggested stylistic changes, but applies them to the pre-existing code in makeunicodedata.py and unicodedata.c. So all of the existing docstrings are converted from '"...\n\' to '"...\n"' form, and the other property name arrays that were non-static are made static.

----------
Added file: http://bugs.python.org/file38719/quick_check_4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23550>
_______________________________________

From report at bugs.python.org  Sat Mar 28 20:39:05 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 28 Mar 2015 19:39:05 +0000
Subject: [issue23771] Timeouts on "x86 Ubuntu Shared 3.x" buildbot
In-Reply-To: <1427251322.87.0.815245923642.issue23771@psf.upfronthosting.co.za>
Message-ID: <1427571545.45.0.116759355993.issue23771@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23771>
_______________________________________

From report at bugs.python.org  Sat Mar 28 20:57:11 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 28 Mar 2015 19:57:11 +0000
Subject: [issue23797] Mac OS X locale setup in thread happens sometime after
 run() is called
In-Reply-To: <1427539675.57.0.610869974475.issue23797@psf.upfronthosting.co.za>
Message-ID: <1427572631.6.0.921148484636.issue23797@psf.upfronthosting.co.za>


Ned Deily added the comment:

The behavior noted in Issue18378 isn't an Apple bug; it's a GNU vs BSD difference.  Can you avoid the problem by calling locale.getlocale() in the main program before creating any threads?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23797>
_______________________________________

From report at bugs.python.org  Sat Mar 28 21:10:30 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 Mar 2015 20:10:30 +0000
Subject: [issue23799] Join started threads in tests
Message-ID: <1427573430.36.0.605750682641.issue23799@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When a test starts many threads in a loop, there is a chance that the starting thread will fail due to lack of memory. In this case all started threads left dangling and make MemotyError even more probably. They also can provoke dim error messages in this and in following tests. Proposed patch adds new helper function test.support.start_threads() that starts threads and then join started threads.

Some tests even hang without this patch.

----------
components: Tests
files: test_support_start_threads.patch
keywords: patch
messages: 239465
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Join started threads in tests
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38720/test_support_start_threads.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23799>
_______________________________________

From report at bugs.python.org  Sat Mar 28 21:42:17 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Sat, 28 Mar 2015 20:42:17 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1427575337.65.0.763478800471.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

Ryan,
For now I'll make the edits to pyconfig.h manually after downloading the zip from the tip and running configure with necessary params.

I'll do my best to get this done this weekend, but it may have to wait until next.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23496>
_______________________________________

From report at bugs.python.org  Sat Mar 28 21:50:31 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 28 Mar 2015 20:50:31 +0000
Subject: [issue23800] Support POSIX uselocale interface for thread-specific
 locale settings
Message-ID: <1427575831.26.0.23077822818.issue23800@psf.upfronthosting.co.za>


New submission from Ned Deily:

POSIX 2008 provides a system interface, uselocale, to set locales individually on a thread basis rather than just process global, as currently supported with locale.setlocale().  uselocale is supported in most current GNU libc, BSD, and OS X releases.  While there is currently a third-party package available in PyPI, it currently doesn't claim to support Python 3 and it would be good to have uselocale as part of the standard library where available.

http://pubs.opengroup.org/stage7tc1/functions/uselocale.html

https://github.com/wichert/xlocale

----------
components: Library (Lib)
messages: 239467
nosy: lemburg, loewis, ned.deily
priority: normal
severity: normal
status: open
title: Support POSIX uselocale interface for thread-specific locale settings
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23800>
_______________________________________

From report at bugs.python.org  Sat Mar 28 23:58:28 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Sat, 28 Mar 2015 22:58:28 +0000
Subject: [issue23787] sum() function docstring lists arguments incorrectly
In-Reply-To: <1427455446.97.0.658394608092.issue23787@psf.upfronthosting.co.za>
Message-ID: <1427583508.68.0.191032939185.issue23787@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

>This implies sum() should accept str, unicode, list, tuple, bytearray, buffer, and xrange.

and in fact it *does* accept all these as input. It just refuses to add the elements of the sequence if these elements are of certain types. Of course, the elements of a string are strings themselves so this does not work:

>>> sum('abc', '')
Traceback (most recent call last):
  File "<pyshell#88>", line 1, in <module>
    sum('abc', '')
TypeError: sum() can't sum strings [use ''.join(seq) instead]


compare with a bytes sequence in Python3, where the elements are ints:

>>> sum(b'abc', 0)
294


but strings are also perfectly accepatble as input if you do not try to add their str elements, but something else:

>>> class X (int):
    def __add__(self, other):
        return X(ord(other) + self)

>>> sum('abc', X(0))
294

=> the docs are right and there is no issue here.

----------
nosy: +wolma

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23787>
_______________________________________

From report at bugs.python.org  Sun Mar 29 01:55:03 2015
From: report at bugs.python.org (Davin Potts)
Date: Sun, 29 Mar 2015 00:55:03 +0000
Subject: [issue23771] Timeouts on "x86 Ubuntu Shared 3.x" buildbot
In-Reply-To: <1427251322.87.0.815245923642.issue23771@psf.upfronthosting.co.za>
Message-ID: <1427590503.34.0.592458151045.issue23771@psf.upfronthosting.co.za>


Davin Potts added the comment:

@haypo:  Could you please take a look at applying my patches from issue23713 to address an intermittent multiprocessing test failure?  I don't know that it is the sole cause, but it is indeed one potential source of the misbehavior.

----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23771>
_______________________________________

From report at bugs.python.org  Sun Mar 29 01:56:37 2015
From: report at bugs.python.org (Davin Potts)
Date: Sun, 29 Mar 2015 00:56:37 +0000
Subject: [issue23771] Timeouts on "x86 Ubuntu Shared 3.x" buildbot
In-Reply-To: <1427251322.87.0.815245923642.issue23771@psf.upfronthosting.co.za>
Message-ID: <1427590597.2.0.00255240968266.issue23771@psf.upfronthosting.co.za>


Davin Potts added the comment:

@haypo: I didn't think that one through -- the consequences of that fragile test are not a hang.  It's unrelated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23771>
_______________________________________

From report at bugs.python.org  Sun Mar 29 04:22:21 2015
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 29 Mar 2015 02:22:21 +0000
Subject: [issue23801] cgi.FieldStorage has different (wrong?) behavior on
 Python3 than Python2
Message-ID: <1427595741.08.0.994267842721.issue23801@psf.upfronthosting.co.za>


New submission from Donald Stufft:

While working on PyPI 2.0 (which is currently running Python 3) I discovered that ``setup.py upload`` was causing an exception. After tracing things I determined that the reason for this is that Python 3 fails to handle leading whitespace in a multipart body.

I've attached a minimum reproducer that runs without error on Python 2.6 and Python 2.7 which fails on Python 3.2, 3.3, and 3.4.

If I go into the cgi.py module and add a print() statement that will print the header of each part, I get output that looks like:

b'----------------GHSKFJDLGDS7543FJKLFHRE75642756743254\r\nContent-Disposition: form-data; name="protcol_version"\r\n\r\n'
b'Content-Disposition: form-data; name="summary"\r\n\r\n'
b'Content-Disposition: form-data; name="home_page"\r\n\r\n'
b'Content-Disposition: form-data; name="filetype"\r\n\r\n'
b'Content-Disposition: form-data; name="content"; filename="jasmin-13.13.13.tar.gz"\r\n\r\n'

The first line of that is obviously suspicious since it includes the inner boundary marker. Looking at the Python 3.x code it throws away the first line off the fp and then proceeds to process the rest of the fp. However in this case the first line is just a blank b'\r\n'. Looking at the Python 2.7 code it throws away an entire first part, not just the first line.

I'm guessing that the "read first line and throw it away code" needs to continue reading lines until it's read enough lines to get to the boundary marker.

----------
files: reproduce.py
messages: 239471
nosy: dstufft
priority: normal
severity: normal
status: open
title: cgi.FieldStorage has different (wrong?) behavior on Python3 than Python2
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38721/reproduce.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23801>
_______________________________________

From report at bugs.python.org  Sun Mar 29 04:30:39 2015
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 29 Mar 2015 02:30:39 +0000
Subject: [issue23801] cgi.FieldStorage has different (wrong?) behavior on
 Python3 than Python2
In-Reply-To: <1427595741.08.0.994267842721.issue23801@psf.upfronthosting.co.za>
Message-ID: <1427596239.88.0.934985182396.issue23801@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Added a patch that fixes this issue by reading lines until we find the line that is our expected boundary marker.

----------
keywords: +patch
Added file: http://bugs.python.org/file38722/cgi-read-until-boundary.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23801>
_______________________________________

From report at bugs.python.org  Sun Mar 29 08:01:41 2015
From: report at bugs.python.org (Daniel Shahaf)
Date: Sun, 29 Mar 2015 06:01:41 +0000
Subject: [issue23802] patch: __deepcopy__ memo dict argument usage
Message-ID: <1427608901.41.0.0640545279461.issue23802@psf.upfronthosting.co.za>


New submission from Daniel Shahaf:

In the 'copy' module documentation, it wasn't fully clear to me how __deepcopy__ implementations should treat the memo dict argument.  The attached patch clarifies that __deepcopy__ implementations should treat the memo dict argument as an opaque type.

----------
assignee: docs at python
components: Documentation
files: opaque.diff
keywords: patch
messages: 239473
nosy: danielsh, docs at python
priority: normal
severity: normal
status: open
title: patch: __deepcopy__ memo dict argument usage
type: enhancement
Added file: http://bugs.python.org/file38723/opaque.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23802>
_______________________________________

From report at bugs.python.org  Sun Mar 29 08:34:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Mar 2015 06:34:17 +0000
Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable
 (on POSIX)
In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za>
Message-ID: <1427610857.22.0.179632627313.issue23458@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The test_urandom_fd_non_inheritable is constantly failed on AMD64 OpenIndiana 2.7 buildbot.

http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%202.7/builds/2727/steps/test/logs/stdio
======================================================================
FAIL: test_urandom_fd_non_inheritable (test.test_os.URandomTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/64bits/2.7.cea-indiana-amd64/build/Lib/test/test_support.py", line 387, in wrapper
    return func(*args, **kw)
  File "/export/home/buildbot/64bits/2.7.cea-indiana-amd64/build/Lib/test/test_os.py", line 601, in test_urandom_fd_non_inheritable
    self.assertEqual(open_fds - set(range(3)), set())
AssertionError: Items in the first set but not the second:
4

----------------------------------------------------------------------

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23458>
_______________________________________

From report at bugs.python.org  Sun Mar 29 09:02:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Mar 2015 07:02:47 +0000
Subject: [issue23803] str.partition() is broken in 3.4
Message-ID: <1427612567.08.0.637724736927.issue23803@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Tests added in b923eeaf8162 exposed a bug in str.partition() and str.rpartition() in 3.4 on big-endian platforms. It should exist in 3.3 too. It likely was fixed in 3.5 in issue23573.

http://buildbot.python.org/all/builders/PPC64%20PowerLinux%203.4/builds/913/steps/test/logs/stdio
======================================================================
FAIL: test_partition (test.test_unicode.UnicodeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.4.edelsohn-powerlinux-ppc64/build/Lib/test/test_unicode.py", line 383, in test_partition
    left + right, 'partition', delim)
  File "/home/shager/cpython-buildarea/3.4.edelsohn-powerlinux-ppc64/build/Lib/test/string_tests.py", line 63, in checkequal
    realresult
AssertionError: Tuples differ: ('bbbbbbbbbaaaaaaaaa', '', '') != ('', '?', '\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00')

First differing element 0:
bbbbbbbbbaaaaaaaaa


- ('bbbbbbbbbaaaaaaaaa', '', '')
+ ('', '?', '\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00')

======================================================================
FAIL: test_rpartition (test.test_unicode.UnicodeTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.4.edelsohn-powerlinux-ppc64/build/Lib/test/test_unicode.py", line 399, in test_rpartition
    left + right, 'rpartition', delim)
  File "/home/shager/cpython-buildarea/3.4.edelsohn-powerlinux-ppc64/build/Lib/test/string_tests.py", line 63, in checkequal
    realresult
AssertionError: Tuples differ: ('', '', 'bbbbbbbbbaaaaaaaaa') != ('\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00', '?', '')

First differing element 0:

bbbb

- ('', '', 'bbbbbbbbbaaaaaaaaa')
+ ('\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00', '?', '')

----------------------------------------------------------------------

'bbbbbbbbbaaaaaaaaa'.partition('\U00010302') returns ('', '?', '\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00')
'bbbbbbbbbaaaaaaaaa'.rpartition('\U00010302') returns ('\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00\x00\x00b\x00', '?', '')

----------
assignee: serhiy.storchaka
components: Interpreter Core
messages: 239475
nosy: benjamin.peterson, ezio.melotti, haypo, lemburg, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: str.partition() is broken in 3.4
type: behavior
versions: Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23803>
_______________________________________

From report at bugs.python.org  Sun Mar 29 09:31:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Mar 2015 07:31:00 +0000
Subject: [issue23803] str.partition() is broken in 3.4
In-Reply-To: <1427612567.08.0.637724736927.issue23803@psf.upfronthosting.co.za>
Message-ID: <1427614260.42.0.385398558632.issue23803@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that should fix the bug.

Can it be committed in 3.3 Georg? The patch is simple and fixes a bug in basic type.

----------
keywords: +patch
nosy: +georg.brandl
stage: needs patch -> patch review
Added file: http://bugs.python.org/file38724/str_partition_kind.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23803>
_______________________________________

From report at bugs.python.org  Sun Mar 29 09:36:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Mar 2015 07:36:53 +0000
Subject: [issue23803] str.partition() is broken in 3.4
In-Reply-To: <1427612567.08.0.637724736927.issue23803@psf.upfronthosting.co.za>
Message-ID: <1427614613.4.0.207162270319.issue23803@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The bug can be reproduced on little-endian platform.

>>> 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'.partition('?')
('A', '?', 'B\x00C\x00D\x00E\x00F\x00G\x00H\x00I\x00J\x00K\x00L\x00M\x00')
>>> 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'.rpartition('?')
('A\x00B\x00C\x00D\x00E\x00F\x00G\x00H\x00I\x00J\x00K\x00L\x00M', '?', '')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23803>
_______________________________________

From report at bugs.python.org  Sun Mar 29 09:50:10 2015
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 29 Mar 2015 07:50:10 +0000
Subject: [issue23801] cgi.FieldStorage has different (wrong?) behavior on
 Python3 than Python2
In-Reply-To: <1427595741.08.0.994267842721.issue23801@psf.upfronthosting.co.za>
Message-ID: <1427615410.93.0.337762205156.issue23801@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Added R David Murray to the nosy list because this is kinda similar to the email stuff and there doesn't seem to be anyone better to look at this patch that I can find...

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23801>
_______________________________________

From report at bugs.python.org  Sun Mar 29 09:52:49 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 29 Mar 2015 07:52:49 +0000
Subject: [issue23803] str.partition() is broken in 3.4
In-Reply-To: <1427614613.4.0.207162270319.issue23803@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa0wVJiUu6cyxtu_bW46dyDVKksA4wtpRw9jiN1XoGUhg@mail.gmail.com>


STINNER Victor added the comment:

The patch lacks unit test. You showed a test which fails also on little
endian.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23803>
_______________________________________

From report at bugs.python.org  Sun Mar 29 09:52:50 2015
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 29 Mar 2015 07:52:50 +0000
Subject: [issue23801] cgi.FieldStorage has different (wrong?) behavior on
 Python3 than Python2
In-Reply-To: <1427595741.08.0.994267842721.issue23801@psf.upfronthosting.co.za>
Message-ID: <1427615570.55.0.128925876956.issue23801@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Also adding Berker Peksag because they've touched this module recently :)

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23801>
_______________________________________

From report at bugs.python.org  Sun Mar 29 10:08:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Mar 2015 08:08:09 +0000
Subject: [issue23713] intermittent failure of multiprocessing unit test
 test_imap_unordered_handle_iterable_exception
In-Reply-To: <1426795503.26.0.283860442544.issue23713@psf.upfronthosting.co.za>
Message-ID: <1427616489.66.0.397517544696.issue23713@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Why not use just

    self.assertEqual(sorted(it), list(map(sqr, list(range(10)))))

or

    self.assertCountEqual(list(it), list(map(sqr, list(range(10)))))

?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23713>
_______________________________________

From report at bugs.python.org  Sun Mar 29 12:07:54 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 Mar 2015 10:07:54 +0000
Subject: [issue23796] BufferedReader.peek() crashes if closed
In-Reply-To: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za>
Message-ID: <1427623674.52.0.313365639278.issue23796@psf.upfronthosting.co.za>


Martin Panter added the comment:

Happy to when I get a chance. It should be easy to do, though it is not high on my priority list because I don?t think the scenario is very important in real world usage. I only encountered it when testing edge cases in another patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23796>
_______________________________________

From report at bugs.python.org  Sun Mar 29 12:27:43 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Mar 2015 10:27:43 +0000
Subject: [issue23796] BufferedReader.peek() crashes if closed
In-Reply-To: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za>
Message-ID: <1427624863.79.0.428706443152.issue23796@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23796>
_______________________________________

From report at bugs.python.org  Sun Mar 29 12:30:23 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 Mar 2015 10:30:23 +0000
Subject: [issue23804] SSLSocket.recv(0) receives up to 1024 bytes
Message-ID: <1427625023.61.0.148010223441.issue23804@psf.upfronthosting.co.za>


New submission from Martin Panter:

The documentation claims that SSL socket objects provide some of the same methods as plain socket objects, including recv(), and that the ?bufsize? parameter specifies the maximum amount of data to be received. With ordinary sockets, socket.recv(0) always seems to return zero bytes (b""), as expected. But not so with SSL sockets:

>>> import socket, ssl
>>> s = ssl.wrap_socket(socket.create_connection(("localhost", 631)))
>>> s.sendall(b"GET / HTTP/1.1\r\nHost: localhost\r\n\r\n")
35
>>> len(s.recv(0))
263
>>> len(s.recv(0))
1024

The call will hang or raise SSLWantReadError when no data is actually available. Looking at the code, the value of zero seems to be used as a placeholder for a default of 1024 in SSLObject.read(). Either the SSL module should be fixed to return no bytes (my preference), or the documentation needs to warn that the recv(0) is not supported, or does not work the same as for plain sockets. SSLSocket.read() might also be affected.

----------
components: Library (Lib)
messages: 239483
nosy: vadmium
priority: normal
severity: normal
status: open
title: SSLSocket.recv(0) receives up to 1024 bytes
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23804>
_______________________________________

From report at bugs.python.org  Sun Mar 29 13:00:56 2015
From: report at bugs.python.org (Barry Alan Scott)
Date: Sun, 29 Mar 2015 11:00:56 +0000
Subject: [issue23797] Mac OS X locale setup in thread happens sometime after
 run() is called
In-Reply-To: <1427539675.57.0.610869974475.issue23797@psf.upfronthosting.co.za>
Message-ID: <1427626856.47.0.177290166635.issue23797@psf.upfronthosting.co.za>


Barry Alan Scott added the comment:

I should point out using Python2.7 with wxPython I do not see this issue.
This issue was exposed during my efforts to port pysvn from py2.7+wxPython to py3.4+wxpython-phoenix.

I do setup locale on the main thread very early before starting the background thread.
I have attached the initLocale() I use.

The background thread needs the locale setup and I use getlocale() to prove that it is setup.

I do not see this as a duplicate of Issue18378 as I can init the locale. 

The problem, and I could believe its an OSX bug, is that new threads do not return the expected locale from _locale.setlocale() for a period of time, approx 2s after starting up.

----------
Added file: http://bugs.python.org/file38725/initLocale.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23797>
_______________________________________

From report at bugs.python.org  Sun Mar 29 13:08:38 2015
From: report at bugs.python.org (Barry Alan Scott)
Date: Sun, 29 Mar 2015 11:08:38 +0000
Subject: [issue18378] locale.getdefaultlocale() fails on Mac OS X with default
 language set to English
In-Reply-To: <1373113143.69.0.513997485887.issue18378@psf.upfronthosting.co.za>
Message-ID: <1427627318.3.0.219175684323.issue18378@psf.upfronthosting.co.za>


Barry Alan Scott added the comment:

Mac OS X use the __CF_USER_TEXT_ENCODING env var to setup the locale in for native libraries.

I found that for GUI python code I needed to convert the value in __CF_USER_TEXT_ENCODING into a suitable call to setlocale().

The code I use is attached to Issue23797.

----------
nosy: +barry-scott

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18378>
_______________________________________

From report at bugs.python.org  Sun Mar 29 13:18:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Mar 2015 11:18:09 +0000
Subject: [issue23803] str.partition() is broken in 3.4
In-Reply-To: <1427612567.08.0.637724736927.issue23803@psf.upfronthosting.co.za>
Message-ID: <1427627889.69.0.624740425704.issue23803@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added tests that fail on little and big endianess.

----------
Added file: http://bugs.python.org/file38726/str_partition_kind_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23803>
_______________________________________

From report at bugs.python.org  Sun Mar 29 14:23:21 2015
From: report at bugs.python.org (Freddy)
Date: Sun, 29 Mar 2015 12:23:21 +0000
Subject: [issue23805] _hashlib compile error?
Message-ID: <1427631801.6.0.245894260937.issue23805@psf.upfronthosting.co.za>


New submission from Freddy:

I just installed Python 3.5.0a2 from Source.
Debian 3.2.65-1+deb7u1 x86_64 GNU/Linux

[264/392] test_hashlib
/root/Downloads/Python-3.5.0a2/Lib/test/test_hashlib.py:52: UserWarning: Did a C extension fail to compile? No module named '_hashlib'
  warnings.warn('Did a C extension fail to compile? %s' % error)

Sorry, I'm not sure if it is an issue.

----------
components: Installation
messages: 239487
nosy: SinusAlpha
priority: normal
severity: normal
status: open
title: _hashlib compile error?
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23805>
_______________________________________

From report at bugs.python.org  Sun Mar 29 14:42:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Mar 2015 12:42:22 +0000
Subject: [issue22390] test.regrtest should complain if a test doesn't remove
 temporary files
In-Reply-To: <1410445852.03.0.724241204359.issue22390@psf.upfronthosting.co.za>
Message-ID: <1427632942.85.0.473855405713.issue22390@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Victor?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22390>
_______________________________________

From report at bugs.python.org  Sun Mar 29 15:12:16 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Sun, 29 Mar 2015 13:12:16 +0000
Subject: [issue23746] sysconfg.is_python_build() is buggy
In-Reply-To: <1427101982.73.0.589713060591.issue23746@psf.upfronthosting.co.za>
Message-ID: <1427634736.07.0.250886082561.issue23746@psf.upfronthosting.co.za>


Changes by Anand B Pillai <anandpillai at letterboxes.org>:


----------
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23746>
_______________________________________

From report at bugs.python.org  Sun Mar 29 15:12:28 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Sun, 29 Mar 2015 13:12:28 +0000
Subject: [issue23746] sysconfg.is_python_build() is buggy
In-Reply-To: <1427101982.73.0.589713060591.issue23746@psf.upfronthosting.co.za>
Message-ID: <1427634748.4.0.0694746394361.issue23746@psf.upfronthosting.co.za>


Changes by Anand B Pillai <anandpillai at letterboxes.org>:


----------
assignee:  -> docs at python
components: +Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23746>
_______________________________________

From report at bugs.python.org  Sun Mar 29 16:11:59 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Mar 2015 14:11:59 +0000
Subject: [issue23802] patch: __deepcopy__ memo dict argument usage
In-Reply-To: <1427608901.41.0.0640545279461.issue23802@psf.upfronthosting.co.za>
Message-ID: <1427638319.16.0.0396928271637.issue23802@psf.upfronthosting.co.za>


R. David Murray added the comment:

I would rather say simply "The memo dictionary should be treated as an opaque object".  On the other hand, I doubt we will ever change the structure of the memo dict, because I'm sure that somewhere out there there is code that is *not* treating it as opaque :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23802>
_______________________________________

From report at bugs.python.org  Sun Mar 29 16:27:31 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 29 Mar 2015 14:27:31 +0000
Subject: [issue23801] cgi.FieldStorage has different (wrong?) behavior on
 Python3 than Python2
In-Reply-To: <1427595741.08.0.994267842721.issue23801@psf.upfronthosting.co.za>
Message-ID: <1427639251.14.0.0899877608419.issue23801@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

The loop might be more elegantly expressed as

for line in self.fp:
    self.bytes_read += len(line)
    if line.strip() != b"--" + self.innerboundary:
        break

but otherwise lgtm

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23801>
_______________________________________

From report at bugs.python.org  Sun Mar 29 16:32:02 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Mar 2015 14:32:02 +0000
Subject: [issue23805] _hashlib compile error?
In-Reply-To: <1427631801.6.0.245894260937.issue23805@psf.upfronthosting.co.za>
Message-ID: <1427639522.28.0.141648513964.issue23805@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, you'll need to look in your build log to see why _hashlib failed to compile or failed to be usable.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23805>
_______________________________________

From report at bugs.python.org  Sun Mar 29 16:53:27 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 29 Mar 2015 14:53:27 +0000
Subject: [issue23803] str.partition() is broken in 3.4
In-Reply-To: <1427612567.08.0.637724736927.issue23803@psf.upfronthosting.co.za>
Message-ID: <1427640807.39.0.0335925556441.issue23803@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

lgtm

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23803>
_______________________________________

From report at bugs.python.org  Sun Mar 29 16:56:26 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Mar 2015 14:56:26 +0000
Subject: [issue23806] documentation for no_proxy is missing from the python3
 urllib documentation
Message-ID: <1427640986.55.0.996928918568.issue23806@psf.upfronthosting.co.za>


New submission from R. David Murray:

no_proxy (and what notation it supports) is mentioned in the python2 urllib docs, but not in the python3 docs.

----------
assignee: docs at python
components: Documentation
messages: 239493
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: documentation for no_proxy is missing from the python3 urllib documentation
type: behavior
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23806>
_______________________________________

From report at bugs.python.org  Sun Mar 29 17:42:19 2015
From: report at bugs.python.org (Thana Annis)
Date: Sun, 29 Mar 2015 15:42:19 +0000
Subject: [issue23807] Improved test coverage for calendar.py command line
Message-ID: <1427643739.5.0.155189832451.issue23807@psf.upfronthosting.co.za>


New submission from Thana Annis:

Added a test to ensure that --locale cannot be called without --encoding. This is targeting lines 654-656 of calendar.py.

----------
components: Tests
files: test_calendar.patch
keywords: patch
messages: 239494
nosy: Bwaffles
priority: normal
severity: normal
status: open
title: Improved test coverage for calendar.py command line
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38727/test_calendar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23807>
_______________________________________

From report at bugs.python.org  Sun Mar 29 18:21:02 2015
From: report at bugs.python.org (Tuomas Suutari)
Date: Sun, 29 Mar 2015 16:21:02 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1427646062.42.0.130980711472.issue23602@psf.upfronthosting.co.za>


Tuomas Suutari added the comment:

Thanks for the comments again!

I fixed the "format(F(4, 27), '.1f') -> 0.2" issue
Serhiy Storchaka reported. Fix for that was as simple as adding one to the precision the decimals are calculated in, but while adding test cases for that I realized two new things:

  (a) I don't want "f" specifier to mean "infinite" precision, but instead some predefined value. I chose 6.
  (b) How about rounding? I don't want the current decimal context to affect that, since it's not logical that formatting of Fractions depends on the decimal context.

The rounding thing made things harder, since there was no way to pass decimal context for Decimal.__format__ without changing the local context -- at least with the C implementation; the Python implementation (_pydecimal) provided nicer API with optional context keyword argument.  So I decided to unify the C and Py API's of Decimal.__format__ and add the keyword argument support to the C API too. This is done in this v4 of the patch.

There's no docs for the added Decimal.__format__ kwargs, since I want some comments on that change first.

----------
Added file: http://bugs.python.org/file38728/issue23602v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Sun Mar 29 18:24:21 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Mar 2015 16:24:21 +0000
Subject: [issue23803] str.partition() is broken in 3.4
In-Reply-To: <1427612567.08.0.637724736927.issue23803@psf.upfronthosting.co.za>
Message-ID: <20150329162418.55362.75869@psf.io>


Roundup Robot added the comment:

New changeset c23713af8be7 by Serhiy Storchaka in branch '3.4':
Issue #23803: Fixed str.partition() and str.rpartition() when a separator
https://hg.python.org/cpython/rev/c23713af8be7

New changeset c48637f57e2b by Serhiy Storchaka in branch 'default':
Added explicit tests for issue #23803.
https://hg.python.org/cpython/rev/c48637f57e2b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23803>
_______________________________________

From report at bugs.python.org  Sun Mar 29 18:42:53 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Mar 2015 16:42:53 +0000
Subject: [issue23801] cgi.FieldStorage has different (wrong?) behavior on
 Python3 than Python2
In-Reply-To: <1427595741.08.0.994267842721.issue23801@psf.upfronthosting.co.za>
Message-ID: <1427647373.46.0.972476876487.issue23801@psf.upfronthosting.co.za>


R. David Murray added the comment:

The code you are modifying looks completely wrong-headed to me.  Unfortunately I don't have time to rewrite the cgi module right now :).  Given that, your fix looks fine: the first part of a multipart (up to the first inner boundary) is the 'preamble', which can contain pretty much arbitrary content, and in the context of cgi should indeed be completely ignored.  

Benjamin's suggested modification has the if logic reversed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23801>
_______________________________________

From report at bugs.python.org  Sun Mar 29 18:54:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Mar 2015 16:54:26 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1427648066.0.0.368721431567.issue23602@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think that Decimal is not needed for Fraction.__format__ (and I'm not sure that issue23602v4.patch is correct). The correct way to format Fraction as fixed-precision decimal is to use Fraction.__round__() or similar algorithm. The implementation can look like:

    f = self.__round__(prec)
    i = int(f)
    return '%d.%0*d' % (i, prec, abs(f - i) * 10**prec)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Sun Mar 29 18:55:15 2015
From: report at bugs.python.org (Joshua Bronson)
Date: Sun, 29 Mar 2015 16:55:15 +0000
Subject: [issue23548] TypeError in event loop finalizer, new in Python 3.4.3
In-Reply-To: <1425139981.48.0.523334940185.issue23548@psf.upfronthosting.co.za>
Message-ID: <1427648115.07.0.985882265312.issue23548@psf.upfronthosting.co.za>


Joshua Bronson added the comment:

Quoting Victor Stinner:
>  I may workaround the bug during Python finalization if more users report this issue.

Read the above so reporting I'm hitting this too fwiw.

Thanks for the great work on asyncio.

----------
nosy: +jab

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23548>
_______________________________________

From report at bugs.python.org  Sun Mar 29 19:00:10 2015
From: report at bugs.python.org (Joshua Bronson)
Date: Sun, 29 Mar 2015 17:00:10 +0000
Subject: [issue23548] TypeError in event loop finalizer, new in Python 3.4.3
In-Reply-To: <1425139981.48.0.523334940185.issue23548@psf.upfronthosting.co.za>
Message-ID: <1427648410.13.0.879454927362.issue23548@psf.upfronthosting.co.za>


Joshua Bronson added the comment:

Not sure if it's related / helpful but just in case, since upgrading from 3.4.2 to 3.4.3, I'm now seeing this printed to stderr sometimes when my program exits:

Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in: Exception ignored in:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23548>
_______________________________________

From report at bugs.python.org  Sun Mar 29 19:07:02 2015
From: report at bugs.python.org (Tuomas Suutari)
Date: Sun, 29 Mar 2015 17:07:02 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1427648066.0.0.368721431567.issue23602@psf.upfronthosting.co.za>
Message-ID: <CAPXCX8CPpQtnNQ34-dEx5g6YVzvgXGAif063MR5K5-3w43eB=g@mail.gmail.com>


Tuomas Suutari added the comment:

On 29 March 2015 at 19:54, Serhiy Storchaka wrote:
> I think that Decimal is not needed for Fraction.__format__ (and I'm not sure that issue23602v4.patch is correct).

Of course it's not needed. I'm using it to avoid re-implementing all
the various formatting variations that can be controlled with the
fill/align/sign/width/,/precision/type parameters
(https://docs.python.org/3/library/string.html#formatspec). IMHO those
should be supported as they are with floats and Decimals.

> The correct way to format Fraction as fixed-precision decimal is to use Fraction.__round__() or similar algorithm. The implementation can look like:
>
>     f = self.__round__(prec)
>     i = int(f)
>     return '%d.%0*d' % (i, prec, abs(f - i) * 10**prec)

Why this would be more correct than delegating the rounding (and
formatting) to Decimal.__format__? (Then we just have to make sure
that we have enough precision in the decimal context we're operating
in. That's what I got wrong in the previous round.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Sun Mar 29 19:21:08 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 29 Mar 2015 17:21:08 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1427649668.6.0.257435552081.issue23602@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

But these parameters could also be partly delegated to normal string (not number) formatting, right?

One of the advantages of not depending on Decimal is, well, to not depend on Decimal, which is a rather uncommon dependency when using Fractions in an application.

I think it could avoid some more calculations to first multiply the nominator by 10**prec, then round(), int() and str() the result, and then split the string at "-prec".

BTW, if "division with remainder" wasn't (sadly) linear time, that would definitely be the most beautiful algorithm here. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Sun Mar 29 19:31:20 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 29 Mar 2015 17:31:20 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1427650280.56.0.878167984802.issue23602@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Meaning, something like this should work:

    x = (nom * 10**(prec+1)) // den
    if x % 10 < 5:
       x = x // 10
    else:
       x = x // 10 + 1
    print('%s.%s' % (x[:-prec], x[-prec:]))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Sun Mar 29 19:40:47 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 29 Mar 2015 17:40:47 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1427650847.83.0.544101875314.issue23602@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Or, speaking of "division with remainder":

    n, r = divmod(nom * 10**prec, den)
    if r * 5 >= den:
        n += 1
    x = str(n)
    print('%s.%s' % (x[:-prec], x[-prec:]))

... minus the usual off-by-one that the tests would quickly find :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Sun Mar 29 20:09:29 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Mar 2015 18:09:29 +0000
Subject: [issue23798] NameError in the encode fixer
In-Reply-To: <1427565654.6.0.111247541.issue23798@psf.upfronthosting.co.za>
Message-ID: <1427652569.94.0.260276111242.issue23798@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, sorry, this was my local file.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23798>
_______________________________________

From report at bugs.python.org  Sun Mar 29 20:44:51 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 29 Mar 2015 18:44:51 +0000
Subject: [issue22500] Argparse always stores True for positional arguments
In-Reply-To: <1411697591.54.0.644462520859.issue22500@psf.upfronthosting.co.za>
Message-ID: <1427654691.1.0.745551671305.issue22500@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22500>
_______________________________________

From report at bugs.python.org  Sun Mar 29 20:45:10 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Mar 2015 18:45:10 +0000
Subject: [issue23808] Symlink to directory on Windows 8
Message-ID: <1427654710.52.0.171827508348.issue23808@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Looks as a symlink on Windows 8 can has the FILE_ATTRIBUTE_DIRECTORY flag.

http://buildbot.python.org/all/builders/AMD64%20Windows8%203.4/builds/348/steps/test/logs/stdio
======================================================================
FAIL: test_walk_bottom_up (test.test_os.WalkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File &#34;D:\buildarea\3.4.bolen-windows8\build\lib\test\test_os.py&#34;, line 802, in test_walk_bottom_up
    self.sub2_tree)
AssertionError: Tuples differ: (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;broken_link&#39;, &#39;link&#39;], [&#39;tmp3&#39;]) != (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;link&#39;], [&#39;broken_link&#39;, &#39;tmp3&#39;])

First differing element 1:
[&#39;broken_link&#39;, &#39;link&#39;]
[&#39;link&#39;]

- (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;broken_link&#39;, &#39;link&#39;], [&#39;tmp3&#39;])
?                                                 ----------

+ (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;link&#39;], [&#39;broken_link&#39;, &#39;tmp3&#39;])
?                                 ++++++++++


======================================================================
FAIL: test_walk_prune (test.test_os.WalkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File &#34;D:\buildarea\3.4.bolen-windows8\build\lib\test\test_os.py&#34;, line 782, in test_walk_prune
    self.assertEqual(all[1], self.sub2_tree)
AssertionError: Tuples differ: (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;broken_link&#39;, &#39;link&#39;], [&#39;tmp3&#39;]) != (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;link&#39;], [&#39;broken_link&#39;, &#39;tmp3&#39;])

First differing element 1:
[&#39;broken_link&#39;, &#39;link&#39;]
[&#39;link&#39;]

- (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;broken_link&#39;, &#39;link&#39;], [&#39;tmp3&#39;])
?                                                 ----------

+ (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;link&#39;], [&#39;broken_link&#39;, &#39;tmp3&#39;])
?                                 ++++++++++


======================================================================
FAIL: test_walk_topdown (test.test_os.WalkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File &#34;D:\buildarea\3.4.bolen-windows8\build\lib\test\test_os.py&#34;, line 765, in test_walk_topdown
    self.assertEqual(all[3 - 2 * flipped], self.sub2_tree)
AssertionError: Tuples differ: (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;broken_link&#39;, &#39;link&#39;], [&#39;tmp3&#39;]) != (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;link&#39;], [&#39;broken_link&#39;, &#39;tmp3&#39;])

First differing element 1:
[&#39;broken_link&#39;, &#39;link&#39;]
[&#39;link&#39;]

- (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;broken_link&#39;, &#39;link&#39;], [&#39;tmp3&#39;])
?                                                 ----------

+ (&#39;@test_3872_tmp\\TEST1\\SUB2&#39;, [&#39;link&#39;], [&#39;broken_link&#39;, &#39;tmp3&#39;])
?                                 ++++++++++


----------------------------------------------------------------------

Create broken link:

    os.symlink('non_existing_patch', 'broken_link', target_is_directory=True)

What return os.path.isdir('broken_link')?

----------
components: Tests, Windows
messages: 239506
nosy: paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Symlink to directory on Windows 8
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23808>
_______________________________________

From report at bugs.python.org  Sun Mar 29 21:01:47 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 29 Mar 2015 19:01:47 +0000
Subject: [issue23807] Improved test coverage for calendar.py command line
In-Reply-To: <1427643739.5.0.155189832451.issue23807@psf.upfronthosting.co.za>
Message-ID: <1427655707.77.0.599932842747.issue23807@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch! I thought line 654-656 was already tested by self.assertFailure('-L', 'en').

----------
nosy: +berker.peksag, serhiy.storchaka
stage:  -> patch review
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23807>
_______________________________________

From report at bugs.python.org  Sun Mar 29 21:07:21 2015
From: report at bugs.python.org (Valentine Sinitsyn)
Date: Sun, 29 Mar 2015 19:07:21 +0000
Subject: [issue23787] sum() function docstring lists arguments incorrectly
In-Reply-To: <1427455446.97.0.658394608092.issue23787@psf.upfronthosting.co.za>
Message-ID: <1427656041.75.0.988039989874.issue23787@psf.upfronthosting.co.za>


Valentine Sinitsyn added the comment:

Seems like mentioning string was really a bad idea. They were only used as (poor) example, forget them if they are confusing in any way.

In my understanding, any sequence in Python is iterable, bit not all iterables are sequences (correct me if I'm wrong). Then, the purpose of my suggestion is to explicitly say that sum() accepts iterables. In its current form, it seems like it doesn't, that's why I considered the docstring [subtly] wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23787>
_______________________________________

From report at bugs.python.org  Sun Mar 29 21:09:34 2015
From: report at bugs.python.org (=?utf-8?b?U8O4cmVuIEzDuHZib3Jn?=)
Date: Sun, 29 Mar 2015 19:09:34 +0000
Subject: [issue22941] IPv4Interface arithmetic changes subnet mask
In-Reply-To: <1416933717.58.0.234544639586.issue22941@psf.upfronthosting.co.za>
Message-ID: <1427656174.29.0.81501760101.issue22941@psf.upfronthosting.co.za>


S?ren L?vborg added the comment:

As mentioned python-dev, I'm not entirely sold on raising an exception on overflow.

To recap the mailing list discussion, there was general agreement that the current behavior is a bug, suggesting that there's no need to go through the depreciation process. There's been three proposals for correct behavior, though:

A) To simply ignore the subnet mask: 10.0.0.255/24 + 1 = 10.0.1.0/24
B) To "wrap around" inside the subnet: 10.0.0.255/24 + 1 = 10.0.0.0/24
C) To raise exception.

First, note what happens if we overflow an IPv4Address:

    >>> ipaddress.IPv4Address('255.255.255.255') + 1
    Traceback (most recent call last):
    ...
    ipaddress.AddressValueError: 4294967296 (>= 2**32) is not permitted
    as an IPv4 address

At least that suggests a type of exception to use in proposal C.
    
There was not much support for the idea of wrapping (B); for which I see three reasons:

1) No identified use case where this effect would be desirable.
2) It's implicit rather than explicit: The addition operator usually does not imply modular arithmetic.
3) It's inconsistent with IPv4Address, which doesn't wrap.

That leaves the question of raising an exception (C), or not (A).

Now, I used "IPv4Interface + 1" to mean "Give me the IP next to the current one in the current subnet", knowing from the context that the address would be valid and available.

    >>> host = ipaddress.IPv4Interface('10.0.0.2/24')
    >>> peer = host + 1
    
In this context, an exception makes a lot of sense, as it would certainly have been an error if I'd overflowed the subnet.

However, I can also imagine situations in which overflowing would be valid and expected, e.g. as a way to skip to the "same" IP in the next subnet:

    >>> ip = ipaddress.IPv4Interface('10.0.0.1/24')
    >>> ip + ip.network.num_addresses
    IPv4Interface('10.0.1.1/24')

There's an additional issue with raising an exception, and that is that it still won't catch the errors as intended. In my use case:

    >>> host = ipaddress.IPv4Interface('10.0.0.254/24')
    >>> peer = host + 1

This wouldn't overflow and not trigger an exception, but the resulting peer address is still invalid (it's the subnet broadcast address, not a host address).

As for consistency with IPv4Address, I can argue for either proposal:

A) "An IPv4Interface behaves exactly like an IPv4Address, except that it also has an associated subnet mask." (This is essentially how it's currently documented).

C) "Overflowing an IPv4Interface raises AddressValueError just like with IPv4Address."

All in all, I'm in favor of keeping things simple and go with solution A, since C prevents a reasonable use, and doesn't actually catch out of bounds errors anyway. I'm open to being convinced otherwise, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22941>
_______________________________________

From report at bugs.python.org  Sun Mar 29 21:12:17 2015
From: report at bugs.python.org (Paul Moore)
Date: Sun, 29 Mar 2015 19:12:17 +0000
Subject: [issue23808] Symlink to directory on Windows 8
In-Reply-To: <1427654710.52.0.171827508348.issue23808@psf.upfronthosting.co.za>
Message-ID: <1427656337.44.0.58703678688.issue23808@psf.upfronthosting.co.za>


Paul Moore added the comment:

It returns True.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23808>
_______________________________________

From report at bugs.python.org  Sun Mar 29 21:20:15 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Mar 2015 19:20:15 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <20150329192012.9796.90969@psf.io>


Roundup Robot added the comment:

New changeset 77c04e949b4b by R David Murray in branch '3.4':
#23792: Ignore KeyboardInterrupt when the pydoc pager is active.
https://hg.python.org/cpython/rev/77c04e949b4b

New changeset fe0c830b43bb by R David Murray in branch 'default':
Merge: #23792: Ignore KeyboardInterrupt when the pydoc pager is active.
https://hg.python.org/cpython/rev/fe0c830b43bb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Sun Mar 29 21:21:10 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Mar 2015 19:21:10 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <1427656870.76.0.999683497192.issue23792@psf.upfronthosting.co.za>


R. David Murray added the comment:

I've committed the fix.  If someone wants to argue in favor of also handling SIGQUIT, they can open a new issue.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Sun Mar 29 21:23:09 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Mar 2015 19:23:09 +0000
Subject: [issue21398] LC_CTYPE=C:  pydoc leaves terminal in an unusable state
In-Reply-To: <1398857601.48.0.383316165786.issue21398@psf.upfronthosting.co.za>
Message-ID: <1427656989.05.0.815984340993.issue21398@psf.upfronthosting.co.za>


R. David Murray added the comment:

The KeybaordInterrupt problem has been dealt with in issue 23792.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21398>
_______________________________________

From report at bugs.python.org  Sun Mar 29 21:27:33 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Mar 2015 19:27:33 +0000
Subject: [issue23808] Symlink to directory on Windows 8
In-Reply-To: <1427654710.52.0.171827508348.issue23808@psf.upfronthosting.co.za>
Message-ID: <1427657253.0.0.04731229078.issue23808@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Then tests should be adapted for Windows 8.

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23808>
_______________________________________

From report at bugs.python.org  Sun Mar 29 22:25:15 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Sun, 29 Mar 2015 20:25:15 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1427660715.26.0.514734214259.issue23602@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

Initially, I also thought that this should be addressable with Fraction.__round__ or an optimized variation of it, but Tuomas is right that it gets complicated by the fact that you need to cope with the different format specifiers and not all of them fit the algorithm.
In particular, scientific notation poses a problem because it may require a lot more precision in the calculation than the one finally used for formatting. Consider:

>>> float(round(Fraction(4, 27000), 6))
0.000148

but
>>> format(4/27000, 'e')
'1.481481e-04'

Trying to deal with this in pure Python quickly slows your code (at least a few naive attempts of mine) unacceptably compared to Tuomas' patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Sun Mar 29 22:31:42 2015
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 29 Mar 2015 20:31:42 +0000
Subject: [issue23801] cgi.FieldStorage has different (wrong?) behavior on
 Python3 than Python2
In-Reply-To: <1427595741.08.0.994267842721.issue23801@psf.upfronthosting.co.za>
Message-ID: <1427661102.22.0.329446702944.issue23801@psf.upfronthosting.co.za>


Donald Stufft added the comment:

@Benjamin

The reason I didn't do that to begin with, was the code currently checks if the first line is a bytes object or not in order to be able to raise an error if it's returning str instead of bytes. I didn't want to redo that check on every iteration, so I left the original part alone and then used the while loop to handle doing more if needed.

Would you prefer the code written your way and either drop the bytes check or incur the cost of doing the type check on every line?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23801>
_______________________________________

From report at bugs.python.org  Sun Mar 29 22:39:27 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 29 Mar 2015 20:39:27 +0000
Subject: [issue23801] cgi.FieldStorage has different (wrong?) behavior on
 Python3 than Python2
In-Reply-To: <1427595741.08.0.994267842721.issue23801@psf.upfronthosting.co.za>
Message-ID: <1427661567.9.0.547042072326.issue23801@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Oh, I see. I think your way is fine then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23801>
_______________________________________

From report at bugs.python.org  Sun Mar 29 22:43:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Mar 2015 20:43:32 +0000
Subject: [issue23801] cgi.FieldStorage has different (wrong?) behavior on
 Python3 than Python2
In-Reply-To: <1427595741.08.0.994267842721.issue23801@psf.upfronthosting.co.za>
Message-ID: <20150329204329.26450.69418@psf.io>


Roundup Robot added the comment:

New changeset 3af77d1c5c47 by Donald Stufft in branch '3.4':
Closes #23801 - Ignore entire preamble to multipart in cgi.FieldStorage
https://hg.python.org/cpython/rev/3af77d1c5c47

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23801>
_______________________________________

From report at bugs.python.org  Sun Mar 29 22:45:26 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Mar 2015 20:45:26 +0000
Subject: [issue23801] cgi.FieldStorage has different (wrong?) behavior on
 Python3 than Python2
In-Reply-To: <1427595741.08.0.994267842721.issue23801@psf.upfronthosting.co.za>
Message-ID: <20150329204524.27944.17306@psf.io>


Roundup Robot added the comment:

New changeset b9364903d91c by Benjamin Peterson in branch 'default':
merge 3.4 (#23801)
https://hg.python.org/cpython/rev/b9364903d91c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23801>
_______________________________________

From report at bugs.python.org  Sun Mar 29 22:50:07 2015
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 29 Mar 2015 20:50:07 +0000
Subject: [issue23801] cgi.FieldStorage has different (wrong?) behavior on
 Python3 than Python2
In-Reply-To: <1427595741.08.0.994267842721.issue23801@psf.upfronthosting.co.za>
Message-ID: <1427662207.59.0.775052550666.issue23801@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Thanks everyone for taking a look at this!

----------
stage: resolved -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23801>
_______________________________________

From report at bugs.python.org  Sun Mar 29 22:51:22 2015
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 29 Mar 2015 20:51:22 +0000
Subject: [issue23801] cgi.FieldStorage has different (wrong?) behavior on
 Python3 than Python2
In-Reply-To: <1427595741.08.0.994267842721.issue23801@psf.upfronthosting.co.za>
Message-ID: <1427662282.02.0.931774816232.issue23801@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald at stufft.io>:


----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23801>
_______________________________________

From report at bugs.python.org  Sun Mar 29 23:09:59 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Mar 2015 21:09:59 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1427663399.05.0.148702210478.issue2211@psf.upfronthosting.co.za>


R. David Murray added the comment:

I made several changes to the patch.

The whatsnew docs didn't format correctly: there's an extra space on all the lines after the first (a three space indent is apparently required there which I don't understand, but it is also our standard for docs).  Also none of the links work, because in the whatsnew document (unlike in the doc page itself) you have to fully qualify the names (eg: ~http.cookies.Morsel to display 'Morsel' and link to the right place).  The line about LegalChars was in the wrong section.  I rewrote both as a single bullet item with working links.

The 'update' and 'copy' methods were not documented.  I added them and moved the relevant 'versionchanged' phrases under the newly documented methods.

In addition, I decided that the deprecation for key, value, and coded_value would be clearer if phrased as : "assignment to XXX; use set instead".

A couple of other notes: while functionally it doesn't (currently) make any difference to Sphinx if you use :func: vs :meth:, :meth: is the correct one for all these cases.  And you had an extra blank line after the versionchanged directive.

I've uploaded the changeset I applied as a diff so that you can more easily see what I changed if you wish.

----------
Added file: http://bugs.python.org/file38729/http_cookies_morsel_deprecated_set_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Sun Mar 29 23:10:12 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Mar 2015 21:10:12 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <20150329211009.55374.22023@psf.io>


Roundup Robot added the comment:

New changeset 09f22b5d6cea by R David Murray in branch 'default':
#2211: properly document the Morsel behavior changes.
https://hg.python.org/cpython/rev/09f22b5d6cea

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Sun Mar 29 23:11:46 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Mar 2015 21:11:46 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1427663506.1.0.15516043071.issue2211@psf.upfronthosting.co.za>


R. David Murray added the comment:

Now, anyone want to place bets on someone getting bitten by the new errors that update will raise? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Sun Mar 29 23:33:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 29 Mar 2015 21:33:51 +0000
Subject: [issue23548] TypeError in event loop finalizer, new in Python 3.4.3
In-Reply-To: <1425139981.48.0.523334940185.issue23548@psf.upfronthosting.co.za>
Message-ID: <1427664831.47.0.804688393773.issue23548@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Exception ignored in: Exception ignored in: ...

Hum, I already saw such issues when exiting an asyncio application. It's probably because they are some pending tasks or transports which are never closed.

You can try to list tasks at exit using:

loop.close()
print(Task.all_tasks(loop=loop))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23548>
_______________________________________

From report at bugs.python.org  Sun Mar 29 23:46:12 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 Mar 2015 21:46:12 +0000
Subject: [issue23806] documentation for no_proxy is missing from the python3
 urllib documentation
In-Reply-To: <1427640986.55.0.996928918568.issue23806@psf.upfronthosting.co.za>
Message-ID: <1427665572.83.0.648395660765.issue23806@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23806>
_______________________________________

From report at bugs.python.org  Sun Mar 29 23:48:07 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 29 Mar 2015 21:48:07 +0000
Subject: [issue22390] test.regrtest should complain if a test doesn't remove
 temporary files
In-Reply-To: <1410445852.03.0.724241204359.issue22390@psf.upfronthosting.co.za>
Message-ID: <1427665687.68.0.0843765281922.issue22390@psf.upfronthosting.co.za>


STINNER Victor added the comment:

regrtest_warn_lost_files2.patch looks good to me.

I just ran the test suite with "./python -m test -j0 -rW" on Linux, I didn't get any warning.

When I modified test_os to create a file "x", it was noticed by your patch.

Go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22390>
_______________________________________

From report at bugs.python.org  Mon Mar 30 00:02:50 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Mar 2015 22:02:50 +0000
Subject: [issue14260] re.groupindex is available for modification and
 continues to work, having incorrect data inside it
In-Reply-To: <1331530103.22.0.0779581075646.issue14260@psf.upfronthosting.co.za>
Message-ID: <20150329220247.26456.32767@psf.io>


Roundup Robot added the comment:

New changeset 4d5826fa77a1 by Serhiy Storchaka in branch 'default':
Issue #14260: The groupindex attribute of regular expression pattern object
https://hg.python.org/cpython/rev/4d5826fa77a1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14260>
_______________________________________

From report at bugs.python.org  Mon Mar 30 00:31:22 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Mar 2015 22:31:22 +0000
Subject: [issue22390] test.regrtest should complain if a test doesn't remove
 temporary files
In-Reply-To: <1410445852.03.0.724241204359.issue22390@psf.upfronthosting.co.za>
Message-ID: <20150329223119.26440.28183@psf.io>


Roundup Robot added the comment:

New changeset f40984e7ceea by Serhiy Storchaka in branch '2.7':
Issue #22390: test.regrtest now emits a warning if temporary files or
https://hg.python.org/cpython/rev/f40984e7ceea

New changeset 05e6bab4db8f by Serhiy Storchaka in branch '3.4':
Issue #22390: test.regrtest now emits a warning if temporary files or
https://hg.python.org/cpython/rev/05e6bab4db8f

New changeset bed806c9eb4c by Serhiy Storchaka in branch 'default':
Issue #22390: test.regrtest now emits a warning if temporary files or
https://hg.python.org/cpython/rev/bed806c9eb4c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22390>
_______________________________________

From report at bugs.python.org  Mon Mar 30 00:32:02 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Mar 2015 22:32:02 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <20150329223200.7117.64922@psf.io>


Roundup Robot added the comment:

New changeset e93eeadef0c3 by Victor Stinner in branch 'default':
Issue #22117: Use the _PyTime_t API in _datetime.datetime() constructor
https://hg.python.org/cpython/rev/e93eeadef0c3

New changeset b16fc95b66e4 by Victor Stinner in branch 'default':
Issue #22117: Cleanup pytime.c/.h
https://hg.python.org/cpython/rev/b16fc95b66e4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Mon Mar 30 01:07:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Mar 2015 23:07:42 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <20150329230739.117867.72304@psf.io>


Roundup Robot added the comment:

New changeset 626575d756da by Victor Stinner in branch 'default':
Issue #22117: Fix rounding and implement _PyTime_ROUND_FLOOR in:
https://hg.python.org/cpython/rev/626575d756da

New changeset c26b4b85dfc4 by Victor Stinner in branch 'default':
Issue #22117: Fix os.utime(), it now rounds the timestamp towards minus
https://hg.python.org/cpython/rev/c26b4b85dfc4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Mon Mar 30 01:07:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Mar 2015 23:07:42 +0000
Subject: [issue22390] test.regrtest should complain if a test doesn't remove
 temporary files
In-Reply-To: <1410445852.03.0.724241204359.issue22390@psf.upfronthosting.co.za>
Message-ID: <20150329230739.117867.53916@psf.io>


Roundup Robot added the comment:

New changeset 207db4338706 by Victor Stinner in branch '2.7':
Issue #22390: Fix typo in regrtest, support => test_support
https://hg.python.org/cpython/rev/207db4338706

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22390>
_______________________________________

From report at bugs.python.org  Mon Mar 30 01:11:32 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Mar 2015 23:11:32 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <20150329231129.9812.1763@psf.io>


Roundup Robot added the comment:

New changeset 6bae19f4e7b2 by Victor Stinner in branch 'default':
Issue #22117: Fix rounding of fromtimestamp() methods of datetime.datetime and
https://hg.python.org/cpython/rev/6bae19f4e7b2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Mon Mar 30 01:20:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Mar 2015 23:20:07 +0000
Subject: [issue22390] test.regrtest should complain if a test doesn't remove
 temporary files
In-Reply-To: <1410445852.03.0.724241204359.issue22390@psf.upfronthosting.co.za>
Message-ID: <20150329232004.1933.71378@psf.io>


Roundup Robot added the comment:

New changeset fb5c3528d0d7 by Victor Stinner in branch '2.7':
Issue #22390: Fix test_aifc to remove the created file
https://hg.python.org/cpython/rev/fb5c3528d0d7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22390>
_______________________________________

From report at bugs.python.org  Mon Mar 30 01:25:08 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Mar 2015 23:25:08 +0000
Subject: [issue22390] test.regrtest should complain if a test doesn't remove
 temporary files
In-Reply-To: <1410445852.03.0.724241204359.issue22390@psf.upfronthosting.co.za>
Message-ID: <20150329232505.26456.73835@psf.io>


Roundup Robot added the comment:

New changeset c5c31adbefeb by Victor Stinner in branch '2.7':
Issue #22390: Fix test_pdb to remove created bar.pyc file
https://hg.python.org/cpython/rev/c5c31adbefeb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22390>
_______________________________________

From report at bugs.python.org  Mon Mar 30 01:36:27 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Mar 2015 23:36:27 +0000
Subject: [issue22390] test.regrtest should complain if a test doesn't remove
 temporary files
In-Reply-To: <1410445852.03.0.724241204359.issue22390@psf.upfronthosting.co.za>
Message-ID: <20150329233624.122173.46727@psf.io>


Roundup Robot added the comment:

New changeset 33e48141d83f by Victor Stinner in branch '2.7':
Issue #22390: Fix test_gzip, remove temporary file
https://hg.python.org/cpython/rev/33e48141d83f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22390>
_______________________________________

From report at bugs.python.org  Mon Mar 30 01:47:50 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 Mar 2015 23:47:50 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <1427672870.6.0.926124371986.issue23792@psf.upfronthosting.co.za>


Martin Panter added the comment:

I don?t think SIGQUIT handling is a big problem. But even with the new change, it is still easy to screw up the terminal in many cases, so I wouldn?t say this is fixed yet. Steps for Python 3 in a small 80 ? 25 terminal on Linux:

* import _pyio; help(_pyio)
* Hit Ctrl-C

Steps for Python 2:

* import _pyio; help(_pyio)
* Hit Ctrl-C
* Hit Space ten times to scroll down. Alternatively, hit Ctrl-C a second time.

I am posting a quick patch which I think should fix this in Python 3 by deferring the traceback until after the child has finished. Another method is using the signal module like <https://github.com/vadmium/pacman-tools/blob/9ffdd88/roopwn#L976>, but that?s probably too platform-specific for the pydoc module.

----------
Added file: http://bugs.python.org/file38730/interrupt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Mon Mar 30 02:04:14 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 00:04:14 +0000
Subject: [issue22390] test.regrtest should complain if a test doesn't remove
 temporary files
In-Reply-To: <20150329233624.122173.46727@psf.io>
Message-ID: <CAMpsgwZOhKSME-_YSQFLzQ24BfRdtap4GT7jGXmSoB-06jXRyg@mail.gmail.com>


STINNER Victor added the comment:

On Windows, test_idle modifies os.environ: TCL_xxx and TIX_xxx (sorry
for "xxx", I don't remember the full variable name) are added. And
test_platform modifies os.environ['PATH'].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22390>
_______________________________________

From report at bugs.python.org  Mon Mar 30 02:15:59 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Mar 2015 00:15:59 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <1427674559.52.0.118467493947.issue23792@psf.upfronthosting.co.za>


R. David Murray added the comment:

Here is a version that keeps things clean by not diplaying the traceback.  The ctl-c does have an effect, but not a visible one unless one pays careful attention :)

----------
Added file: http://bugs.python.org/file38731/catch_additional_interrupt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Mon Mar 30 02:21:08 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 00:21:08 +0000
Subject: [issue23694] PEP 475: handle EINTR in fileutils.c
In-Reply-To: <1426634378.41.0.681041892498.issue23694@psf.upfronthosting.co.za>
Message-ID: <20150330002057.26456.72518@psf.io>


Roundup Robot added the comment:

New changeset 2e1234208bab by Victor Stinner in branch 'default':
Issue #23694: Fix usage of _Py_open() in the _posixsubprocess module
https://hg.python.org/cpython/rev/2e1234208bab

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23694>
_______________________________________

From report at bugs.python.org  Mon Mar 30 02:21:08 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 00:21:08 +0000
Subject: [issue22390] test.regrtest should complain if a test doesn't remove
 temporary files
In-Reply-To: <1410445852.03.0.724241204359.issue22390@psf.upfronthosting.co.za>
Message-ID: <20150330002057.26456.26403@psf.io>


Roundup Robot added the comment:

New changeset 6ef2cacec2e9 by Victor Stinner in branch '2.7':
Issue #22390: Fix test_gzip if unicode filename doesn't work
https://hg.python.org/cpython/rev/6ef2cacec2e9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22390>
_______________________________________

From report at bugs.python.org  Mon Mar 30 02:28:40 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 00:28:40 +0000
Subject: [issue23771] Timeouts on "x86 Ubuntu Shared 3.x" buildbot
In-Reply-To: <1427251322.87.0.815245923642.issue23771@psf.upfronthosting.co.za>
Message-ID: <1427675320.8.0.880171073148.issue23771@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> This build was only triggered by one changeset 0b99d7043a99: "Issue #23694: Enhance _Py_open(), it now raises exceptions".

I was reproduce to issue on a buildbot and I got access to the buildbot. Using gdb, I saw that a process was stuck in _close_open_fds_safe(). The problem is that this function is called after fork() to run a child process. It's not safe to play with the GIL here.

This bug is the regression which makes some buildbots to hang.

I fixed the bug in the changeset 2e1234208bab.

I keep the issue open a few days to check if buildbots are repaired or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23771>
_______________________________________

From report at bugs.python.org  Mon Mar 30 02:34:50 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 30 Mar 2015 00:34:50 +0000
Subject: [issue19023] ctypes docs: Unimplemented and undocumented features
In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>
Message-ID: <1427675690.09.0.891139630141.issue19023@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
components:  -Tests
nosy: +berker.peksag
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19023>
_______________________________________

From report at bugs.python.org  Mon Mar 30 02:36:46 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 30 Mar 2015 00:36:46 +0000
Subject: [issue23758] Improve documenation about num_params in sqlite3
 create_function and create_aggregate
In-Reply-To: <1427190295.06.0.0583773654336.issue23758@psf.upfronthosting.co.za>
Message-ID: <1427675806.78.0.7647118847.issue23758@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag, ghaering
stage:  -> patch review
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23758>
_______________________________________

From report at bugs.python.org  Mon Mar 30 02:54:42 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 30 Mar 2015 00:54:42 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <1427676882.95.0.516529266769.issue23792@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think your patch should be fine for all practical cases I can think of.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Mon Mar 30 02:55:52 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 00:55:52 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <20150330005549.27960.53232@psf.io>


Roundup Robot added the comment:

New changeset d938533b43f7 by Victor Stinner in branch 'default':
Issue #22117: Fix usage of _PyTime_AsTimeval()
https://hg.python.org/cpython/rev/d938533b43f7

New changeset 49d3ff81f31f by Victor Stinner in branch 'default':
Issue #22117: Add assertions to _PyTime_AsTimeval() and _PyTime_AsTimespec() to
https://hg.python.org/cpython/rev/49d3ff81f31f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:00:31 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Mar 2015 01:00:31 +0000
Subject: [issue23809] RFE: emit a warning when a module in a traceback shadows
 a stdlib module
Message-ID: <1427677231.57.0.397201302545.issue23809@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

A colleague just ran into the issue where they created a "json.py" module in their local directory and broke a previously working program. I picked up on the mistake when I saw the following traceback snippet:

    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/lib/python2.7/site-packages/praw/__init__.py", line 27, in <module>
        import json
      File "json.py", line 1, in <module>
        r = requests.get("http://www.reddit.com/user/spilcm/about/.json")

However, actually making the connection required thinking "Wait, why is the stdlib JSON module calling out to Reddit?" followed immediately by "Oh, that's not the stdlib json module".

That connection would potentially be easier for new Python users to make if there was an inline notification printed after the traceback warning of the stdlib module shadowing. If nothing else, it would give them something specific to search for to lead them to a discussion of name shadowing and the problems that can arise when you name one of your local modules the same as a standard library module.

Offering such a feature would necessarily rely on having a standard way of getting a programmatic list of the standard library modules available to the running interpreter version without actually loading them all, a question which is discussed further in https://stackoverflow.com/questions/6463918/how-can-i-get-a-list-of-all-the-python-standard-library-modules and https://github.com/jackmaney/python-stdlib-list

Since the contents of the standard library for a given release is immutable, and we'd like to keep any such mechanism (if we decide to provide it) very simple so we can easily access it from the low level interpreter traceback machinery, my suggestion would be along the lines of:

1. Update the interpreter build process to emit a flat text file containing a complete list of fully qualified stdlib module names (including submodules), one name per line (this will be generated at build time, so it *won't* contain filenames, just the module names - however, it could theoretically be combined with importlib.util.find_spec to generate a PEP 376 style RECORD file for the non-builtin parts of the standard library at installation time)
2. Rather than exposing the underlying machinery to end users directly, instead expose a function in sysconfig to read that list of modules into memory via a read-only line based iterator. (There may be an internal API to allow access to the content without going through sysconfig)
3. Updating the two main traceback display mechanisms (the builtin traceback display and the traceback module) to check that list for potential conflicts after displaying a traceback

(This idea could benefit from discussion on python-ideas and potentially even escalate into a full PEP, but I don't currently have the personal bandwidth available to pursue that course. Accordingly, I'm just filing the idea here in case someone else finds it intriguing and has more time available to pursue it)

----------
messages: 239543
nosy: georg.brandl, larry, ncoghlan, rbcollins
priority: normal
severity: normal
status: open
title: RFE: emit a warning when a module in a traceback shadows a stdlib module
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23809>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:03:37 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 30 Mar 2015 01:03:37 +0000
Subject: [issue23809] RFE: emit a warning when a module in a traceback shadows
 a stdlib module
In-Reply-To: <1427677231.57.0.397201302545.issue23809@psf.upfronthosting.co.za>
Message-ID: <1427677417.63.0.21183410097.issue23809@psf.upfronthosting.co.za>


Robert Collins added the comment:

Why limit this to just stdlib shadowing?

A local module can shadow a top level module-or-package across the board. If we don't limit it to stdlib names, it becomes a lot easier to implement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23809>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:07:17 2015
From: report at bugs.python.org (Robert Collins)
Date: Mon, 30 Mar 2015 01:07:17 +0000
Subject: [issue23809] RFE: emit a warning when a module in a traceback shadows
 a stdlib module
In-Reply-To: <1427677231.57.0.397201302545.issue23809@psf.upfronthosting.co.za>
Message-ID: <1427677637.91.0.0903752847962.issue23809@psf.upfronthosting.co.za>


Robert Collins added the comment:

Implementation wise: this is not part of the generic rendering-of-tracebacks; I'd like to make the traceback new stuff be tastefully extensible - I'd be inclined to do this with a per-frame-callback on render (so we don't pay overhead on unrendered tb's) and a global variable that controls the default hooks loaded into the objects.

That would:
 - allow folk using the raw API to control what hooks are at play
 - allow third-parties to install additional things globally, to influence code using the existing old tb apis
 - make testing of the warning specific code be very straight forward and isolated

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23809>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:14:59 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Mar 2015 01:14:59 +0000
Subject: [issue23809] RFE: emit a warning when a module in a traceback shadows
 a stdlib module
In-Reply-To: <1427677231.57.0.397201302545.issue23809@psf.upfronthosting.co.za>
Message-ID: <1427678099.46.0.23014351688.issue23809@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I proposed limiting it to stdlib names as that's the case where we see the most beginner confusion (experimenting with sockets in a file named "socket.py", etc), and the one where we can generate a comprehensive list of known module names ahead of time (so in most cases we won't need to touch the filesystem to determine there's no shadowing happening once the list of stdlib modules has been pulled in to memory).

Handling the general case means we have to instead rely on rescanning the import system at runtime. On the other hand, we're already doing something along those lines through linecache to handle retrieving source lines, and the import system itself already has caches everywhere (hence importlib.invalidate_caches()), so adding yet-another-cache to be able to check for module shadowing efficiently wouldn't be that big a deal.

Adding Brett & Eric to get some additional perspectives on the idea of doing checks for name shadowing through a new importlib.util API rather than a separate stdlib specific mechanism.

----------
nosy: +brett.cannon, eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23809>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:16:14 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Mar 2015 01:16:14 +0000
Subject: [issue23809] RFE: emit a warning when a module in a traceback shadows
 a stdlib module
In-Reply-To: <1427677231.57.0.397201302545.issue23809@psf.upfronthosting.co.za>
Message-ID: <1427678174.42.0.499759645469.issue23809@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

On the implementation front, +1 for looking at a per-frame callback API rather than hardcoding this directly into the existing traceback rendering code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23809>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:17:07 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 01:17:07 +0000
Subject: [issue23770] Rework how exceptions are handled in the parser module
 (in validate_repeating_list())
In-Reply-To: <1427243360.96.0.274103044553.issue23770@psf.upfronthosting.co.za>
Message-ID: <1427678227.18.0.774272370582.issue23770@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Rework of exceptions are handled in the parser module (in validate_repeating_list()) -> Rework how exceptions are handled in the parser module (in validate_repeating_list())

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23770>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:22:53 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 01:22:53 +0000
Subject: [issue23752] Cleanup io.FileIO
In-Reply-To: <1427129465.77.0.24572480634.issue23752@psf.upfronthosting.co.za>
Message-ID: <20150330012250.1933.48706@psf.io>


Roundup Robot added the comment:

New changeset bc2a22eaa0af by Victor Stinner in branch 'default':
Issue #23752: When built from an existing file descriptor, io.FileIO() now only
https://hg.python.org/cpython/rev/bc2a22eaa0af

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23752>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:23:26 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 01:23:26 +0000
Subject: [issue23752] Cleanup io.FileIO
In-Reply-To: <1427129465.77.0.24572480634.issue23752@psf.upfronthosting.co.za>
Message-ID: <1427678606.5.0.749618918314.issue23752@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23752>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:23:56 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 30 Mar 2015 01:23:56 +0000
Subject: [issue23809] RFE: emit a warning when a module in a traceback shadows
 a stdlib module
In-Reply-To: <1427677231.57.0.397201302545.issue23809@psf.upfronthosting.co.za>
Message-ID: <1427678636.09.0.796087584671.issue23809@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I had an idea for a possible importlib.util API to support this capability: an "ignore_entries=0" default arg to https://docs.python.org/dev/library/importlib.html#importlib.util.find_spec

The new arg would say how many found entries to skip when looking for the module, defaulting to returning the first hit as it does now.

The challenging part would be that all the implicit import system caching is currently built around the notion of "there can be only one", so we'd likely want to introduce something like a new name shadowing cache that mapped "(modname, ignored_entries)" pairs to module specs (and was cleared by importlib.invalidate_caches() along with everything else).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23809>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:25:07 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 01:25:07 +0000
Subject: [issue23754] Add a new os.read_into() function to avoid memory copies
In-Reply-To: <1427145371.9.0.485193711036.issue23754@psf.upfronthosting.co.za>
Message-ID: <1427678707.69.0.853726239814.issue23754@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Why do you want to optimize the pure Python FileIO?

I gave more examples than FileIO in this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23754>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:30:55 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 01:30:55 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1427679055.28.0.0491805586777.issue23571@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> That last commit fixed compatibility with Django.

Good.

> Instead of an assert(), you could use Py_FatalError() at the end of _Py_CheckFunctionResult().

_Py_CheckFunctionResult() now calls Py_FatalError() in debug mode. By the way, I fixed various issues in Py_FatalError() to be able to display the exception and the traceback in more cases.

@Serhiy: Are you ok with that?

Can I close the issue?

FYI I write the PEP 490 as a "spin off" of this issue, to continue my work on the enhancement of exceptions in the C code: "PEP 490 - Chain exceptions at C level".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:38:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 01:38:17 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <1427679497.21.0.646203929755.issue22117@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I rewrite the implementation of this issue 2 or 3 times. At the end, I decided to rewrite it again with a more incremental approach: add the new API, use the new API, and then drop slowly the old API.

I was used to rewrite the implementation multiple times to fix issues in the API and enhance the implementation. The new API now handles better rounding with more unit tests.

The datetime module only uses the new API for the datetime.datetime() constructor. It's not used for datetime.datetime.fromtimestamp(), because _PyTime_t is limited to a range of [-292 years; 292 years]. The datetime module supports a much large range: year in range [1; 9999]. So some parts of the old API will survive for the datetime module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:51:52 2015
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 30 Mar 2015 01:51:52 +0000
Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting
 of integers
In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za>
Message-ID: <1427680312.42.0.524029719685.issue23466@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Patch looks good.

Changing the raised exceptions to ValueError  would require deprecation periods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23466>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:54:14 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 30 Mar 2015 01:54:14 +0000
Subject: [issue23810] Suboptimal stacklevel of deprecation warnings for
 formatter and imp modules
Message-ID: <1427680454.72.0.13356883084.issue23810@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

https://hg.python.org/cpython/rev/2a336cc29282 changed stacklevel of some deprecation warnings.
However new value is still not useful, because either _frozen_importlib or importlib/_bootstrap.py is now mentioned in deprecation warnings:

$ cat test.py
import formatter
import imp
$ python3.4 -Wd test.py
/usr/lib64/python3.4/formatter.py:24: PendingDeprecationWarning: the formatter module is deprecated and will be removed in Python 3.6
  'Python 3.6', PendingDeprecationWarning)
/usr/lib64/python3.4/imp.py:32: PendingDeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  PendingDeprecationWarning)
$ python3.5 -Wd test.py
_frozen_importlib:321: DeprecationWarning: the formatter module is deprecated and will be removed in Python 3.6
/usr/lib64/python3.5/importlib/_bootstrap.py:321: PendingDeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
  return f(*args, **kwds)

----------
assignee: brett.cannon
components: Library (Lib)
messages: 239554
nosy: Arfrever, brett.cannon
priority: normal
severity: normal
status: open
title: Suboptimal stacklevel of deprecation warnings for formatter and imp modules
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23810>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:54:50 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 01:54:50 +0000
Subject: [issue23745] Exception when parsing an email using
 email.parser.BytesParser
In-Reply-To: <1427096623.21.0.20064628085.issue23745@psf.upfronthosting.co.za>
Message-ID: <20150330015447.7101.70524@psf.io>


Roundup Robot added the comment:

New changeset dc10c52c6539 by R David Murray in branch '3.4':
#23745: handle duplicate MIME parameter names in new parser.
https://hg.python.org/cpython/rev/dc10c52c6539

New changeset fe9a578d5f38 by R David Murray in branch 'default':
Merge: #23745: handle duplicate MIME parameter names in new parser.
https://hg.python.org/cpython/rev/fe9a578d5f38

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23745>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:55:12 2015
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 30 Mar 2015 01:55:12 +0000
Subject: [issue21076] Turn signal.SIG* constants into enums
In-Reply-To: <1395935330.94.0.38028035584.issue21076@psf.upfronthosting.co.za>
Message-ID: <1427680512.69.0.466316707061.issue21076@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Okay, in a perfect world that _enum_to_int function would be unnecessary, but as Serhiy pointed out the C code is doing pointer comparison, so unless the exact same int is passed in it does not work.

I'm looking at adjusting the C code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21076>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:57:00 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Mar 2015 01:57:00 +0000
Subject: [issue23745] Exception when parsing an email using
 email.parser.BytesParser
In-Reply-To: <1427096623.21.0.20064628085.issue23745@psf.upfronthosting.co.za>
Message-ID: <1427680620.49.0.433367058843.issue23745@psf.upfronthosting.co.za>


R. David Murray added the comment:

The issue arose from the duplicated parameter name.  I fixed it by (mostly) copying the error recovery used by the older api (get_param).

Note that you don't need to specify both policy and _class.  If you use the new policies (such as default), it automatically uses EmailMessage for the _class.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23745>
_______________________________________

From report at bugs.python.org  Mon Mar 30 03:59:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 01:59:24 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <20150330015921.23144.45274@psf.io>


Roundup Robot added the comment:

New changeset f6b41566ca28 by Victor Stinner in branch 'default':
Issue #22117: Add _PyTime_ROUND_CEILING rounding method for timestamps
https://hg.python.org/cpython/rev/f6b41566ca28

New changeset 0a8015a4ff97 by Victor Stinner in branch 'default':
Issue #22117: Replace usage of _PyTime_ROUND_UP with _PyTime_ROUND_CEILING
https://hg.python.org/cpython/rev/0a8015a4ff97

New changeset 350eb1ca561a by Victor Stinner in branch 'default':
Issue #22117: Remove _PyTime_ROUND_DOWN and _PyTime_ROUND_UP rounding methods
https://hg.python.org/cpython/rev/350eb1ca561a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Mon Mar 30 04:07:49 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 02:07:49 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <1427681269.1.0.691006706011.issue22117@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ok, I'm quite API with the new API and I have what I need to rework the select module for the PEP 475, so I close this issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Mon Mar 30 04:13:34 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 02:13:34 +0000
Subject: [issue23485] PEP 475: handle EINTR in the select and selectors module
In-Reply-To: <1424352775.64.0.420442648443.issue23485@psf.upfronthosting.co.za>
Message-ID: <1427681614.73.0.414699000974.issue23485@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ok, here is a first patch just for select.select().

It took me some time to write this small patch, because I wanted first to push my new API to handle time in pytime.h (Issue #22117). The new time C API has been merged.

----------
keywords: +patch
Added file: http://bugs.python.org/file38732/select_eintr.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23485>
_______________________________________

From report at bugs.python.org  Mon Mar 30 04:14:06 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 02:14:06 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect)
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <1427681646.12.0.614124782268.issue23618@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: PEP 475: handle EINTR in the socket module -> PEP 475: handle EINTR in the socket module (connect)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Mon Mar 30 04:22:24 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 02:22:24 +0000
Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting
 of integers
In-Reply-To: <1427680312.42.0.524029719685.issue23466@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbZUNsRgb9ECbrHy0aZxLiEmOEM2y6ecXQSKz+33kG_DA@mail.gmail.com>


STINNER Victor added the comment:

> Changing the raised exceptions to ValueError  would require deprecation
periods.

bytes%args is not a new feature of python 3.5? It sounds strange to
deprecate a part of a new feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23466>
_______________________________________

From report at bugs.python.org  Mon Mar 30 04:54:04 2015
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 Mar 2015 02:54:04 +0000
Subject: [issue23804] SSLSocket.recv(0) receives up to 1024 bytes
In-Reply-To: <1427625023.61.0.148010223441.issue23804@psf.upfronthosting.co.za>
Message-ID: <1427684044.95.0.155483944525.issue23804@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +alex, christian.heimes, dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23804>
_______________________________________

From report at bugs.python.org  Mon Mar 30 05:02:15 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 30 Mar 2015 03:02:15 +0000
Subject: [issue23529] Limit decompressed data when reading from LZMAFile and
 BZ2File
In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za>
Message-ID: <1427684535.49.0.251144691657.issue23529@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch v9:

* Incorporated _PaddedFile.rewind() into seek() for simplicity
* Reverted to support fast-forwarding in non-seekable streams again
* Factored common checks into _check_can_seek()
* Documented ?mtime? attribute and implemented it as a read-only decompression-only property

Antoine highlighted the fact that BufferedReader.peek() does not guarantee how much data it returns, so I removed the code trying to return at least 100 bytes.

I revisited merging the gzip read() loop with the others, but gave up again. I tried adding calls to _start_member() and _end_member(), with more ?if? statements and flags to account for the different edge cases. But then I remembered the ?needs_input? flag of LZMA and bzip versus the ?unconsumed_tail? of zlib. Handling this would probably require another delegation to a new _decompress_chunk() method, at which point I think the whole read() method will probably just be a mess of hacks trying to marry the two not-quite-compatible implementations. So I think it is better to override read() with a gzip-specific implementation, unless someone wants to prove me wrong with their own patch :)

----------
Added file: http://bugs.python.org/file38733/LZMAFile-etc.v9.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23529>
_______________________________________

From report at bugs.python.org  Mon Mar 30 05:13:13 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Mar 2015 03:13:13 +0000
Subject: [issue23793] Support __add__, __mul__, and __imul__ for deques.
In-Reply-To: <1427477638.63.0.2394294758.issue23793@psf.upfronthosting.co.za>
Message-ID: <1427685193.08.0.462142855275.issue23793@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Also incorporate __mul__ and __imul__.

    >>> d = deque('abc')
    >>> d * 3
    deque(['a', 'b', 'c', 'a', 'b', 'c', 'a', 'b', 'c'])
    >>> d *= 2
    >>> d
    deque(['a', 'b', 'c', 'a', 'b', 'c'])

----------
keywords: +needs review -patch
title: Support __add__ for deques. -> Support __add__, __mul__, and __imul__ for deques.
Added file: http://bugs.python.org/file38734/deque_mul_and_add.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23793>
_______________________________________

From report at bugs.python.org  Mon Mar 30 06:01:09 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 30 Mar 2015 04:01:09 +0000
Subject: [issue23729] Import ElementTree documentation for namespaces and XPath
In-Reply-To: <1426926572.78.0.5131365949.issue23729@psf.upfronthosting.co.za>
Message-ID: <1427688069.22.0.830018881083.issue23729@psf.upfronthosting.co.za>


Martin Panter added the comment:

Reopening because I think there are some review comments that need addressing, at least the fromstring() one. I?m happy to make a patch if necessary.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23729>
_______________________________________

From report at bugs.python.org  Mon Mar 30 06:21:10 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 30 Mar 2015 04:21:10 +0000
Subject: [issue23755] tempfile.NamedTemporaryFile should be able to toggle
 "delete"
In-Reply-To: <1427158506.1.0.856842662258.issue23755@psf.upfronthosting.co.za>
Message-ID: <1427689270.56.0.603607572579.issue23755@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think I have often passed delete=False because of the documented deficiency with Windows (see Issue 14243). Depending on the outcome of that issue, allowing for deletion after close() might be useful too.

BTW, monkey-patching __del__() probably won?t work if you only set an attribute on the ?f? instance, instead of modifying the class itself. See <file:///home/proj/python/cpython/Doc/build/html/reference/datamodel.html#special-method-lookup>.

----------
nosy: +vadmium
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23755>
_______________________________________

From report at bugs.python.org  Mon Mar 30 07:00:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 05:00:31 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <1427691631.48.0.997460307774.issue22117@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be rename _PyTime_AsTimeval_impl() to _PyTime_AsTimeval_noraise() and check a result to raise an exception in _PyTime_AsTimeval()?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Mon Mar 30 07:43:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 05:43:22 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za>
Message-ID: <1427694202.73.0.71537342366.issue23571@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The second (exception == NULL) check in _Py_PrintFatalError() looks suspicious. When it is possible? And if it is possible, can it cause leaks?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Mon Mar 30 08:17:02 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 06:17:02 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1427691631.48.0.997460307774.issue22117@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb38NtO=o2=7at_wcwdqAVU-uUYKXeGKWtVqp-WN6f4Xg@mail.gmail.com>


STINNER Victor added the comment:

>
> Serhiy Storchaka added the comment:
>
> May be rename _PyTime_AsTimeval_impl() to _PyTime_AsTimeval_noraise() and
> check a result to raise an exception in _PyTime_AsTimeval()?
>

Ah yes correct, can you modify directly the code please?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Mon Mar 30 08:22:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 06:22:04 +0000
Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting
 of integers
In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za>
Message-ID: <20150330062201.122171.47095@psf.io>


Roundup Robot added the comment:

New changeset cb96fd376baa by Serhiy Storchaka in branch 'default':
Issue #23466: %c, %o, %x, and %X in bytes formatting now raise TypeError on
https://hg.python.org/cpython/rev/cb96fd376baa

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23466>
_______________________________________

From report at bugs.python.org  Mon Mar 30 08:22:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 06:22:04 +0000
Subject: [issue23171] csv.writer.writerow() does not accept generator (must be
 coerced to list)
In-Reply-To: <1420479102.66.0.846752030326.issue23171@psf.upfronthosting.co.za>
Message-ID: <20150330062201.122171.71752@psf.io>


Roundup Robot added the comment:

New changeset cf5b62036445 by Serhiy Storchaka in branch 'default':
Issue #23171: csv.Writer.writerow() now supports arbitrary iterables.
https://hg.python.org/cpython/rev/cf5b62036445

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23171>
_______________________________________

From report at bugs.python.org  Mon Mar 30 08:28:10 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 06:28:10 +0000
Subject: [issue14904] test_unicode_repr_oflw (in test_bigmem) crashes
In-Reply-To: <1337903212.58.0.439916347295.issue14904@psf.upfronthosting.co.za>
Message-ID: <20150330062807.7121.51050@psf.io>


Roundup Robot added the comment:

New changeset 5bea08f80e62 by Serhiy Storchaka in branch '2.7':
Issue #14904: Made test_unicode_repr_oflw to use less memory.
https://hg.python.org/cpython/rev/5bea08f80e62

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14904>
_______________________________________

From report at bugs.python.org  Mon Mar 30 09:01:47 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 07:01:47 +0000
Subject: [issue23783] Leak in PyObject_ClearWeakRefs
In-Reply-To: <1427366216.42.0.852268629074.issue23783@psf.upfronthosting.co.za>
Message-ID: <20150330070140.122169.37246@psf.io>


Roundup Robot added the comment:

New changeset 74d766d819a6 by Serhiy Storchaka in branch '3.4':
Issue #23783: Fixed memory leak in PyObject_ClearWeakRefs() in case of
https://hg.python.org/cpython/rev/74d766d819a6

New changeset 6a4b83c56b86 by Serhiy Storchaka in branch 'default':
Issue #23783: Fixed memory leak in PyObject_ClearWeakRefs() in case of
https://hg.python.org/cpython/rev/6a4b83c56b86

New changeset a8d8d16c853e by Serhiy Storchaka in branch '2.7':
Issue #23783: Fixed memory leak in PyObject_ClearWeakRefs() in case of
https://hg.python.org/cpython/rev/a8d8d16c853e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23783>
_______________________________________

From report at bugs.python.org  Mon Mar 30 09:01:47 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 07:01:47 +0000
Subject: [issue23785] Leak in TextIOWrapper.tell()
In-Reply-To: <1427375081.85.0.443670344357.issue23785@psf.upfronthosting.co.za>
Message-ID: <20150330070140.122169.97949@psf.io>


Roundup Robot added the comment:

New changeset 442ebebad516 by Serhiy Storchaka in branch '3.4':
Issue #23785: Fixed memory leak in TextIOWrapper.tell() in rare circumstances.
https://hg.python.org/cpython/rev/442ebebad516

New changeset 2fcd99929dba by Serhiy Storchaka in branch 'default':
Issue #23785: Fixed memory leak in TextIOWrapper.tell() in rare circumstances.
https://hg.python.org/cpython/rev/2fcd99929dba

New changeset 12d3eec72f9e by Serhiy Storchaka in branch '2.7':
Issue #23785: Fixed memory leak in TextIOWrapper.tell() in rare circumstances.
https://hg.python.org/cpython/rev/12d3eec72f9e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23785>
_______________________________________

From report at bugs.python.org  Mon Mar 30 09:01:49 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 07:01:49 +0000
Subject: [issue23781] Add private _PyErr_ReplaceException() in 2.7
In-Reply-To: <1427363388.22.0.986381006689.issue23781@psf.upfronthosting.co.za>
Message-ID: <20150330070140.122169.14674@psf.io>


Roundup Robot added the comment:

New changeset c76a1a42799c by Serhiy Storchaka in branch '2.7':
Issue #23781: Add private helper function _PyErr_ReplaceException() that
https://hg.python.org/cpython/rev/c76a1a42799c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23781>
_______________________________________

From report at bugs.python.org  Mon Mar 30 09:02:35 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 07:02:35 +0000
Subject: [issue23785] Leak in TextIOWrapper.tell()
In-Reply-To: <1427375081.85.0.443670344357.issue23785@psf.upfronthosting.co.za>
Message-ID: <1427698955.99.0.237696085858.issue23785@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23785>
_______________________________________

From report at bugs.python.org  Mon Mar 30 09:03:37 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 07:03:37 +0000
Subject: [issue23783] Leak in PyObject_ClearWeakRefs
In-Reply-To: <1427366216.42.0.852268629074.issue23783@psf.upfronthosting.co.za>
Message-ID: <1427699017.48.0.380896497644.issue23783@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23783>
_______________________________________

From report at bugs.python.org  Mon Mar 30 09:04:19 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 07:04:19 +0000
Subject: [issue23781] Add private _PyErr_ReplaceException() in 2.7
In-Reply-To: <1427363388.22.0.986381006689.issue23781@psf.upfronthosting.co.za>
Message-ID: <1427699059.74.0.972064418128.issue23781@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23781>
_______________________________________

From report at bugs.python.org  Mon Mar 30 09:05:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 07:05:09 +0000
Subject: [issue22079] Ensure in PyType_Ready() that base class of static type
 is static
In-Reply-To: <1406378199.04.0.952325428414.issue22079@psf.upfronthosting.co.za>
Message-ID: <1427699109.44.0.975164030268.issue22079@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22079>
_______________________________________

From report at bugs.python.org  Mon Mar 30 09:06:37 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 07:06:37 +0000
Subject: [issue23799] Join started threads in tests
In-Reply-To: <1427573430.36.0.605750682641.issue23799@psf.upfronthosting.co.za>
Message-ID: <1427699197.78.0.126750269369.issue23799@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +ezio.melotti, haypo, michael.foord, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23799>
_______________________________________

From report at bugs.python.org  Mon Mar 30 09:07:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 07:07:28 +0000
Subject: [issue14904] test_unicode_repr_oflw (in test_bigmem) crashes
In-Reply-To: <1337903212.58.0.439916347295.issue14904@psf.upfronthosting.co.za>
Message-ID: <1427699248.44.0.304053066908.issue14904@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14904>
_______________________________________

From report at bugs.python.org  Mon Mar 30 09:08:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 07:08:36 +0000
Subject: [issue14260] re.groupindex is available for modification and
 continues to work, having incorrect data inside it
In-Reply-To: <1331530103.22.0.0779581075646.issue14260@psf.upfronthosting.co.za>
Message-ID: <1427699316.65.0.777873160531.issue14260@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14260>
_______________________________________

From report at bugs.python.org  Mon Mar 30 09:10:42 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 07:10:42 +0000
Subject: [issue22390] test.regrtest should complain if a test doesn't remove
 temporary files
In-Reply-To: <1410445852.03.0.724241204359.issue22390@psf.upfronthosting.co.za>
Message-ID: <1427699442.01.0.973390195774.issue22390@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for fixing backported patch and tests Victor.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22390>
_______________________________________

From report at bugs.python.org  Mon Mar 30 09:11:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 07:11:02 +0000
Subject: [issue23171] csv.writer.writerow() does not accept generator (must be
 coerced to list)
In-Reply-To: <1420479102.66.0.846752030326.issue23171@psf.upfronthosting.co.za>
Message-ID: <1427699462.97.0.986020686836.issue23171@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23171>
_______________________________________

From report at bugs.python.org  Mon Mar 30 09:18:58 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 07:18:58 +0000
Subject: [issue23500] Argument Clinic: multiple macro definition
In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za>
Message-ID: <1427699938.48.0.611932880551.issue23500@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please commit your patch (may be with changes) Larry?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23500>
_______________________________________

From report at bugs.python.org  Mon Mar 30 10:19:58 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 08:19:58 +0000
Subject: [issue23752] Cleanup io.FileIO
In-Reply-To: <1427129465.77.0.24572480634.issue23752@psf.upfronthosting.co.za>
Message-ID: <1427703598.96.0.319688241975.issue23752@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hum, _Py_fstat() is not used correctly in _io.FilIO: it uses errno instead of GetLastError() to raise the OSError. It's too hard to use the new _Py_fstat() function directly, I modified it to raise directly the exception. So the caller doesn't have to use #ifdef MS_WINDOWS to raise the exception correctly.

I added _Py_fstat_noraise() when it's not possible to use an exception.

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/5978/steps/test/logs/stdio

======================================================================
FAIL: test_fdopen (test.test_os.TestInvalidFD)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_os.py", line 1418, in check
    f(support.make_bad_fd(), *args)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\os.py", line 1028, in fdopen
    return io.open(fd, *args, **kwargs)
OSError: [Errno 0] Error

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\test\test_os.py", line 1411, in helper
    self.check(getattr(os, f))
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_os.py", line 1420, in check
    self.assertEqual(e.errno, errno.EBADF)
AssertionError: 0 != 9

----------
nosy: +holdenweb
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23752>
_______________________________________

From report at bugs.python.org  Mon Mar 30 10:20:08 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 08:20:08 +0000
Subject: [issue23752] Cleanup io.FileIO
In-Reply-To: <1427129465.77.0.24572480634.issue23752@psf.upfronthosting.co.za>
Message-ID: <20150330082005.1927.87411@psf.io>


Roundup Robot added the comment:

New changeset 128f92ae8bae by Victor Stinner in branch 'default':
Issue #23752: _Py_fstat() is now responsible to raise the Python exception
https://hg.python.org/cpython/rev/128f92ae8bae

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23752>
_______________________________________

From report at bugs.python.org  Mon Mar 30 10:21:46 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 08:21:46 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <1427703706.15.0.4795634728.issue22117@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hum, conversion from Python float to _PyTime_t is not rounded as expected on x86 Ubuntu Shared 3.x. Example:

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/11426/steps/test/logs/stdio

======================================================================
FAIL: test_FromSecondsObject (test.test_time.TestPyTime_t) (obj=1e-06, round=<_PyTime.ROUND_FLOOR: 0>, timestamp=1000)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_time.py", line 779, in test_FromSecondsObject
    self.assertEqual(PyTime_FromSecondsObject(obj, rnd), ts)
AssertionError: 999 != 1000

======================================================================
FAIL: test_FromSecondsObject (test.test_time.TestPyTime_t) (obj=4194304.000000001, round=<_PyTime.ROUND_FLOOR: 0>, timestamp=4194304000000001)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_time.py", line 779, in test_FromSecondsObject
    self.assertEqual(PyTime_FromSecondsObject(obj, rnd), ts)
AssertionError: 4194304000000000 != 4194304000000001

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Mon Mar 30 10:22:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 08:22:24 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <20150330082222.7111.90110@psf.io>


Roundup Robot added the comment:

New changeset e00b581a65ec by Victor Stinner in branch 'default':
Issue #22117: Try to fix rounding in conversion from Python double to _PyTime_t
https://hg.python.org/cpython/rev/e00b581a65ec

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Mon Mar 30 10:38:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 08:38:51 +0000
Subject: [issue23571] Raise SystemError if a function returns a result with an
 exception set
In-Reply-To: <1427694202.73.0.71537342366.issue23571@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwasg7owAg1gaqM3Vf5gEXAgsO0CZJ+Mr7R55hxFj3HUkg@mail.gmail.com>


STINNER Victor added the comment:

Serhiy Storchaka added the comment:
> The second (exception == NULL) check in _Py_PrintFatalError() looks suspicious. When it is possible? And if it is possible, can it cause leaks?

Sorry, I have no idea. I didn't write this code myself. It comes from
PyErr_PrintEx():

    PyErr_Fetch(&exception, &v, &tb);
    if (exception == NULL)
        return;
    PyErr_NormalizeException(&exception, &v, &tb);
    if (tb == NULL) {
        tb = Py_None;
        Py_INCREF(tb);
    }
    PyException_SetTraceback(v, tb);
    if (exception == NULL)
        return;

I read again PyErr_NormalizeException(). I'm not sure that the case
can occur in practice. Maybe it can be replaced with an assertion?
Since Py_FatalError() is called in catastrophic cases, I chose to not
try to drop safety checks :-) You can modify PyErr_PrintEx() or even
_Py_PrintFatalError() if you feel more brave than me :-D

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23571>
_______________________________________

From report at bugs.python.org  Mon Mar 30 10:41:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 08:41:08 +0000
Subject: [issue22390] test.regrtest should complain if a test doesn't remove
 temporary files
In-Reply-To: <1427699442.01.0.973390195774.issue22390@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYC6VxiWaAHhDo5qOjM4-xFxM9p1BaxwKQO0qh5poHkvw@mail.gmail.com>


STINNER Victor added the comment:

Serhiy Storchaka added the comment:
> Thank you for fixing backported patch and tests Victor.

No problem, thanks for your enhancement of regrtest ;-) I proposed the
idea and you implemented it, great team work!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22390>
_______________________________________

From report at bugs.python.org  Mon Mar 30 10:48:22 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 08:48:22 +0000
Subject: [issue23799] Join started threads in tests
In-Reply-To: <1427573430.36.0.605750682641.issue23799@psf.upfronthosting.co.za>
Message-ID: <1427705302.21.0.688012243657.issue23799@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> In this case all started threads left dangling and make MemotyError even more probably

Oh, I didn't know that. Good catch.

test_support_start_threads.patch looks good to me and it looks like a nice enhancement.

But would it be possible to emit a warning if a thread hangs?

For example, try to join with a timeout of 60 seconds, and then display a warning, and retry with a timeout of 120 seconds, then display a second warning, etc.

Maybe we may even give up after a timeout (ex: 5 minutes, or 15 minutes, it's up to you). An exception must be raised in this case. You can use faulthandler.dump_traceback() to display the traceback of all threads in this case.

I hope that my concern is more theorical, but it would reduce the duration of tests when the test suite is stuck (which is quite common), and so being able to test more changesets per day.

--

I noticed that under low memory condition, some tests hang because Python doesn't handle notify the "parent thread" that the "child thread" fails to start. So the parent thread is stuck and nothing happens. Well, I'm not sure that it's related to this issue. At least, test_support_start_threads.patch doesn't help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23799>
_______________________________________

From report at bugs.python.org  Mon Mar 30 10:52:21 2015
From: report at bugs.python.org (Michael Foord)
Date: Mon, 30 Mar 2015 08:52:21 +0000
Subject: [issue15836] unittest assertRaises should verify excClass is actually
 a BaseException class
In-Reply-To: <1346459161.18.0.156457463704.issue15836@psf.upfronthosting.co.za>
Message-ID: <1427705541.45.0.423964720152.issue15836@psf.upfronthosting.co.za>


Michael Foord added the comment:

The change to unittest is fine. I'd prefer the tests tweaking as Ezio suggested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15836>
_______________________________________

From report at bugs.python.org  Mon Mar 30 11:20:16 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 09:20:16 +0000
Subject: [issue22181] os.urandom() should use Linux 3.17 getrandom() syscall
In-Reply-To: <1407713563.4.0.264701036097.issue22181@psf.upfronthosting.co.za>
Message-ID: <20150330092012.25931.4822@psf.io>


Roundup Robot added the comment:

New changeset 28b465d8c519 by Victor Stinner in branch 'default':
Issue #22181: os.urandom() now releases the GIL when the getrandom()
https://hg.python.org/cpython/rev/28b465d8c519

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22181>
_______________________________________

From report at bugs.python.org  Mon Mar 30 11:20:16 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 09:20:16 +0000
Subject: [issue22585] os.urandom() should use getentropy() of OpenBSD 5.6
In-Reply-To: <1412846768.8.0.764206346975.issue22585@psf.upfronthosting.co.za>
Message-ID: <20150330092013.25931.58165@psf.io>


Roundup Robot added the comment:

New changeset 9d3013a383eb by Victor Stinner in branch '3.4':
Issue #22585: os.urandom() now releases the GIL when the getentropy() is used
https://hg.python.org/cpython/rev/9d3013a383eb

New changeset 7f1015e4277a by Victor Stinner in branch 'default':
(Merge 3.4) Issue #22585: os.urandom() now releases the GIL when the
https://hg.python.org/cpython/rev/7f1015e4277a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22585>
_______________________________________

From report at bugs.python.org  Mon Mar 30 11:23:03 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 09:23:03 +0000
Subject: [issue23115] Backport #22585 -- getentropy for urandom to Python 2.7
In-Reply-To: <1419610873.69.0.17447907262.issue23115@psf.upfronthosting.co.za>
Message-ID: <20150330092300.27950.35419@psf.io>


Roundup Robot added the comment:

New changeset 05b96af72805 by Victor Stinner in branch '2.7':
Issue #23115: os.urandom() now releases the GIL when the getentropy() is used
https://hg.python.org/cpython/rev/05b96af72805

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23115>
_______________________________________

From report at bugs.python.org  Mon Mar 30 11:41:18 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 09:41:18 +0000
Subject: [issue23752] Cleanup io.FileIO
In-Reply-To: <1427129465.77.0.24572480634.issue23752@psf.upfronthosting.co.za>
Message-ID: <1427708478.04.0.578720004436.issue23752@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The changeset 128f92ae8bae also changed _Py_fstat() to release the GIL when calling fstat(), I forgot to mention it in the changeset.

test_socket now hangs on AMD64 Snow Leop 3.x, I don't know yet if it's related:

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/2870/steps/test/logs/stdio

[393/393] test_socket
Timeout (1:00:00)!
Thread 0x0000000104fef000 (most recent call first):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/socket.py", line 288 in _sendfile_use_sendfile
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_socket.py", line 5131 in _testOffset
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_socket.py", line 278 in clientRun

Thread 0x00007fff71296cc0 (most recent call first):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/threading.py", line 293 in wait
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/threading.py", line 556 in wait
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_socket.py", line 262 in _tearDown
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/case.py", line 580 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/case.py", line 625 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 122 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 122 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/runner.py", line 176 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/support/__init__.py", line 1773 in _run_suite
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/support/__init__.py", line 1807 in run_unittest
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_socket.py", line 5340 in test_main
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/regrtest.py", line 1280 in runtest_inner

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23752>
_______________________________________

From report at bugs.python.org  Mon Mar 30 11:44:58 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 09:44:58 +0000
Subject: [issue23752] Cleanup io.FileIO
In-Reply-To: <1427129465.77.0.24572480634.issue23752@psf.upfronthosting.co.za>
Message-ID: <1427708698.35.0.0959838384271.issue23752@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, there was another hang before, so it's probably not related:

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/2852/steps/test/logs/stdio

[393/393] test_ssl
Timeout (1:00:00)!
Thread 0x0000000102d81000 (most recent call first):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_ssl.py", line 2832 in serve
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/threading.py", line 871 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/threading.py", line 923 in _bootstrap_inner
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/threading.py", line 891 in _bootstrap

Thread 0x00007fff71296cc0 (most recent call first):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/ssl.py", line 628 in do_handshake
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/ssl.py", line 983 in do_handshake
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/ssl.py", line 747 in __init__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/ssl.py", line 1064 in wrap_socket
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/case.py", line 162 in handle
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/case.py", line 1238 in assertRaisesRegex
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_ssl.py", line 2851 in test_handshake_timeout
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/case.py", line 577 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/case.py", line 625 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 122 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 122 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/unittest/runner.py", line 176 in run
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/support/__init__.py", line 1773 in _run_suite

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23752>
_______________________________________

From report at bugs.python.org  Mon Mar 30 11:52:22 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 09:52:22 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <1427709142.81.0.768457317552.issue22117@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, test_time now pass on "x86 Ubuntu Shared 3.x". It looks like the volatile keyword was enough to fix rounding issues, cool :-)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Mon Mar 30 11:54:13 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 09:54:13 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <20150330095411.9808.35980@psf.io>


Roundup Robot added the comment:

New changeset 1ad3d8d82b18 by Victor Stinner in branch 'default':
Issue #23605: Fix typo in an os.walk() comment
https://hg.python.org/cpython/rev/1ad3d8d82b18

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Mon Mar 30 12:03:07 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 10:03:07 +0000
Subject: [issue23796] BufferedReader.peek() crashes if closed
In-Reply-To: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za>
Message-ID: <1427709787.47.0.414662769266.issue23796@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I confirm the bug on Python 3.5.0a3+.

Is someone interested to fix buffered_peek() to add a check on the closed state?

----------
nosy: +haypo
Added file: http://bugs.python.org/file38735/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23796>
_______________________________________

From report at bugs.python.org  Mon Mar 30 12:04:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 10:04:41 +0000
Subject: [issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal)
In-Reply-To: <1425810901.79.0.570490913636.issue23607@psf.upfronthosting.co.za>
Message-ID: <1427709881.01.0.490383943247.issue23607@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that adds Decimal support for datetime.fromtimestamp() and datetime.utcfromtimestamp(). As side effect Decimal timestamps now are supported in few other places, e.g. in os.utime().

----------
nosy: +haypo
stage: needs patch -> patch review
Added file: http://bugs.python.org/file38736/datetime_fromtimestamp_decimal.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23607>
_______________________________________

From report at bugs.python.org  Mon Mar 30 12:49:42 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 30 Mar 2015 10:49:42 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1427712582.38.0.692698903373.issue23602@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Regarding Decimal:

  1) The context precision isn't used for formatting.  If you have
     another reason for proposing the optional context argument for
     dec_format(), please open another issue.

  2) There's another problem: The mythical DefaultContext (which
     acts as a template for creating new contexts) affects not only
     new thread-local contexts, but also a new Context()!

     In my opinion this is something we should change: The mechanism
     is fine for thread-local contexts, but Context() should behave
     like a pure function.

  3) The double rounding issues are more tricky than it might seem;
     if we use Decimal for this, perhaps direct support in the module
     would be the cleanest option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Mon Mar 30 13:36:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 11:36:57 +0000
Subject: [issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal)
In-Reply-To: <1425810901.79.0.570490913636.issue23607@psf.upfronthosting.co.za>
Message-ID: <1427715417.39.0.550309722172.issue23607@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I reviewed datetime_fromtimestamp_decimal.patch.

> As side effect Decimal timestamps now are supported in few other places, e.g. in os.utime().

It would be more consistent to support decimal.Decimal nowhere or "everywhere". IMO the new _PyTime_FromSecondsObject() (very close to _PyTime_ObjectToDenominator, but using time_t) should also be patched.

Please add some tests for decimal.Decimal in test_time directly. Usually, I try to test rounding and overflow. Testing for overflow is not always possible because it may depend on the platform.

--

See also the PEP 410: "PEP 410 - Use decimal.Decimal type for timestamps". The PEP was rejected. The compromise was a new timestamp format for os.utime(): a number of nanoseconds since the UNIX epoch (1970-01-01). I partially implemented a private API for this PEP in the issue #22117: the new _PyTime_t is a number of timestamp using an arbitrary resolution (currently, it's a number of nanoseconds using a 64-bit signed integer type).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23607>
_______________________________________

From report at bugs.python.org  Mon Mar 30 13:42:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 11:42:45 +0000
Subject: [issue22181] os.urandom() should use Linux 3.17 getrandom() syscall
In-Reply-To: <1407713563.4.0.264701036097.issue22181@psf.upfronthosting.co.za>
Message-ID: <1427715765.87.0.16018608563.issue22181@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22181>
_______________________________________

From report at bugs.python.org  Mon Mar 30 13:53:07 2015
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 30 Mar 2015 11:53:07 +0000
Subject: [issue23500] Argument Clinic: multiple macro definition
In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za>
Message-ID: <1427716387.49.0.460107741937.issue23500@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I want to redo it--it's smelly.  I hope to get it done this week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23500>
_______________________________________

From report at bugs.python.org  Mon Mar 30 13:55:17 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 30 Mar 2015 11:55:17 +0000
Subject: [issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal)
In-Reply-To: <1425810901.79.0.570490913636.issue23607@psf.upfronthosting.co.za>
Message-ID: <1427716517.39.0.941178110936.issue23607@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I just looked at this very briefly: Is the patch context insensitive?

IOW, do things still work if you change the thread-local context:

from decimal import *
c = getcontext()
c.prec = 1
c.Emax = 1
c.Emin = -1

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23607>
_______________________________________

From report at bugs.python.org  Mon Mar 30 13:58:58 2015
From: report at bugs.python.org (Akshet Pandey)
Date: Mon, 30 Mar 2015 11:58:58 +0000
Subject: [issue23811] Python py_compile error message inconsistent and missing
 newline
Message-ID: <1427716738.06.0.245811504272.issue23811@psf.upfronthosting.co.za>


New submission from Akshet Pandey:

On the following test file (test.py):

```python
class Solution:
  def repeatedNumber(self, A):
    test = 1
      return []
```

Running python -m py_compile test.py return the following error message:
Sorry: IndentationError: unexpected indent (test.py, line 6)

But without a newline on stderr at the end of the message. This causes some problems with scripts that expect a newline and new my particular case with reading stderr on docker where docker just ignore the line if it doesn't end in a newline.

Also, this message differs from the runtime error message:

```
  File "test.py", line 6
    return []
    ^
IndentationError: unexpected indent
```

Would it be possible to at least add in a newline and at best, change the message to be consistent with the runtime error message?

I will trying to look at the code and see if I can write a patch but it will take me some time.

----------
components: Interpreter Core
messages: 239598
nosy: akshetp
priority: normal
severity: normal
status: open
title: Python py_compile error message inconsistent and missing newline
type: enhancement
versions: Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23811>
_______________________________________

From report at bugs.python.org  Mon Mar 30 14:19:38 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 30 Mar 2015 12:19:38 +0000
Subject: [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1427717978.96.0.337179229961.issue22341@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch v3:

* Reverted to original crc32(b"hello") example call with the implicit initial CRC
* Added ?Changed in version 3.0? notices, restoring a brief version of the suggestion to use the bit mask, along with an explanation.

Python 2 compatibility information is generally unprecedented in the Python 3 documentation though, but hopefully this version should make more sense to people not already familiar with the Python 2 odd behaviour.

----------
Added file: http://bugs.python.org/file38737/crc-sign.v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22341>
_______________________________________

From report at bugs.python.org  Mon Mar 30 14:28:13 2015
From: report at bugs.python.org (Ben Hoyt)
Date: Mon, 30 Mar 2015 12:28:13 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1427718493.92.0.375222346899.issue23605@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

Thanks for the explanation (and the comment fix).

> What's your point about complexity? Would you like to drop os.scandir
> changes in os.walk(), or do you have a simpler version to propose?

No, not at all! I was just noting it and trying to brainstorm any ways to simplify it (while keeping the current behavior). But I'm not sure there is a good simplification, so that's fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Mon Mar 30 14:28:58 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 12:28:58 +0000
Subject: [issue23799] Join started threads in tests
In-Reply-To: <1427573430.36.0.605750682641.issue23799@psf.upfronthosting.co.za>
Message-ID: <1427718538.74.0.292705714236.issue23799@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Something like this?

----------
Added file: http://bugs.python.org/file38738/test_support_start_threads_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23799>
_______________________________________

From report at bugs.python.org  Mon Mar 30 14:40:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 30 Mar 2015 12:40:55 +0000
Subject: [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1427719255.26.0.913794545085.issue22341@psf.upfronthosting.co.za>


Martin Panter added the comment:

V4 fixes a merge conflict with recent gzip changes.

----------
Added file: http://bugs.python.org/file38739/crc-sign.v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22341>
_______________________________________

From report at bugs.python.org  Mon Mar 30 14:45:58 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 12:45:58 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1427719558.54.0.198600105167.issue23605@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ben: do you think that we are done with this issue? can I close it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Mon Mar 30 14:48:16 2015
From: report at bugs.python.org (Ben Hoyt)
Date: Mon, 30 Mar 2015 12:48:16 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1427719696.85.0.868412218205.issue23605@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

Yep, I'm good -- go ahead and close!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Mon Mar 30 14:48:56 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 12:48:56 +0000
Subject: [issue23605] Use the new os.scandir() function in os.walk()
In-Reply-To: <1425782173.96.0.807112707437.issue23605@psf.upfronthosting.co.za>
Message-ID: <1427719736.89.0.0481115299902.issue23605@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks for your great work Ben! I close the issue. The PEP 471 has already the Final status.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23605>
_______________________________________

From report at bugs.python.org  Mon Mar 30 15:13:12 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 13:13:12 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1427721192.75.0.199456762534.issue2211@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Did you noticed my comments on Rietveld about setdefault() and the :meth: role?

----------
assignee: serhiy.storchaka -> r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Mon Mar 30 15:33:21 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Mar 2015 13:33:21 +0000
Subject: [issue23810] Suboptimal stacklevel of deprecation warnings for
 formatter and imp modules
In-Reply-To: <1427680454.72.0.13356883084.issue23810@psf.upfronthosting.co.za>
Message-ID: <1427722401.47.0.0508664395903.issue23810@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Probably need to introduce a new keyword argument just for deprecated imports or some helper function in importlib to get the stack depth right (else there is a risk of breaking the stack depth in any minor release whenever importlib's depth shifts). Something like the following should be enough (obviously done in warnings instead of per-file):

try:
    level = 1
    while True:
        frame = sys._getframe(level)
        print(frame.f_code.co_filename)
        if '_bootstrap' not in frame.f_code.co_filename:
            break
        level += 1
except ValueError:
    pass
print(sys._getframe(2).f_code.co_filename)
warnings.warn("the imp module is deprecated in favour of importlib; "
              "see the module's documentation for alternative uses",
              PendingDeprecationWarning, stacklevel=level+1)

Otherwise the depths should just go back to what they were at.

----------
nosy: +larry
priority: normal -> release blocker
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23810>
_______________________________________

From report at bugs.python.org  Mon Mar 30 15:44:12 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Mar 2015 13:44:12 +0000
Subject: [issue23807] Improved test coverage for calendar.py command line
In-Reply-To: <1427643739.5.0.155189832451.issue23807@psf.upfronthosting.co.za>
Message-ID: <1427723052.01.0.918258050814.issue23807@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23807>
_______________________________________

From report at bugs.python.org  Mon Mar 30 15:48:12 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 13:48:12 +0000
Subject: [issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal)
In-Reply-To: <1425810901.79.0.570490913636.issue23607@psf.upfronthosting.co.za>
Message-ID: <1427723292.19.0.782698531637.issue23607@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The problem is that the Decimal *was* supported in 2.7. So this issue can be considered not as adding new feature, but as fixing a regression. But changes are too large for just bugfix.

> It would be more consistent to support decimal.Decimal nowhere or "everywhere". IMO the new _PyTime_FromSecondsObject() (very close to _PyTime_ObjectToDenominator, but using time_t) should also be patched.

Will add Decimal support in all functions in Python/pytime.c that support floats.

> Please add some tests for decimal.Decimal in test_time directly. Usually, I try to test rounding and overflow. Testing for overflow is not always possible because it may depend on the platform.

Will do.

> Is the patch context insensitive?

No, the patch is context sensitive. I think the end user is responsible to set an appropriate context if it want to create a datetime from Decimal timestamp. At least until we add functions that return Decimal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23607>
_______________________________________

From report at bugs.python.org  Mon Mar 30 15:49:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 13:49:23 +0000
Subject: [issue23807] Improved test coverage for calendar.py command line
In-Reply-To: <1427643739.5.0.155189832451.issue23807@psf.upfronthosting.co.za>
Message-ID: <1427723363.27.0.0893833553654.issue23807@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, self.assertFailure('-L', 'en') tests this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23807>
_______________________________________

From report at bugs.python.org  Mon Mar 30 15:53:49 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 13:53:49 +0000
Subject: [issue23810] Suboptimal stacklevel of deprecation warnings for
 formatter and imp modules
In-Reply-To: <1427680454.72.0.13356883084.issue23810@psf.upfronthosting.co.za>
Message-ID: <1427723629.68.0.228606225332.issue23810@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Similar feature is needed for warnings in the re module. Methods of regular expression pattern can be called directly or from module-level wrappers. In these case the stack level differs by 1. And sometimes warnings are emitted in recursive parser, when stack level is variable.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23810>
_______________________________________

From report at bugs.python.org  Mon Mar 30 15:54:54 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 30 Mar 2015 13:54:54 +0000
Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful
 on	Windows
In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za>
Message-ID: <1427723694.04.0.731817109145.issue14243@psf.upfronthosting.co.za>


Changes by Paul Moore <p.f.moore at gmail.com>:


----------
nosy: +paul.moore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14243>
_______________________________________

From report at bugs.python.org  Mon Mar 30 15:59:52 2015
From: report at bugs.python.org (Gustavo J. A. M. Carneiro)
Date: Mon, 30 Mar 2015 13:59:52 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
Message-ID: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>


New submission from Gustavo J. A. M. Carneiro:

I have a pattern where I read from a queue with a timeout, generally like this:

while True:
  reader = asyncio.async(wait_for(queue.get(), 0.1))
  try:
    item = (yield from reader)
  except asyncio.TimeoutError:
    reader.cancel()
    continue

This is to have a loop where we try to get items from the queue with a timeout.  Prior to Python 3.5, wait_for() doesn't automatically cancel the reading task, so I have to do it explicitly above.

The code has a strange race condition where, if a taks calls put_nowait on a reader task that is just about to be cancelled due to timeout, then the item that wast put onto the queue gets lost.

In the tests framework, the minimal test case I can come up with is mainly this code:


  q = asyncio.Queue(loop=loop)
  reader = loop.create_task(q.get())
  loop.run_until_complete(asyncio.sleep(0.01, loop=loop))

  q.put_nowait(1)
  q.put_nowait(2)
  reader.cancel()

When the reader gets cancelled, the item `1` is lost into the ether, and when you create another reader for the same queue, it only gets the second item `2`.  I would expect that, if a reader task is cancelled, the item at the head of the queue doesn't get lost.  Either the reader succeeds and the item is removed, or it doesn't succeed and the item is left alone.

I attach a patch to the tulip tests that reproduces the problem in both Python 3.4.2 and tulip hg.

----------
components: asyncio
files: bug-test.diff
keywords: patch
messages: 239611
nosy: gustavo, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38740/bug-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23812>
_______________________________________

From report at bugs.python.org  Mon Mar 30 16:17:56 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 14:17:56 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <20150330141720.122187.57573@psf.io>


Roundup Robot added the comment:

New changeset 7a5f30babc72 by R David Murray in branch '3.4':
#23792: also catch interrupt around pipe.write.
https://hg.python.org/cpython/rev/7a5f30babc72

New changeset 536c4f4acae1 by R David Murray in branch 'default':
Merge: #23792: also catch interrupt around pipe.write.
https://hg.python.org/cpython/rev/536c4f4acae1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Mon Mar 30 16:25:22 2015
From: report at bugs.python.org (Gustavo J. A. M. Carneiro)
Date: Mon, 30 Mar 2015 14:25:22 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1427725522.61.0.00593366395518.issue23812@psf.upfronthosting.co.za>


Changes by Gustavo J. A. M. Carneiro <gjcarneiro at gmail.com>:


Added file: http://bugs.python.org/file38741/Issue23812.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23812>
_______________________________________

From report at bugs.python.org  Mon Mar 30 16:42:46 2015
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 30 Mar 2015 14:42:46 +0000
Subject: [issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal)
In-Reply-To: <1425810901.79.0.570490913636.issue23607@psf.upfronthosting.co.za>
Message-ID: <1427726566.49.0.0343216930162.issue23607@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I think we should try to avoid depending on global state in
the stdlib, at least in new code.  Also, if something is not
really a decimal computation, Decimal itself tries to ignore
the context (like Decimal.__repr__).

At least I would expect this datetime function to be context
independent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23607>
_______________________________________

From report at bugs.python.org  Mon Mar 30 16:45:41 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Mar 2015 14:45:41 +0000
Subject: [issue23792] help crash leaves terminal in raw mode
In-Reply-To: <1427476163.88.0.610503717832.issue23792@psf.upfronthosting.co.za>
Message-ID: <1427726741.46.0.346529656388.issue23792@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yeah, someone could theoretically manage to hit ctl-c between the time the process is started and the call to pipe.write, or between it and the call to wait, but I don't think those very-low-probability events are worth worrying about.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23792>
_______________________________________

From report at bugs.python.org  Mon Mar 30 17:09:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Mar 2015 15:09:15 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1427728155.42.0.223447308833.issue2211@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, sorry, I currently don't always notice reviews unless they are mentioned on the tracker.  I will take a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Mon Mar 30 17:29:14 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Mar 2015 15:29:14 +0000
Subject: [issue23729] Import ElementTree documentation for namespaces and XPath
In-Reply-To: <1426926572.78.0.5131365949.issue23729@psf.upfronthosting.co.za>
Message-ID: <1427729354.5.0.855481071573.issue23729@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file38742/namespace_doc_fixes.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23729>
_______________________________________

From report at bugs.python.org  Mon Mar 30 17:54:59 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 15:54:59 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <20150330155440.55382.14937@psf.io>


Roundup Robot added the comment:

New changeset a70ca6f35327 by R David Murray in branch 'default':
#2211: Fix typo, address missed review comment.
https://hg.python.org/cpython/rev/a70ca6f35327

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Mon Mar 30 17:56:08 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Mar 2015 15:56:08 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1427730968.37.0.370683841122.issue2211@psf.upfronthosting.co.za>


R. David Murray added the comment:

Serhiy: I had already dealt with all the comments in my revisions in one way or another, except for the one about setdefault.  I've added documentation for that now, too.  Sorry for not posting everything for review first...if you see anything you object to in the commits. please let me know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Mon Mar 30 17:58:40 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Mar 2015 15:58:40 +0000
Subject: [issue23811] Python py_compile error message inconsistent and missing
 newline
In-Reply-To: <1427716738.06.0.245811504272.issue23811@psf.upfronthosting.co.za>
Message-ID: <1427731120.04.0.0471215405248.issue23811@psf.upfronthosting.co.za>


R. David Murray added the comment:

I can confirm that the bugs is demonstrated by copying the text below into a normal unix text file.

----------
keywords: +easy
nosy: +r.david.murray
stage:  -> needs patch
type: enhancement -> behavior
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23811>
_______________________________________

From report at bugs.python.org  Mon Mar 30 17:59:39 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 Mar 2015 15:59:39 +0000
Subject: [issue23811] Python py_compile error message inconsistent and missing
 newline
In-Reply-To: <1427716738.06.0.245811504272.issue23811@psf.upfronthosting.co.za>
Message-ID: <1427731179.84.0.950959992298.issue23811@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +Library (Lib) -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23811>
_______________________________________

From report at bugs.python.org  Mon Mar 30 18:02:01 2015
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 30 Mar 2015 16:02:01 +0000
Subject: [issue23640] Enum.from_bytes() is broken
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1427731321.63.0.606134497138.issue23640@psf.upfronthosting.co.za>


Ethan Furman added the comment:

'from_bytes' is a classmethod.  As such, it should return the same type as the class it is called on.  If that wasn't the intent it would be a staticmethod instead.

It is the responsibility of the subclass to override base class behavior, not the other way around.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________

From report at bugs.python.org  Mon Mar 30 18:20:18 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 30 Mar 2015 16:20:18 +0000
Subject: [issue23326] Remove redundant __ne__ implementations
In-Reply-To: <1422308079.14.0.124539148403.issue23326@psf.upfronthosting.co.za>
Message-ID: <1427732418.15.0.82699914196.issue23326@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I'm a little surprised you didn't get pushback from asyncio (i.e. Victor). We try to keep the source identical across releases while asyncio is in provisional mode (i.e. until 3.5 is released).

----------
nosy: +gvanrossum, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23326>
_______________________________________

From report at bugs.python.org  Mon Mar 30 18:22:15 2015
From: report at bugs.python.org (J. Walter Clark)
Date: Mon, 30 Mar 2015 16:22:15 +0000
Subject: [issue22329] Windows installer can't recover partially installed state
In-Reply-To: <1409703967.84.0.334306520264.issue22329@psf.upfronthosting.co.za>
Message-ID: <1427732535.75.0.917112040391.issue22329@psf.upfronthosting.co.za>


J. Walter Clark added the comment:

I had the same issue using Python 3.4.2 x64 on Windows 7 x64 and resolved it by setting PYTHONHOME and PYTHONPATH environmental variables.

----------
nosy: +jwalterclark

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22329>
_______________________________________

From report at bugs.python.org  Mon Mar 30 18:35:05 2015
From: report at bugs.python.org (Bruno Cauet)
Date: Mon, 30 Mar 2015 16:35:05 +0000
Subject: [issue23640] Enum.from_bytes() is broken
In-Reply-To: <1427731321.63.0.606134497138.issue23640@psf.upfronthosting.co.za>
Message-ID: <CAMA3c4_6xzjS8DQ3i4DjAu+TUt6qFKd3Ys3QEeZcH_QRLOa_GA@mail.gmail.com>


Bruno Cauet added the comment:

I'm not sure how you can have both, those two seem opposite to me:
- if 'from_bytes' returns the same type as the class it is called on then
the instantiation of the result object should go through its constructor
(patch proposed)
- if the subclass should override base class behaviour then there is no
reason for Enum.from_bytes to return the same type as the class it is
called on, and therefore it should be made a classmethod.

2015-03-30 18:02 GMT+02:00 Ethan Furman <report at bugs.python.org>:

>
> Ethan Furman added the comment:
>
> 'from_bytes' is a classmethod.  As such, it should return the same type as
> the class it is called on.  If that wasn't the intent it would be a
> staticmethod instead.
>
> It is the responsibility of the subclass to override base class behavior,
> not the other way around.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue23640>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________

From report at bugs.python.org  Mon Mar 30 18:38:16 2015
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 30 Mar 2015 16:38:16 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1427730968.37.0.370683841122.issue2211@psf.upfronthosting.co.za>
Message-ID: <371232AA-3E7B-4B7A-B553-8BA247A044D2@gmail.com>


Demian Brecht added the comment:

Thanks for following up on this David. The changes you've made all look good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Mon Mar 30 19:06:13 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 30 Mar 2015 17:06:13 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1427735173.11.0.0403822227959.issue23812@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Looks like a valid bug report, I like the test you provided, and the fix seems on the right track. Comments on the fix:

- I'd really like to see a rietveld diff for both patches.

- Are there other places where a cancellation can have a similar effect? Maybe the same logic in put()?

- The fix uses waiter.result() but if waiter itself is cancelled this will raise a CancelledError. This is probably fine because in that case no value has been put into it. But now this got me thinking -- how can the yield-from in get() receive a CancelledError without the waiter being cancelled? IOW how does the fix actually work??? (Maybe because the generator has already returned when the Task wrapping it is cancelled?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23812>
_______________________________________

From report at bugs.python.org  Mon Mar 30 19:20:17 2015
From: report at bugs.python.org (Gustavo J. A. M. Carneiro)
Date: Mon, 30 Mar 2015 17:20:17 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1427736017.5.0.856706653873.issue23812@psf.upfronthosting.co.za>


Gustavo J. A. M. Carneiro added the comment:

I created a codereview issue: https://codereview.appspot.com/222930043

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23812>
_______________________________________

From report at bugs.python.org  Mon Mar 30 19:38:37 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 17:38:37 +0000
Subject: [issue23326] Remove redundant __ne__ implementations
In-Reply-To: <1422308079.14.0.124539148403.issue23326@psf.upfronthosting.co.za>
Message-ID: <1427737117.77.0.144287373328.issue23326@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Should I restore __ne__ in asyncio? The version without __ne__ will work with Python 3.4.3 because issue21408 patch was committed in 3.4 too. Explicit __ne__ implementation is just redundant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23326>
_______________________________________

From report at bugs.python.org  Mon Mar 30 19:38:52 2015
From: report at bugs.python.org (Gustavo J. A. M. Carneiro)
Date: Mon, 30 Mar 2015 17:38:52 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1427737132.16.0.965220938667.issue23812@psf.upfronthosting.co.za>


Gustavo J. A. M. Carneiro added the comment:

> - Are there other places where a cancellation can have a similar effect? Maybe the same logic in put()?

Hm.. I didn't look, but yes, it does look like it might be affected by the same issue.  I'll try to create a test for that to confirm.

> how can the yield-from in get() receive a CancelledError without the waiter being cancelled?

Well, it definitely gets a CancelledError in the return (yield from waiter).  I added extensive logging and could confirm this is the case.

What happens is that

1. Test creates a task q.get()
2. The task coroutine, inside Queue.get, blocks on the yield from waiter
3. a couple of items are put in the queue
4. Test code calls task.cancel() (where `task` is running the coroutine q.get)
5. The Queue.get task receives a CancelledError because it was cancelled.  The exception appears to come from the `yield from waiter` only because this is the place where the Queue.get task was suspended, but waiter itself is not cancelled.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23812>
_______________________________________

From report at bugs.python.org  Mon Mar 30 19:44:08 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 30 Mar 2015 17:44:08 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1427737448.09.0.340286242045.issue23812@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Make sense. I'll be waiting for your updated patch. Thanks for both the bug report and the fix!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23812>
_______________________________________

From report at bugs.python.org  Mon Mar 30 19:45:22 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 30 Mar 2015 17:45:22 +0000
Subject: [issue23326] Remove redundant __ne__ implementations
In-Reply-To: <1427737117.77.0.144287373328.issue23326@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+vpZd4cHiAda4ybyiiMNtS27QSYZ68h59f04TLejpznw@mail.gmail.com>


Guido van Rossum added the comment:

Yeah, I'd like to see it restored in asyncio. It seems to be just one file
that's currently out of sync with the tulip "upstream" repo.

On Mon, Mar 30, 2015 at 10:38 AM, Serhiy Storchaka <report at bugs.python.org>
wrote:

>
> Serhiy Storchaka added the comment:
>
> Should I restore __ne__ in asyncio? The version without __ne__ will work
> with Python 3.4.3 because issue21408 patch was committed in 3.4 too.
> Explicit __ne__ implementation is just redundant.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue23326>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23326>
_______________________________________

From report at bugs.python.org  Mon Mar 30 20:35:33 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 30 Mar 2015 18:35:33 +0000
Subject: [issue23810] Suboptimal stacklevel of deprecation warnings for
 formatter and imp modules
In-Reply-To: <1427680454.72.0.13356883084.issue23810@psf.upfronthosting.co.za>
Message-ID: <1427740533.15.0.143935682719.issue23810@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23810>
_______________________________________

From report at bugs.python.org  Mon Mar 30 20:35:51 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 18:35:51 +0000
Subject: [issue23813] RSS and Atom feeds of buildbot results are broken
Message-ID: <1427740551.98.0.543585412367.issue23813@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are links to Atom and RSS feeds on https://www.python.org/dev/buildbot/:

http://buildbot.python.org/all/rss
http://buildbot.python.org/all/atom

Both referred pages are broken.

web.Server Traceback (most recent call last):
exceptions.UnicodeDecodeError: 'utf8' codec can't decode byte 0xfc in position 39: invalid start byte
/usr/lib/python2.7/dist-packages/twisted/web/server.py:189 in process
188                    self._encoder = encoder
189            self.render(resrc)
190        except:
/usr/lib/python2.7/dist-packages/twisted/web/server.py:238 in render
237        try:
238            body = resrc.render(self)
239        except UnsupportedMethod as e:
/data/buildbot/lib/python/buildbot/status/web/feeds.py:55 in render
54    def render(self, request):
55        data = self.content(request)
56        request.setHeader("content-type", self.contentType)
/data/buildbot/lib/python/buildbot/status/web/feeds.py:224 in content
223                        for line in logdata.split('\n')[-30:]:
224                            unilist.append(unicode(line,'utf-8'))
225                        log_lines.extend(unilist)
exceptions.UnicodeDecodeError: 'utf8' codec can't decode byte 0xfc in position 39: invalid start byte

----------
messages: 239631
nosy: pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: RSS and Atom feeds of buildbot results are broken
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23813>
_______________________________________

From report at bugs.python.org  Mon Mar 30 20:30:16 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 18:30:16 +0000
Subject: [issue6650] sre_parse contains a confusing generic error message
In-Reply-To: <1249492479.55.0.250174703511.issue6650@psf.upfronthosting.co.za>
Message-ID: <1427740216.48.0.962708909053.issue6650@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Current (after issue22364) error message is:

>>> re.match('(?<foo>.*)', 'foo')
Traceback (most recent call last):
...
sre_constants.error: unknown extension ?<f at position 1

Is it good enough or should be improved? In regex this syntax is legal and no error is raised.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6650>
_______________________________________

From report at bugs.python.org  Mon Mar 30 20:40:47 2015
From: report at bugs.python.org (Karl O. Pinc)
Date: Mon, 30 Mar 2015 18:40:47 +0000
Subject: [issue23814] argparse: Parser level defaults do not always override
 argument level defaults
Message-ID: <1427740847.33.0.866518706982.issue23814@psf.upfronthosting.co.za>


New submission from Karl O. Pinc:

In the argparse library parser library, contrary to the documentation,
parser-level defaults do not always override argument-level defaults.

https://docs.python.org/3.5/library/argparse.html#argparse.ArgumentParser.set_defaults

says "Note that parser-level defaults always override argument-level defaults:"

(And so does the python 3.3 docs.)

The docs then provide this example:

  >>> parser = argparse.ArgumentParser()
  >>> parser.add_argument('--foo', default='bar')
  >>> parser.set_defaults(foo='spam')
  >>> parser.parse_args([])
  Namespace(foo='spam')

But it is only true that parser-level defaults override argument-level
defaults when they are established after the argument is added.

The output below shows an argument level default overrideing
a parser level default.

$ python3
Python 3.3.2 (default, Jun  4 2014, 11:36:37) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.set_defaults(foo='spam')
>>> parser.add_argument('--foo', default='bar')
_StoreAction(option_strings=['--foo'], dest='foo', nargs=None, const=None, default='bar', type=None, choices=None, help=None, metavar=None)
>>> parser.parse_args([])
Namespace(foo='bar')

It seems that whichever default is set last is the one which is used.
Or perhaps there are not argument level defaults and parser level
defaults, there are just defaults, period.  (It might, possibly,
be nice if there _were_ both argument and parser level defaults
and parser level defaults had priority.  Then this would not be
a documentation bug.)

----------
assignee: docs at python
components: Documentation
messages: 239632
nosy: docs at python, kop
priority: normal
severity: normal
status: open
title: argparse: Parser level defaults do not always override argument level defaults
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23814>
_______________________________________

From report at bugs.python.org  Mon Mar 30 21:26:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 19:26:04 +0000
Subject: [issue23326] Remove redundant __ne__ implementations
In-Reply-To: <1422308079.14.0.124539148403.issue23326@psf.upfronthosting.co.za>
Message-ID: <20150330192601.117743.5294@psf.io>


Roundup Robot added the comment:

New changeset e881444f078f by Serhiy Storchaka in branch 'default':
Partially revert 3603bae63c13 (issue23326) for asyncio.
https://hg.python.org/cpython/rev/e881444f078f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23326>
_______________________________________

From report at bugs.python.org  Mon Mar 30 21:29:11 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 19:29:11 +0000
Subject: [issue23485] PEP 475: handle EINTR in the select and selectors module
In-Reply-To: <1424352775.64.0.420442648443.issue23485@psf.upfronthosting.co.za>
Message-ID: <20150330192907.1892.15733@psf.io>


Roundup Robot added the comment:

New changeset 0ff1090307c7 by Victor Stinner in branch 'default':
Issue #23485: select.select() is now retried automatically with the recomputed
https://hg.python.org/cpython/rev/0ff1090307c7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23485>
_______________________________________

From report at bugs.python.org  Mon Mar 30 21:32:29 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 30 Mar 2015 19:32:29 +0000
Subject: [issue23326] Remove redundant __ne__ implementations
In-Reply-To: <20150330192601.117743.5294@psf.io>
Message-ID: <CAP7+vJLMMz0GF5Ytmu4J+Gr_U20JitWbZ3iEO9z1DYebAkePRQ@mail.gmail.com>


Guido van Rossum added the comment:

Thanks!

On Mon, Mar 30, 2015 at 12:26 PM, Roundup Robot <report at bugs.python.org>
wrote:

>
> Roundup Robot added the comment:
>
> New changeset e881444f078f by Serhiy Storchaka in branch 'default':
> Partially revert 3603bae63c13 (issue23326) for asyncio.
> https://hg.python.org/cpython/rev/e881444f078f
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue23326>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23326>
_______________________________________

From report at bugs.python.org  Mon Mar 30 21:56:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 Mar 2015 19:56:55 +0000
Subject: [issue23815] Segmentation fault when create _tkinter objects
Message-ID: <1427745415.01.0.962782500028.issue23815@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In 2.7 and 3.3:

>>> import _tkinter
>>> _tkinter.Tcl_Obj()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create '_tkinter.Tcl_Obj' instances
>>> _tkinter.TkttType()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create 'tktimertoken' instances

In 3.4+:

>>> import _tkinter
>>> _tkinter.Tcl_Obj()
Segmentation fault (core dumped)

And the same for _tkinter.TkttType.

Looks as this is a result of issue15721.

----------
components: Extension Modules, Tkinter
messages: 239636
nosy: Robin.Schreiber, amaury.forgeotdarc, asvetlov, loewis, ned.deily, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Segmentation fault when create _tkinter objects
type: crash
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23815>
_______________________________________

From report at bugs.python.org  Mon Mar 30 22:10:12 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 20:10:12 +0000
Subject: [issue23485] PEP 475: handle EINTR in the select and selectors module
In-Reply-To: <1424352775.64.0.420442648443.issue23485@psf.upfronthosting.co.za>
Message-ID: <20150330201009.42782.42245@psf.io>


Roundup Robot added the comment:

New changeset 17b6d0d7da00 by Victor Stinner in branch 'default':
Issue #23485: Fix test_signal, select.select() now retries the syscall if the
https://hg.python.org/cpython/rev/17b6d0d7da00

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23485>
_______________________________________

From report at bugs.python.org  Mon Mar 30 22:16:01 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 Mar 2015 20:16:01 +0000
Subject: [issue23485] PEP 475: handle EINTR in the select and selectors module
In-Reply-To: <1424352775.64.0.420442648443.issue23485@psf.upfronthosting.co.za>
Message-ID: <20150330201558.10336.34978@psf.io>


Roundup Robot added the comment:

New changeset 0591cf5c9ebd by Victor Stinner in branch 'default':
Issue #23485: Add _PyTime_FromMillisecondsObject() function
https://hg.python.org/cpython/rev/0591cf5c9ebd

New changeset 69b1683ee001 by Victor Stinner in branch 'default':
Issue #23485: select.poll.poll() is now retried when interrupted by a signal
https://hg.python.org/cpython/rev/69b1683ee001

New changeset 5194a84ed9f3 by Victor Stinner in branch 'default':
Issue #23485: select.epoll.poll() is now retried when interrupted by a signal
https://hg.python.org/cpython/rev/5194a84ed9f3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23485>
_______________________________________

From report at bugs.python.org  Mon Mar 30 22:18:58 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 20:18:58 +0000
Subject: [issue23771] Timeouts on "x86 Ubuntu Shared 3.x" buildbot
In-Reply-To: <1427251322.87.0.815245923642.issue23771@psf.upfronthosting.co.za>
Message-ID: <1427746738.83.0.801038844841.issue23771@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Last 5 builds of "x86 Ubuntu Shared 3.x" and "AMD64 Debian root 3.x" buildbots are green (success). The sporadic hang is gone! I close the issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23771>
_______________________________________

From report at bugs.python.org  Mon Mar 30 22:34:16 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 20:34:16 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect)
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <1427747656.36.0.655405329159.issue23618@psf.upfronthosting.co.za>


STINNER Victor added the comment:

test_selectors.patch: Enhance test_selector to test the two kinds of signal handlers: one raises an exception, the other one doesn't. I wait until kqueue & devpoll retry on EINTR to push test_selectors.patch.

----------
Added file: http://bugs.python.org/file38743/test_selectors.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Mon Mar 30 22:36:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 Mar 2015 20:36:51 +0000
Subject: [issue23648] PEP 475 meta issue
In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za>
Message-ID: <1427747811.3.0.593188474439.issue23648@psf.upfronthosting.co.za>


STINNER Victor added the comment:

inject_signals.patch: Quick-and-dirty patch to send signals (SIGALRM) every milliseconds when running unit tests.

On Linux, results are very good. Only multiprocessing fails because of the issue #23618 (socket connect) which has a pending patch. I hope that we will quickly reach a point where the full test suite completes without failure while sending millions of signals to it!

----------
Added file: http://bugs.python.org/file38744/inject_signals.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23648>
_______________________________________

From report at bugs.python.org  Mon Mar 30 23:18:24 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 30 Mar 2015 21:18:24 +0000
Subject: [issue23793] Support __add__, __mul__, and __imul__ for deques.
In-Reply-To: <1427477638.63.0.2394294758.issue23793@psf.upfronthosting.co.za>
Message-ID: <1427750304.67.0.761248726763.issue23793@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

The behavior for multiplying or adding doesn't seem quite so intuitive when you allow for a bounded deque. In particular, it doesn't seem obvious that multiplying when the deque is bounded, you'll get results like:

>>> list(deque([1,2], 3) * 2)
[2, 1, 2]

Similarly, when you support non-in-place addition, the bounded-ness of the result depends on the order of the values added.

>>> list(deque([1,2], 3) + deque([1,2], 2))
[1, 2, 1]
>>> list(deque([1,2], 2) + deque([1,2], 3))
[1, 2]

Not saying these are the wrong behaviors, but it's much more weird than what you get with other sequence types (since most sequence types aren't bounded), and possibly why deques didn't include these features in the first place; trying to act like a generalized sequence when you have features that don't fit the model is a titch odd.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23793>
_______________________________________

From report at bugs.python.org  Mon Mar 30 23:21:52 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 30 Mar 2015 21:21:52 +0000
Subject: [issue23729] Import ElementTree documentation for namespaces and XPath
In-Reply-To: <1426926572.78.0.5131365949.issue23729@psf.upfronthosting.co.za>
Message-ID: <1427750512.55.0.944124335644.issue23729@psf.upfronthosting.co.za>


Martin Panter added the comment:

The new patch looks good, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23729>
_______________________________________

From report at bugs.python.org  Mon Mar 30 23:27:03 2015
From: report at bugs.python.org (Jon Heiner)
Date: Mon, 30 Mar 2015 21:27:03 +0000
Subject: [issue23816] struct.unpack returns null pascal strings - [first] bug
 report
Message-ID: <1427750823.57.0.914162685824.issue23816@psf.upfronthosting.co.za>


New submission from Jon Heiner:

I believe there is an issue with the _struct.c handling of Pascal style strings.

In the _struct.c:s_unpack_internal() function (reading 2.7.6 and 2.7.9 source from tgz ball), the size parameter 'n' is clamped to code->size-1.

As far as I can tell, 'n' is set to the correct deserialized value, but the code->size value is not set to 255. I could be incorrect, as I'm not running in a debugger.

I've attached a short repro case. Note the use of unpack_from() as otherwise unpac() will thrown an error. Additionally, I may be using it wrong, but this feels correct.

----------
components: Library (Lib)
files: unpack_pascal.py
messages: 239644
nosy: jonheiner, mark.dickinson, meador.inge
priority: normal
severity: normal
status: open
title: struct.unpack returns null pascal strings - [first] bug report
versions: Python 2.7
Added file: http://bugs.python.org/file38745/unpack_pascal.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23816>
_______________________________________

From report at bugs.python.org  Mon Mar 30 23:45:50 2015
From: report at bugs.python.org (John Hergenroeder)
Date: Mon, 30 Mar 2015 21:45:50 +0000
Subject: [issue23796] BufferedReader.peek() crashes if closed
In-Reply-To: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za>
Message-ID: <1427751950.04.0.87832040695.issue23796@psf.upfronthosting.co.za>


John Hergenroeder added the comment:

If no-one else wants it, I'd love to tackle this as my first Python (and OSS in general) contribution. Attached is a one-line patch that just does a CHECK_CLOSED call in buffered_peek and is modeled on the pattern in the buffered_flush function just above. I'm under the impression that the final patch will need to include a test that confirms the patch worked, but I wanted to claim the bug and start the feedback process early :)

----------
keywords: +patch
nosy: +jdherg
Added file: http://bugs.python.org/file38746/buffered_reader_closed_peek.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23796>
_______________________________________

From report at bugs.python.org  Tue Mar 31 00:23:40 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 30 Mar 2015 22:23:40 +0000
Subject: [issue23793] Support __add__, __mul__, and __imul__ for deques.
In-Reply-To: <1427477638.63.0.2394294758.issue23793@psf.upfronthosting.co.za>
Message-ID: <1427754220.93.0.930440864303.issue23793@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

I think my first addition example is wrong (should produce [2, 1, 2]), but you get the idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23793>
_______________________________________

From report at bugs.python.org  Tue Mar 31 00:55:46 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 30 Mar 2015 22:55:46 +0000
Subject: [issue23796] BufferedReader.peek() crashes if closed
In-Reply-To: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za>
Message-ID: <1427756146.46.0.143290585693.issue23796@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, John.

> I'm under the impression that the final patch will need to include a test that confirms the patch worked,

Correct. You could convert the reproducers in msg239445 to a test case.

The patch looks good to me. I think you'll also need to add a similar check to buffered_read1():

>>> from io import *
>>> b = BufferedReader(BytesIO(b"12"))
>>> b.read(1)
b'1'
>>> b.close()
>>> b.peek()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: peek of closed file
>>> b.read1(1)
Segmentation fault (core dumped)

----------
nosy: +berker.peksag
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23796>
_______________________________________

From report at bugs.python.org  Tue Mar 31 02:00:58 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 31 Mar 2015 00:00:58 +0000
Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable
 (on POSIX)
In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za>
Message-ID: <1427760058.4.0.0299537869338.issue23458@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23458>
_______________________________________

From report at bugs.python.org  Tue Mar 31 02:13:07 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Mar 2015 00:13:07 +0000
Subject: [issue17214] http.client.HTTPConnection.putrequest encode  error
In-Reply-To: <1361011959.8.0.221376430084.issue17214@psf.upfronthosting.co.za>
Message-ID: <1427760787.88.0.939646108689.issue17214@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think this patch needs a test. I left some comments on Reitveld as well. Perhaps there should also be a test to prove that redirects to URLs like /spaced%20path/ do not get mangled.

Have a look at the HTTPRedirectHandler.redirect_request() method. Perhaps the code translating spaces to %20 could be merged with the fix for this issue.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17214>
_______________________________________

From report at bugs.python.org  Tue Mar 31 02:15:49 2015
From: report at bugs.python.org (Brian)
Date: Tue, 31 Mar 2015 00:15:49 +0000
Subject: [issue23791] Identify Moved Lines with difflib
In-Reply-To: <1427473520.44.0.514545586028.issue23791@psf.upfronthosting.co.za>
Message-ID: <1427760949.64.0.0836769964857.issue23791@psf.upfronthosting.co.za>


Brian added the comment:

I have put together 5 basic tests to implement moved lines in difflib. All diffs should be compared against the 'diffmove_base.txt' file. Below is a short description of each test.

1) Basic reordering of lines
2) Reordering of lines with new lines added
3) Reordering of lines with one line removed
4) Reordering of lines with one character omitted from a line and character added to another line
5) Combination of all previous tests

----------
Added file: http://bugs.python.org/file38747/python_diff_move.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23791>
_______________________________________

From report at bugs.python.org  Tue Mar 31 02:35:31 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Mar 2015 00:35:31 +0000
Subject: [issue19100] Use backslashreplace in pprint
In-Reply-To: <1380279910.92.0.349060015388.issue19100@psf.upfronthosting.co.za>
Message-ID: <1427762131.71.0.587113462689.issue19100@psf.upfronthosting.co.za>


Martin Panter added the comment:

I agree with Serhiy that using a permissive error handler with pprint() is appropriate.

What is the reasoning behind the DecodeWriter case, where the original stream has an interesting encoding, but ?buffer? is None? Are there any real-world cases like that? Your mock test case sets encoding="latin1" with no buffer, but that class will also write non-latin1 strings, so there is no problem.

Also I wonder if flushing the stream once or twice for each pprint() call is a wise move.

Another way to tackle this might be a function that translates the non-Latin-1 or whatever characters, allowing the original write() or whatever method to still be used. Here is a Python 2 and 3 compatible attempt: <https://bitbucket.org/Gfy/pyrescene/src/560cafe/rescene/utility.py#cl-426>. Python 3 only version: <https://github.com/vadmium/python-iview/commit/68b0559>. This function is originally used for printing descriptive comments to stdout (alongside other text where the ?strict? error handler is appropriate). But I think it could be generally usable for pprint(), sys.displayhook(), etc as well.

----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19100>
_______________________________________

From report at bugs.python.org  Tue Mar 31 02:58:26 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Mar 2015 00:58:26 +0000
Subject: [issue5550] [urllib.request]: Comparison of HTTP headers should be
 insensitive to the case
In-Reply-To: <1237870141.83.0.616869799184.issue5550@psf.upfronthosting.co.za>
Message-ID: <1427763506.68.0.862898493129.issue5550@psf.upfronthosting.co.za>


Martin Panter added the comment:

According to <https://bugs.python.org/issue18986#msg236161> that PEP isn?t going to be accepted, although no reason seems to have been given. So I wouldn?t hold back because of that.

----------
dependencies: +Add a case-insensitive case-preserving dict
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5550>
_______________________________________

From report at bugs.python.org  Tue Mar 31 03:38:01 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 31 Mar 2015 01:38:01 +0000
Subject: [issue23793] Support __add__, __mul__, and __imul__ for deques.
In-Reply-To: <1427477638.63.0.2394294758.issue23793@psf.upfronthosting.co.za>
Message-ID: <1427765881.17.0.938679451665.issue23793@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> The behavior for multiplying or adding doesn't seem quite so 
> intuitive when you allow for a bounded deque.

What would you want it to do?  By design, the key feature of maxlen is pop old inputs to make way newer appends -- that is its essence.

It would be surprising if the following invariant didn't hold:

>>> deque('abc' * 3, maxlen=5) == deque('abc', maxlen=5) * 3
True

That said, I don't expect that people are going to commonly be doing d*=n where len(d) > 1 and there is a maxlen > len(d)*n.   The normal cases are unsurprising.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23793>
_______________________________________

From report at bugs.python.org  Tue Mar 31 03:44:24 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Mar 2015 01:44:24 +0000
Subject: [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1427766264.09.0.118856032465.issue12855@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch v4 adds back the reference to ?universal newlines?. I did not alter the doc string, because I don?t think doc strings need to be as detailed as the main documentation.

----------
Added file: http://bugs.python.org/file38748/linebreakdoc.v4.py3.5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12855>
_______________________________________

From report at bugs.python.org  Tue Mar 31 04:07:32 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 31 Mar 2015 02:07:32 +0000
Subject: [issue23774] Test failures when unable to write to install location
In-Reply-To: <1427265696.1.0.371099529167.issue23774@psf.upfronthosting.co.za>
Message-ID: <1427767652.41.0.604482663239.issue23774@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> test_compileall

See issue 21264

I think this can be closed as a duplicate of issue 17750.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23774>
_______________________________________

From report at bugs.python.org  Tue Mar 31 04:19:03 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 31 Mar 2015 02:19:03 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>
Message-ID: <1427768343.98.0.623073073319.issue22609@psf.upfronthosting.co.za>


Berker Peksag added the comment:

UserDict_self_and_dict_keywords.patch looks good to me. Is there a reason not to use assertWarnsRegex?

Also, there are already collections.UserDict() usages in the test file, so I'd remove the "from collections import UserDict" import.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22609>
_______________________________________

From report at bugs.python.org  Tue Mar 31 04:25:43 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 31 Mar 2015 02:25:43 +0000
Subject: [issue23779] imaplib authenticate raises TypeError if authenticator
 tries to abort
In-Reply-To: <1427322083.72.0.863898159285.issue23779@psf.upfronthosting.co.za>
Message-ID: <1427768743.74.0.6051219996.issue23779@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report and the patch, Craig. Could you convert your reproducer to a test case? imaplib tests are located in Lib/test/test_imaplib.py.

----------
nosy: +berker.peksag
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23779>
_______________________________________

From report at bugs.python.org  Tue Mar 31 04:36:06 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 31 Mar 2015 02:36:06 +0000
Subject: [issue23663] Crash on failure in ctypes on Cygwin
In-Reply-To: <1426370668.97.0.493459472376.issue23663@psf.upfronthosting.co.za>
Message-ID: <1427769366.58.0.255139290877.issue23663@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> PyErr_Format in ctypes uses invalid parameter
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23663>
_______________________________________

From report at bugs.python.org  Tue Mar 31 04:36:23 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Mar 2015 02:36:23 +0000
Subject: [issue5714] http.server._url_collapse_path should live elsewhere
In-Reply-To: <1239063845.81.0.120232947257.issue5714@psf.upfronthosting.co.za>
Message-ID: <1427769383.41.0.163467460221.issue5714@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5714>
_______________________________________

From report at bugs.python.org  Tue Mar 31 04:36:44 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 31 Mar 2015 02:36:44 +0000
Subject: [issue23338] PyErr_Format in ctypes uses invalid parameter
In-Reply-To: <1422442371.36.0.968367348117.issue23338@psf.upfronthosting.co.za>
Message-ID: <1427769404.25.0.377316371824.issue23338@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
stage:  -> patch review
type: crash -> behavior
versions: +Python 3.4, Python 3.5 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23338>
_______________________________________

From report at bugs.python.org  Tue Mar 31 04:38:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Mar 2015 02:38:39 +0000
Subject: [issue11344] Add os.path.splitpath(path) function
In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>
Message-ID: <1427769519.09.0.927413008673.issue11344@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think my use cases of splitpath() could be fulfilled by using Path.parts, Path.anchor, Path.relative_to(), etc. I am a bit sad that this never made it in, but I agree it is redundant with pathlib, and the issue should probably be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11344>
_______________________________________

From report at bugs.python.org  Tue Mar 31 04:40:03 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 31 Mar 2015 02:40:03 +0000
Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1427769603.74.0.647506767171.issue23484@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23484>
_______________________________________

From report at bugs.python.org  Tue Mar 31 04:51:16 2015
From: report at bugs.python.org (Craig Holmquist)
Date: Tue, 31 Mar 2015 02:51:16 +0000
Subject: [issue23779] imaplib authenticate raises TypeError if authenticator
 tries to abort
In-Reply-To: <1427322083.72.0.863898159285.issue23779@psf.upfronthosting.co.za>
Message-ID: <1427770276.0.0.656361340324.issue23779@psf.upfronthosting.co.za>


Craig Holmquist added the comment:

New patch is attached.

----------
Added file: http://bugs.python.org/file38749/imap_auth2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23779>
_______________________________________

From report at bugs.python.org  Tue Mar 31 05:30:33 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Mar 2015 03:30:33 +0000
Subject: [issue23729] Import ElementTree documentation for namespaces and XPath
In-Reply-To: <1426926572.78.0.5131365949.issue23729@psf.upfronthosting.co.za>
Message-ID: <20150331033026.65753.58398@psf.io>


Roundup Robot added the comment:

New changeset 28b778b0a132 by Raymond Hettinger in branch '3.4':
Issue #23729:  Improve docs for ElementTree namespace parsing
https://hg.python.org/cpython/rev/28b778b0a132

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23729>
_______________________________________

From report at bugs.python.org  Tue Mar 31 05:47:03 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Mar 2015 03:47:03 +0000
Subject: [issue23729] Import ElementTree documentation for namespaces and XPath
In-Reply-To: <1426926572.78.0.5131365949.issue23729@psf.upfronthosting.co.za>
Message-ID: <20150331034700.119992.71167@psf.io>


Roundup Robot added the comment:

New changeset 051cf1aa6288 by Raymond Hettinger in branch '2.7':
Issue #23729:  Improve docs for ElementTree namespace parsing
https://hg.python.org/cpython/rev/051cf1aa6288

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23729>
_______________________________________

From report at bugs.python.org  Tue Mar 31 05:47:27 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 31 Mar 2015 03:47:27 +0000
Subject: [issue23729] Import ElementTree documentation for namespaces and XPath
In-Reply-To: <1426926572.78.0.5131365949.issue23729@psf.upfronthosting.co.za>
Message-ID: <1427773647.26.0.403327592823.issue23729@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23729>
_______________________________________

From report at bugs.python.org  Tue Mar 31 06:11:11 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Mar 2015 04:11:11 +0000
Subject: [issue23088] Document that PyUnicode_AsUTF8() returns a
 null-terminated string
In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>
Message-ID: <1427775071.14.0.342083075259.issue23088@psf.upfronthosting.co.za>


Martin Panter added the comment:

utf8-null.v4.patch:

* Clarified some mentions of ?string? and ?character? as bytes or code points
* Copied the warning about embedded nulls to PyUnicode_AS_UNICODE()

----------
Added file: http://bugs.python.org/file38750/utf8-null.v4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23088>
_______________________________________

From report at bugs.python.org  Tue Mar 31 06:23:25 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Mar 2015 04:23:25 +0000
Subject: [issue23411] Update urllib.parse.__all__
In-Reply-To: <1423395526.83.0.535584531827.issue23411@psf.upfronthosting.co.za>
Message-ID: <1427775805.93.0.123913402673.issue23411@psf.upfronthosting.co.za>


Martin Panter added the comment:

urllib.parse-all.v2.patch removes indentation from a blank line and merges recent changes to avoid a potential conflict.

----------
Added file: http://bugs.python.org/file38751/urllib.parse-all.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23411>
_______________________________________

From report at bugs.python.org  Tue Mar 31 06:23:48 2015
From: report at bugs.python.org (Masayuki Yamamoto)
Date: Tue, 31 Mar 2015 04:23:48 +0000
Subject: [issue21085] compile error Python3.3 on Cygwin
In-Reply-To: <1396019829.85.0.386935527155.issue21085@psf.upfronthosting.co.za>
Message-ID: <1427775828.05.0.0278843947965.issue21085@psf.upfronthosting.co.za>


Masayuki Yamamoto added the comment:

New patch uses configure script to set the compile condition for struct_siginfo.si_band. 
The script was generated from configure.ac using autoreconf.

Could you make sure of having the si_band in another platform?

----------
Added file: http://bugs.python.org/file38752/3.4-issue21085-struct_siginfo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21085>
_______________________________________

From report at bugs.python.org  Tue Mar 31 07:04:40 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 05:04:40 +0000
Subject: [issue23796] BufferedReader.peek() crashes if closed
In-Reply-To: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za>
Message-ID: <1427778280.79.0.840102874234.issue23796@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee: serhiy.storchaka -> berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23796>
_______________________________________

From report at bugs.python.org  Tue Mar 31 07:05:43 2015
From: report at bugs.python.org (Tuomas Suutari)
Date: Tue, 31 Mar 2015 05:05:43 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1427712582.38.0.692698903373.issue23602@psf.upfronthosting.co.za>
Message-ID: <CAPXCX8DVy_p6rgsRWNGoRt4qXm+befwuXXm3=7H3Oi8=xM9=_w@mail.gmail.com>


Tuomas Suutari added the comment:

On 30 March 2015 at 13:49, Stefan Krah wrote:
> Regarding Decimal:
>
>   1) The context precision isn't used for formatting.  If you have
>      another reason for proposing the optional context argument for
>      dec_format(), please open another issue.

Yes, context precision isn't, but context rounding mode is. That's why
I wanted to use a known context rather than the current (thread-local)
context.

But yes, I also thought that maybe the Decimal.__format__ changes
should go to another issue, which my implementation would then depend
on though. It wouldn't be too bad if Py and C version of
Decimal.__format__ had same interface. What do you think?

>   2) There's another problem: The mythical DefaultContext (which
>      acts as a template for creating new contexts) affects not only
>      new thread-local contexts, but also a new Context()!
>
>      In my opinion this is something we should change: The mechanism
>      is fine for thread-local contexts, but Context() should behave
>      like a pure function.

I don't understand what do you mean with this. Is this something that
I'm doing wrong in my patch or just another (related?) issue?

>   3) The double rounding issues are more tricky than it might seem;
>      if we use Decimal for this, perhaps direct support in the module
>      would be the cleanest option.

What double rounding issues you're referring to?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Tue Mar 31 07:17:44 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 31 Mar 2015 05:17:44 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1427779064.62.0.943061714596.issue16991@psf.upfronthosting.co.za>


Eric Snow added the comment:

I've opened a feature clone to better track the work (features/cordereddict).  Here's the updated patch against default from that clone.  I haven't added any argument client stuff.  I also haven't addressed any of the feedback from Antoine.  I'd rather leave OrderedDict as a "builtin" since the whole point is to be able to use OrderedDict in the interpreter.

----------
Added file: http://bugs.python.org/file38753/cOrderedDict-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16991>
_______________________________________

From report at bugs.python.org  Tue Mar 31 07:18:55 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 31 Mar 2015 05:18:55 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1427779135.1.0.758711188934.issue16991@psf.upfronthosting.co.za>


Eric Snow added the comment:

s/argument client/Argument Clinic/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16991>
_______________________________________

From report at bugs.python.org  Tue Mar 31 07:28:51 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 05:28:51 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1427768343.98.0.623073073319.issue22609@psf.upfronthosting.co.za>
Message-ID: <1934848.ON4Xrs2XsK@raxxla>


Serhiy Storchaka added the comment:

Thank you for your review Berker.

> Is there a reason not to use assertWarnsRegex?

Initially the patch was written for 2.7. Fixing WeakValueDictionary in 2.7 
needs first fix UserDict (issue22958). That is why I returned to this issue.

> Also, there are already collections.UserDict() usages in the test file, so
> I'd remove the "from collections import UserDict" import.

These tests originally was written for test_collections.

Updated patch addresses Berker's comment.

----------
Added file: http://bugs.python.org/file38754/UserDict_self_and_dict_keywords_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22609>
_______________________________________
-------------- next part --------------
diff -r 34bd8fee3006 Lib/collections/__init__.py
--- a/Lib/collections/__init__.py	Tue Mar 31 07:20:03 2015 +0300
+++ b/Lib/collections/__init__.py	Tue Mar 31 08:19:07 2015 +0300
@@ -924,7 +924,23 @@ class ChainMap(MutableMapping):
 class UserDict(MutableMapping):
 
     # Start by filling-out the abstract methods
-    def __init__(self, dict=None, **kwargs):
+    def __init__(*args, **kwargs):
+        if not args:
+            raise TypeError("descriptor '__init__' of 'UserDict' object "
+                            "needs an argument")
+        self, *args = args
+        if len(args) > 1:
+            raise TypeError('expected at most 1 arguments, got %d' % len(args))
+        if args:
+            dict = args[0]
+        else:
+            if 'dict' in kwargs:
+                dict = kwargs.pop('dict')
+                import warnings
+                warnings.warn("Passing 'dict' as keyword argument is "
+                              "deprecated", DeprecationWarning, stacklevel=2)
+            else:
+                dict = None
         self.data = {}
         if dict is not None:
             self.update(dict)
diff -r 34bd8fee3006 Lib/test/test_userdict.py
--- a/Lib/test/test_userdict.py	Tue Mar 31 07:20:03 2015 +0300
+++ b/Lib/test/test_userdict.py	Tue Mar 31 08:19:07 2015 +0300
@@ -2,6 +2,7 @@
 
 from test import support, mapping_tests
 import collections
+from collections import UserDict
 
 d0 = {}
 d1 = {"one": 1}
@@ -29,7 +30,8 @@ class UserDictTest(mapping_tests.TestHas
         self.assertEqual(collections.UserDict(one=1, two=2), d2)
         # item sequence constructor
         self.assertEqual(collections.UserDict([('one',1), ('two',2)]), d2)
-        self.assertEqual(collections.UserDict(dict=[('one',1), ('two',2)]), d2)
+        with self.assertWarnsRegex(DeprecationWarning, 'dict'):
+            self.assertEqual(collections.UserDict(dict=[('one',1), ('two',2)]), d2)
         # both together
         self.assertEqual(collections.UserDict([('one',1), ('two',2)], two=3, three=5), d3)
 
@@ -139,6 +141,30 @@ class UserDictTest(mapping_tests.TestHas
         self.assertEqual(t.popitem(), ("x", 42))
         self.assertRaises(KeyError, t.popitem)
 
+    def test_init(self):
+        for kw in 'self', 'other', 'iterable':
+            self.assertEqual(list(collections.UserDict(**{kw: 42}).items()),
+                             [(kw, 42)])
+        self.assertEqual(list(collections.UserDict({}, dict=42).items()),
+                         [('dict', 42)])
+        self.assertEqual(list(collections.UserDict({}, dict=None).items()),
+                         [('dict', None)])
+        with self.assertWarnsRegex(DeprecationWarning, 'dict'):
+            self.assertEqual(list(collections.UserDict(dict={'a': 42}).items()),
+                             [('a', 42)])
+        self.assertRaises(TypeError, collections.UserDict, 42)
+        self.assertRaises(TypeError, collections.UserDict, (), ())
+        self.assertRaises(TypeError, collections.UserDict.__init__)
+
+    def test_update(self):
+        for kw in 'self', 'dict', 'other', 'iterable':
+            d = collections.UserDict()
+            d.update(**{kw: 42})
+            self.assertEqual(list(d.items()), [(kw, 42)])
+        self.assertRaises(TypeError, collections.UserDict().update, 42)
+        self.assertRaises(TypeError, collections.UserDict().update, {}, {})
+        self.assertRaises(TypeError, collections.UserDict.update)
+
     def test_missing(self):
         # Make sure UserDict doesn't have a __missing__ method
         self.assertEqual(hasattr(collections.UserDict, "__missing__"), False)

From report at bugs.python.org  Tue Mar 31 07:29:52 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Mar 2015 05:29:52 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1427779792.31.0.891879983037.issue23602@psf.upfronthosting.co.za>


Martin Panter added the comment:

I understand double rounding to mean incorrectly rounding something like 0.149999 up to 0.2. It should be rounded once to 1 decimal place (0.1). If you temporarily round it to a higher number of places before rounding to 1 place, you?re doing it wrong. So you might have to ensure that any rounding done before formatting step exactly matches the rounding specified in the formatting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Tue Mar 31 07:41:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 05:41:31 +0000
Subject: [issue23411] Update urllib.parse.__all__
In-Reply-To: <1423395526.83.0.535584531827.issue23411@psf.upfronthosting.co.za>
Message-ID: <1427780491.76.0.929045652838.issue23411@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think it would be safer not commit this patch in 3.4 and 2.7. The patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23411>
_______________________________________

From report at bugs.python.org  Tue Mar 31 07:49:03 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 05:49:03 +0000
Subject: [issue23088] Document that PyUnicode_AsUTF8() returns a
 null-terminated string
In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>
Message-ID: <1427780943.06.0.0634194767531.issue23088@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch LGTM, but someone other should look on it. David, could you please make a look?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23088>
_______________________________________

From report at bugs.python.org  Tue Mar 31 08:02:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Mar 2015 06:02:39 +0000
Subject: [issue19176] DeprecationWarning for doctype() method when subclassing
 _elementtree.XMLParser
In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za>
Message-ID: <1427781759.46.0.513739009919.issue19176@psf.upfronthosting.co.za>


Martin Panter added the comment:

The difference of calling XMLParser.doctype() between the implementations is another argument for removing it completely. With all these bugs, and no opposition that I know of, I think it should be okay to remove the deprecated doctype() method in 3.5.

doctype-remove.v2.patch adds a tweaked version of the original test for no DeprecationWarning from the other patch.

----------
Added file: http://bugs.python.org/file38755/doctype-remove.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19176>
_______________________________________

From report at bugs.python.org  Tue Mar 31 08:09:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 06:09:15 +0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1427782155.64.0.56458234329.issue2211@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you David, all LGTM.

I noted that the :func: role sometimes is used for methods in the whatsnew file (and perhaps in other rst files). Perhaps it should be changed to :meth:. But this is other issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
_______________________________________

From report at bugs.python.org  Tue Mar 31 08:28:25 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Mar 2015 06:28:25 +0000
Subject: [issue19176] DeprecationWarning for doctype() method when subclassing
 _elementtree.XMLParser
In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za>
Message-ID: <1427783305.51.0.0989247153666.issue19176@psf.upfronthosting.co.za>


Martin Panter added the comment:

inherit-doctype.v2.patch inverts the logic in the C module. This patch may still be useful if people want to apply it to 3.4, or do not want to remove the deprecated method from 3.5.

----------
Added file: http://bugs.python.org/file38756/inherit-doctype.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19176>
_______________________________________

From report at bugs.python.org  Tue Mar 31 09:10:13 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Mar 2015 07:10:13 +0000
Subject: [issue19176] DeprecationWarning for doctype() method when subclassing
 _elementtree.XMLParser
In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za>
Message-ID: <1427785813.9.0.291090282757.issue19176@psf.upfronthosting.co.za>


Martin Panter added the comment:

doctype-remove.v3.patch includes an entry on the What?s New page.

----------
Added file: http://bugs.python.org/file38757/doctype-remove.v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19176>
_______________________________________

From report at bugs.python.org  Tue Mar 31 10:59:05 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 08:59:05 +0000
Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting
 of integers
In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za>
Message-ID: <1427792345.47.0.421919517584.issue23466@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23466>
_______________________________________

From report at bugs.python.org  Tue Mar 31 11:25:18 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 31 Mar 2015 09:25:18 +0000
Subject: [issue10395] new os.path function to extract common prefix based on
 path components
In-Reply-To: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>
Message-ID: <1427793918.16.0.0731346757863.issue10395@psf.upfronthosting.co.za>


Paul Moore added the comment:

The patch looks good to me.

rhettinger: I'm not sure I see a problem with the doc changes in the latest patch - noting that commonprefix may return an invalid path is fine, and what the current docs say. Directing people to commonpath if they don't want invalid paths also seems fine.

Paddy McCarthy: I don't think that the backward compatibility cost of moving os.path.commonprefix is worth it.

----------
nosy: +paul.moore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10395>
_______________________________________

From report at bugs.python.org  Tue Mar 31 11:33:05 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 31 Mar 2015 09:33:05 +0000
Subject: [issue11344] Add os.path.splitpath(path) function
In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za>
Message-ID: <1427794385.14.0.83605643013.issue11344@psf.upfronthosting.co.za>


Paul Moore added the comment:

Assuming new code should be using pathlib, I agree this should probably be closed now as obsolete.

One proviso - pathlib objects don't take a bytestring path in the constructor. If there's a need for a low-level splitpath taking bytes objects, there may still be a benefit to this patch. Otherwise pathlib.Path(p).parts is a direct replacement AFAICT.

----------
nosy: +paul.moore

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11344>
_______________________________________

From report at bugs.python.org  Tue Mar 31 12:17:46 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Mar 2015 10:17:46 +0000
Subject: [issue23485] PEP 475: handle EINTR in the select and selectors module
In-Reply-To: <1424352775.64.0.420442648443.issue23485@psf.upfronthosting.co.za>
Message-ID: <20150331101734.95086.40899@psf.io>


Roundup Robot added the comment:

New changeset b017ca5d28bc by Victor Stinner in branch 'default':
Issue #23485: select.kqueue.control() is now retried when interrupted by a signal
https://hg.python.org/cpython/rev/b017ca5d28bc

New changeset f54bc2c52dfd by Victor Stinner in branch 'default':
Issue #23485: select.devpoll.poll() is now retried when interrupted by a signal
https://hg.python.org/cpython/rev/f54bc2c52dfd

New changeset 76d297869859 by Victor Stinner in branch 'default':
Issue #23485: Enhance and update selectors doc and test_selectors
https://hg.python.org/cpython/rev/76d297869859

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23485>
_______________________________________

From report at bugs.python.org  Tue Mar 31 12:19:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Mar 2015 10:19:18 +0000
Subject: [issue18473] some objects pickled by Python 3.x are not unpicklable
 in Python 2.x because of incorrect REVERSE_IMPORT_MAPPING
In-Reply-To: <1373973767.04.0.0542870445433.issue18473@psf.upfronthosting.co.za>
Message-ID: <20150331101912.113177.77235@psf.io>


Roundup Robot added the comment:

New changeset 8d86dfe53b97 by Serhiy Storchaka in branch '3.4':
Issue #18473: Fixed 2to3 and 3to2 compatible pickle mappings.
https://hg.python.org/cpython/rev/8d86dfe53b97

New changeset 5980e81219ed by Serhiy Storchaka in branch 'default':
Issue #18473: Fixed 2to3 and 3to2 compatible pickle mappings.
https://hg.python.org/cpython/rev/5980e81219ed

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18473>
_______________________________________

From report at bugs.python.org  Tue Mar 31 12:20:50 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Mar 2015 10:20:50 +0000
Subject: [issue23485] PEP 475: handle EINTR in the select and selectors module
In-Reply-To: <1424352775.64.0.420442648443.issue23485@psf.upfronthosting.co.za>
Message-ID: <1427797250.81.0.413079037685.issue23485@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23485>
_______________________________________

From report at bugs.python.org  Tue Mar 31 12:21:42 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Mar 2015 10:21:42 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect)
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <1427797302.53.0.258376366234.issue23618@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file38743/test_selectors.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Tue Mar 31 12:22:48 2015
From: report at bugs.python.org (Gustavo J. A. M. Carneiro)
Date: Tue, 31 Mar 2015 10:22:48 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1427797368.11.0.253077045097.issue23812@psf.upfronthosting.co.za>


Gustavo J. A. M. Carneiro added the comment:

So I uploaded a new patch version fixing a similar problem in put().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23812>
_______________________________________

From report at bugs.python.org  Tue Mar 31 12:25:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 10:25:01 +0000
Subject: [issue13583] sqlite3.Row doesn't support slice indexes
In-Reply-To: <1323639948.36.0.717803065724.issue13583@psf.upfronthosting.co.za>
Message-ID: <1427797501.05.0.573615197168.issue13583@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee: ghaering -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13583>
_______________________________________

From report at bugs.python.org  Tue Mar 31 12:34:18 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Mar 2015 10:34:18 +0000
Subject: [issue13583] sqlite3.Row doesn't support slice indexes
In-Reply-To: <1323639948.36.0.717803065724.issue13583@psf.upfronthosting.co.za>
Message-ID: <20150331103409.65773.98378@psf.io>


Roundup Robot added the comment:

New changeset e47f520eb756 by Serhiy Storchaka in branch 'default':
Issue #13583: sqlite3.Row now supports slice indexing.
https://hg.python.org/cpython/rev/e47f520eb756

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13583>
_______________________________________

From report at bugs.python.org  Tue Mar 31 12:36:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 10:36:54 +0000
Subject: [issue13583] sqlite3.Row doesn't support slice indexes
In-Reply-To: <1323639948.36.0.717803065724.issue13583@psf.upfronthosting.co.za>
Message-ID: <1427798214.91.0.758470734052.issue13583@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The implementation can be much simpler, but in any case thank you for your patches Lucas and Jessica.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13583>
_______________________________________

From report at bugs.python.org  Tue Mar 31 12:38:12 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 10:38:12 +0000
Subject: [issue22035] Fatal error in dbm.gdbm
In-Reply-To: <1406024440.03.0.44171364302.issue22035@psf.upfronthosting.co.za>
Message-ID: <1427798292.69.0.472964590784.issue22035@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22035>
_______________________________________

From report at bugs.python.org  Tue Mar 31 12:39:07 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 31 Mar 2015 10:39:07 +0000
Subject: [issue23793] Support __add__, __mul__, and __imul__ for deques.
In-Reply-To: <1427477638.63.0.2394294758.issue23793@psf.upfronthosting.co.za>
Message-ID: <1427798347.06.0.889412710172.issue23793@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

I agree that popping old inputs is the normal way. What I'm trying to say is that it doesn't feel like "old" or "inputs" when you multiply. In that case (and maybe this is just me), it feels like a "reasonable" outcome could be to get an outcome similar to multiplying a list and then slicing the result to maxlen. I don't think it *should* do that, but either behavior feels weird, solely because sequence multiplication has never been applied to a bounded sequence before (to my knowledge), so the expectations aren't set.

You end up with weird behaviors like len(seq) * 3 != len(seq * 3), which is a normal and expected outcome with every other sequence. If you know you're dealing with a bounded deque, it's less unexpected, but this is trying to make a deque a drop-in replacement for any other sequence when it doesn't behave like one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23793>
_______________________________________

From report at bugs.python.org  Tue Mar 31 13:09:45 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Mar 2015 11:09:45 +0000
Subject: [issue23611] Pickle nested names with protocols < 4
In-Reply-To: <1425837040.48.0.408829364916.issue23611@psf.upfronthosting.co.za>
Message-ID: <20150331110805.113165.29037@psf.io>


Roundup Robot added the comment:

New changeset ca12465418bd by Serhiy Storchaka in branch 'default':
Issue #23611: Serializing more "lookupable" objects (such as unbound methods
https://hg.python.org/cpython/rev/ca12465418bd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23611>
_______________________________________

From report at bugs.python.org  Tue Mar 31 13:50:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Mar 2015 11:50:39 +0000
Subject: [issue23360] Content-Type when sending data with urlopen()
In-Reply-To: <1422794612.5.0.505084736818.issue23360@psf.upfronthosting.co.za>
Message-ID: <1427802639.04.0.473499416414.issue23360@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think we should avoid mentioning bytes-like objects until Issue 23740 (http.client support), Issue 23756 (clarify definition), and/or SSLSocket.sendall() support are sorted out.

Changes in non-urlencoded.3.patch:
* Removed iterable object as direct urlopen() argument, since that would require a custom Content-Length and therefore a custom Request object
* Removed Content-Type discussion from urlopen() for similar reasons
* Added iterable object to Request constructor (already tested)
* Clarified default Content-Type whenever data is not None
* Added a test for default Content-Type with iterable object

----------
stage:  -> patch review
versions: +Python 3.5
Added file: http://bugs.python.org/file38758/non-urlencoded.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23360>
_______________________________________

From report at bugs.python.org  Tue Mar 31 13:54:52 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Mar 2015 11:54:52 +0000
Subject: [issue18473] some objects pickled by Python 3.x are not unpicklable
 in Python 2.x because of incorrect REVERSE_IMPORT_MAPPING
In-Reply-To: <1373973767.04.0.0542870445433.issue18473@psf.upfronthosting.co.za>
Message-ID: <1427802892.11.0.324715043254.issue18473@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Buildbots are unhappy. Example:

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/11437/steps/test/logs/stdio


======================================================================
ERROR: test_name_mapping (test.test_pickle.CompatPickleTests) [(('tkinter.filedialog', 'FileDialog'), ('FileDialog', 'FileDialog'))]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_pickle.py", line 241, in getmodule
    return sys.modules[module]
KeyError: 'tkinter.filedialog'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_pickle.py", line 286, in test_name_mapping
    attr = getattribute(module3, name3)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_pickle.py", line 247, in getattribute
    obj = getmodule(module)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_pickle.py", line 243, in getmodule
    __import__(module)
  File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/tkinter/__init__.py", line 38, in <module>
    import _tkinter # If this fails your Python may not be configured for Tk
ImportError: No module named '_tkinter'

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18473>
_______________________________________

From report at bugs.python.org  Tue Mar 31 14:00:24 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Mar 2015 12:00:24 +0000
Subject: [issue18473] some objects pickled by Python 3.x are not unpicklable
 in Python 2.x because of incorrect REVERSE_IMPORT_MAPPING
In-Reply-To: <1373973767.04.0.0542870445433.issue18473@psf.upfronthosting.co.za>
Message-ID: <1427803224.94.0.940036316313.issue18473@psf.upfronthosting.co.za>


STINNER Victor added the comment:

A different error:

http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/2880/steps/test/logs/stdio

======================================================================
FAIL: test_class_nested_enum_and_pickle_protocol_four (test.test_enum.TestEnum)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_enum.py", line 580, in test_class_nested_enum_and_pickle_protocol_four
    protocol=(0, 3))
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_enum.py", line 82, in test_pickle_exception
    dumps(obj, protocol=protocol)
AssertionError: PicklingError not raised

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18473>
_______________________________________

From report at bugs.python.org  Tue Mar 31 14:00:56 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Mar 2015 12:00:56 +0000
Subject: [issue18473] some objects pickled by Python 3.x are not unpicklable
 in Python 2.x because of incorrect REVERSE_IMPORT_MAPPING
In-Reply-To: <1373973767.04.0.0542870445433.issue18473@psf.upfronthosting.co.za>
Message-ID: <1427803256.62.0.85117319617.issue18473@psf.upfronthosting.co.za>


STINNER Victor added the comment:

A third kind of error:

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/5992/steps/test/logs/stdio

======================================================================
ERROR: test_import (test.test_pickle.CompatPickleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_pickle.py", line 241, in getmodule
    return sys.modules[module]
KeyError: 'multiprocessing.popen_fork'

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\test\test_pickle.py", line 266, in test_import
    getmodule(module)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_pickle.py", line 243, in getmodule
    __import__(module)
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\multiprocessing\popen_fork.py", line 13, in <module>
    class Popen(object):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\multiprocessing\popen_fork.py", line 25, in Popen
    def poll(self, flag=os.WNOHANG):
AttributeError: module 'os' has no attribute 'WNOHANG'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18473>
_______________________________________

From report at bugs.python.org  Tue Mar 31 14:05:31 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Mar 2015 12:05:31 +0000
Subject: [issue22035] Fatal error in dbm.gdbm
In-Reply-To: <1406024440.03.0.44171364302.issue22035@psf.upfronthosting.co.za>
Message-ID: <1427803531.06.0.0229587642244.issue22035@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I would prefer to avoid setgmp/longjmp, it's kind of a hack. It's maybe more a design issue in the gdbm library to report errors.

I proposed a generic signal handler using setjmp/longjmp to convert SIGSEGV to regular Python exceptions, but it was rejected: issue #3999.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22035>
_______________________________________

From report at bugs.python.org  Tue Mar 31 14:06:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Mar 2015 12:06:08 +0000
Subject: [issue22035] Fatal error in dbm.gdbm
In-Reply-To: <1406024440.03.0.44171364302.issue22035@psf.upfronthosting.co.za>
Message-ID: <1427803568.17.0.526852221588.issue22035@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Oh, Mark, please stop shaking up bug tracker.

I agree: please stop posting useless messages, and review patches instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22035>
_______________________________________

From report at bugs.python.org  Tue Mar 31 14:11:39 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Mar 2015 12:11:39 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect)
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <20150331121126.65757.35399@psf.io>


Roundup Robot added the comment:

New changeset e8246baad0f6 by Victor Stinner in branch 'default':
Issue #23618: Refactor the _socket module
https://hg.python.org/cpython/rev/e8246baad0f6

New changeset fa5542660b17 by Victor Stinner in branch 'default':
Issue #23618: Refactor internal_select() to prepare socket.connect() for EINTR
https://hg.python.org/cpython/rev/fa5542660b17

New changeset c027d6468667 by Victor Stinner in branch 'default':
Issue #23618: internal_connect_select() now waits also for error events
https://hg.python.org/cpython/rev/c027d6468667

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Tue Mar 31 14:14:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 12:14:27 +0000
Subject: [issue10395] new os.path function to extract common prefix based on
 path components
In-Reply-To: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>
Message-ID: <1427804067.5.0.134483695331.issue10395@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch only adds a reference to commonpath() in commonprefix() documentation. The note about invalid paths already was here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10395>
_______________________________________

From report at bugs.python.org  Tue Mar 31 14:19:59 2015
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Tue, 31 Mar 2015 12:19:59 +0000
Subject: [issue19100] Use backslashreplace in pprint
In-Reply-To: <1380279910.92.0.349060015388.issue19100@psf.upfronthosting.co.za>
Message-ID: <1427804399.63.0.573981997764.issue19100@psf.upfronthosting.co.za>


Walter D?rwald added the comment:

The linked code at https://github.com/vadmium/python-iview/commit/68b0559 seems strange to me:

    try:
        text.encode(encoding, textio.errors or "strict")
    except UnicodeEncodeError:
        text = text.encode(encoding, errors).decode(encoding)
    return text

is the same as:

    return text.encode(encoding, errors).decode(encoding)

because when there are no unencodable characters in text, the error handler will never be invoked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19100>
_______________________________________

From report at bugs.python.org  Tue Mar 31 14:26:10 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Mar 2015 12:26:10 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect)
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <20150331122457.65773.86999@psf.io>


Roundup Robot added the comment:

New changeset 47b2d1ff9743 by Victor Stinner in branch 'default':
Issue #23618: Fix internal_connect_select()
https://hg.python.org/cpython/rev/47b2d1ff9743

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Tue Mar 31 14:32:56 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Mar 2015 12:32:56 +0000
Subject: [issue10395] new os.path function to extract common prefix based on
 path components
In-Reply-To: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>
Message-ID: <20150331123237.91364.10144@psf.io>


Roundup Robot added the comment:

New changeset ec6c812fbc1f by Serhiy Storchaka in branch 'default':
Issue #10395: Added os.path.commonpath().  Implemented in posixpath and ntpath.
https://hg.python.org/cpython/rev/ec6c812fbc1f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10395>
_______________________________________

From report at bugs.python.org  Tue Mar 31 14:46:47 2015
From: report at bugs.python.org (bapt)
Date: Tue, 31 Mar 2015 12:46:47 +0000
Subject: [issue23817] Consider FreeBSD like any other OS in SOVERSION
Message-ID: <1427806007.43.0.118979455245.issue23817@psf.upfronthosting.co.za>


New submission from bapt:

In the configuration script:
https://hg.python.org/cpython/file/47b2d1ff9743/configure.ac#l963

There is a special treatment done for FreeBSD, which is not needed, FreeBSD is perfectly fine with multiple digit in soversion.

----------
components: Build
messages: 239695
nosy: bapt
priority: normal
severity: normal
status: open
title: Consider FreeBSD like any other OS in SOVERSION

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23817>
_______________________________________

From report at bugs.python.org  Tue Mar 31 14:49:56 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Mar 2015 12:49:56 +0000
Subject: [issue23817] Consider FreeBSD like any other OS in SOVERSION
In-Reply-To: <1427806007.43.0.118979455245.issue23817@psf.upfronthosting.co.za>
Message-ID: <1427806196.87.0.587448728.issue23817@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> https://hg.python.org/cpython/file/47b2d1ff9743/configure.ac#l963

This command was added by the changeset 6fc10306bf31.

----------
nosy: +haypo, koobs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23817>
_______________________________________

From report at bugs.python.org  Tue Mar 31 14:58:00 2015
From: report at bugs.python.org (Ximin Luo)
Date: Tue, 31 Mar 2015 12:58:00 +0000
Subject: [issue19660] decorator syntax: allow testlist instead of just
 dotted_name
In-Reply-To: <1384910825.18.0.00604679093295.issue19660@psf.upfronthosting.co.za>
Message-ID: <1427806680.34.0.0019116773529.issue19660@psf.upfronthosting.co.za>


Ximin Luo added the comment:

Yes, please get rid of this restriction. It's trivial to get around - you don't even need to define your own "pass-through", one already exists in the standard library:

>>> @(lambda: [lambda x: x][0])()
  File "<stdin>", line 1
    @(lambda: [lambda x: x][0])()
     ^
SyntaxError: invalid syntax

>>> from functools import partial as _
>>> @_( (lambda: [lambda x: x][0])() )
... def f(x): return x*x
... 
>>> f(3)
9

I don't know the rational behind disallowing bar().foo(), but it is the use-case I have in mind - something like:

@MainDecoratorFactory(params).tweakedDecorator(tweak_params)
def f(x):
  pass

or even

@MainDecoratorFactory(params).\
 tweakedDecorator(tweak_params)
def f(x):
  pass

It should be no more controversial than chaining decorators.

The alternative with the current restrictions would be tweakedDecorator(MainDecorator(params), tweak_params) which is more ugly and visually separates the "tweak" concepts.

It's not appropriate to merge MainDecoratorFactory and the tweaks together: there are several MainDecoratorFactories taking care of one main concern; they don't care about the tweaks. And vice versa; the tweaks shouldn't care about the main decorators.

----------
nosy: +xl269

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19660>
_______________________________________

From report at bugs.python.org  Tue Mar 31 15:03:31 2015
From: report at bugs.python.org (bapt)
Date: Tue, 31 Mar 2015 13:03:31 +0000
Subject: [issue23817] Consider FreeBSD like any other OS in SOVERSION
In-Reply-To: <1427806007.43.0.118979455245.issue23817@psf.upfronthosting.co.za>
Message-ID: <1427807011.27.0.0361641143422.issue23817@psf.upfronthosting.co.za>


bapt added the comment:

Adding a patch on configure.ac (I bet configure should not be patched but regenerated)

Considering the comment here: http://bugs.python.org/issue1044395#msg47064 about ldconfig(1) the output of ldconfig(1) is buggy in that regard, and the ports tree does not depends on that anymore so it will perfectly accept the 2 digit name.

There are no known other things depending on that buggy output

----------
keywords: +patch
Added file: http://bugs.python.org/file38759/configure_ac.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23817>
_______________________________________

From report at bugs.python.org  Tue Mar 31 15:05:14 2015
From: report at bugs.python.org (koobs)
Date: Tue, 31 Mar 2015 13:05:14 +0000
Subject: [issue23817] Consider FreeBSD like any other OS in SOVERSION
In-Reply-To: <1427806007.43.0.118979455245.issue23817@psf.upfronthosting.co.za>
Message-ID: <1427807114.65.0.53507036816.issue23817@psf.upfronthosting.co.za>


koobs added the comment:

+1

----------
stage:  -> needs patch
type:  -> enhancement
versions: +Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23817>
_______________________________________

From report at bugs.python.org  Tue Mar 31 15:08:36 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 13:08:36 +0000
Subject: [issue23818] test_enum failing
 test_class_nested_enum_and_pickle_protocol_four
Message-ID: <1427807316.71.0.103044792684.issue23818@psf.upfronthosting.co.za>


New submission from Brett Cannon:

test test_enum failed -- Traceback (most recent call last):
  File "/Users/bcannon/Repositories/cpython/default/Lib/test/test_enum.py", line 580, in test_class_nested_enum_and_pickle_protocol_four
    protocol=(0, 3))
  File "/Users/bcannon/Repositories/cpython/default/Lib/test/test_enum.py", line 82, in test_pickle_exception
    dumps(obj, protocol=protocol)
AssertionError: PicklingError not raised

----------
components: Library (Lib)
messages: 239700
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_enum failing test_class_nested_enum_and_pickle_protocol_four
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23818>
_______________________________________

From report at bugs.python.org  Tue Mar 31 15:12:28 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 Mar 2015 13:12:28 +0000
Subject: [issue23779] imaplib authenticate raises TypeError if authenticator
 tries to abort
In-Reply-To: <1427322083.72.0.863898159285.issue23779@psf.upfronthosting.co.za>
Message-ID: <1427807548.43.0.0919622618911.issue23779@psf.upfronthosting.co.za>


R. David Murray added the comment:

The patch looks good to me, except that I think it would be better if the test verified that the '*' response is received by the server (perhaps return OK if we don't get it?)

----------
components: +email
nosy: +barry, r.david.murray
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23779>
_______________________________________

From report at bugs.python.org  Tue Mar 31 15:28:30 2015
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 31 Mar 2015 13:28:30 +0000
Subject: [issue18378] locale.getdefaultlocale() fails on Mac OS X with default
 language set to English
In-Reply-To: <1373113143.69.0.513997485887.issue18378@psf.upfronthosting.co.za>
Message-ID: <1427808510.03.0.0410782140771.issue18378@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

1) I agree with Ned that the OSX behavior is not broken, it is different but within spec. Python makes assumption about the format of locale names that aren't universally valid.

2) We should be careful in using CFLocale. Those APIs are part of CoreFoundation and CoreFoundation APIs cannot be used in the child proces after calling os.fork. 

As an aside to 2), CoreFoundation and any other Apple "Cocoa" frameworks should be assumed to use threads and hence the comment about threads in the fork specification (link below) apply, and currently Apple doesn't appear to use pthread_atfork to make sure library state is valid in child processes after fork.

<http://pubs.opengroup.org/onlinepubs/009695399/functions/fork.html>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18378>
_______________________________________

From report at bugs.python.org  Tue Mar 31 15:29:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Mar 2015 13:29:17 +0000
Subject: [issue23817] Consider FreeBSD like any other OS in SOVERSION
In-Reply-To: <1427806007.43.0.118979455245.issue23817@psf.upfronthosting.co.za>
Message-ID: <1427808557.48.0.934501241061.issue23817@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> koobs	set	versions: + Python 2.7, Python 3.4, Python 3.5

Do you seriously consider to modify Python 2.7 and 3.4? Can it break the backward compatibility?

I don't know how the SOVERSION thing is used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23817>
_______________________________________

From report at bugs.python.org  Tue Mar 31 15:31:35 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 13:31:35 +0000
Subject: [issue23819] test_asyncio fails when run under -O
Message-ID: <1427808695.9.0.385563565443.issue23819@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Ton of failures along the lines of:

======================================================================
ERROR: test_ctor (test.test_asyncio.test_unix_events.UnixReadPipeTransportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bcannon/Repositories/cpython/default/Lib/test/test_asyncio/test_unix_events.py", line 329, in setUp
    self.loop = self.new_test_loop()
  File "/Users/bcannon/Repositories/cpython/default/Lib/asyncio/test_utils.py", line 413, in new_test_loop
    self.set_event_loop(loop)
  File "/Users/bcannon/Repositories/cpython/default/Lib/asyncio/test_utils.py", line 407, in set_event_loop
    events.set_event_loop(None)
  File "/Users/bcannon/Repositories/cpython/default/Lib/asyncio/events.py", line 581, in set_event_loop
    get_event_loop_policy().set_event_loop(loop)
AttributeError: 'object' object has no attribute 'set_event_loop'

----------
components: asyncio
messages: 239704
nosy: brett.cannon, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: test_asyncio fails when run under -O
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23819>
_______________________________________

From report at bugs.python.org  Tue Mar 31 15:35:35 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 13:35:35 +0000
Subject: [issue23820] test_importlib fails under -O
Message-ID: <1427808935.25.0.609166440001.issue23820@psf.upfronthosting.co.za>


New submission from Brett Cannon:

======================================================================
FAIL: test_cached_sourceless (test.test_importlib.test_spec.Frozen_ModuleSpecTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bcannon/Repositories/cpython/default/Lib/test/test_importlib/test_spec.py", line 224, in test_cached_sourceless
    self.assertEqual(self.loc_spec.cached, 'spam.pyc')
AssertionError: None != 'spam.pyc'

----------
assignee: brett.cannon
components: Tests
messages: 239705
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_importlib fails under -O
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23820>
_______________________________________

From report at bugs.python.org  Tue Mar 31 15:36:58 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Mar 2015 13:36:58 +0000
Subject: [issue23819] test_asyncio fails when run under -O
In-Reply-To: <1427808695.9.0.385563565443.issue23819@psf.upfronthosting.co.za>
Message-ID: <1427809018.62.0.167589805051.issue23819@psf.upfronthosting.co.za>


STINNER Victor added the comment:

-O disables assertions, and asyncio has a ton of assertions. Some tests maybe rely on them? I guess that they are real bugs (assert must be replaced with a regular if+raise) in the middle of the failures.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23819>
_______________________________________

From report at bugs.python.org  Tue Mar 31 15:38:14 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 13:38:14 +0000
Subject: [issue23821] test_pdb fails under -O
Message-ID: <1427809094.04.0.0519767176067.issue23821@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
components: Tests
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_pdb fails under -O
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23821>
_______________________________________

From report at bugs.python.org  Tue Mar 31 15:39:13 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 13:39:13 +0000
Subject: [issue23822] test_py_compile fails under -O
Message-ID: <1427809153.77.0.260576385757.issue23822@psf.upfronthosting.co.za>


New submission from Brett Cannon:

======================================================================
FAIL: test_double_dot_no_clobber (__main__.PyCompileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bcannon/Repositories/cpython/default/Lib/test/test_py_compile.py", line 115, in test_double_dot_no_clobber
    'foo.bar.{}.pyc'.format(sys.implementation.cache_tag)))
AssertionError: '__pycache__/foo.bar.cpython-35.pyo' != '__pycache__/foo.bar.cpython-35.pyc'
- __pycache__/foo.bar.cpython-35.pyo
?                                  ^
+ __pycache__/foo.bar.cpython-35.pyc
?

----------
assignee: brett.cannon
components: Tests
messages: 239707
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_py_compile fails under -O
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23822>
_______________________________________

From report at bugs.python.org  Tue Mar 31 15:40:03 2015
From: report at bugs.python.org (bapt)
Date: Tue, 31 Mar 2015 13:40:03 +0000
Subject: [issue23817] Consider FreeBSD like any other OS in SOVERSION
In-Reply-To: <1427806007.43.0.118979455245.issue23817@psf.upfronthosting.co.za>
Message-ID: <1427809203.47.0.471434879636.issue23817@psf.upfronthosting.co.za>


bapt added the comment:

Provide more information:
Here is a description of the problem with the FreeBSD ldconfig(1) problem and why it was a problem with libpython.so.*

https://wiki.freebsd.org/ports/fix_lib_depends

Here is the commit that adds the new methode for ports to lookup for libraries installed (not using ldconfig(1):
https://svnweb.freebsd.org/ports?view=revision&revision=322328
here is the commit that removes the ancient method:
https://svnweb.freebsd.org/ports?view=revision&revision=362031

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23817>
_______________________________________

From report at bugs.python.org  Tue Mar 31 15:43:37 2015
From: report at bugs.python.org (bapt)
Date: Tue, 31 Mar 2015 13:43:37 +0000
Subject: [issue23817] Consider FreeBSD like any other OS in SOVERSION
In-Reply-To: <1427806007.43.0.118979455245.issue23817@psf.upfronthosting.co.za>
Message-ID: <1427809417.19.0.0353311934073.issue23817@psf.upfronthosting.co.za>


bapt added the comment:

I do not think it is worth changing python 2.7 or python 3.4 given the fact that the .so.1 symlink is not created (which imho it should be a good idea to create but let's go step by step)

Let's just do it for next python

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23817>
_______________________________________

From report at bugs.python.org  Tue Mar 31 15:56:02 2015
From: report at bugs.python.org (rschwieb)
Date: Tue, 31 Mar 2015 13:56:02 +0000
Subject: [issue23823] "Generalization" misused in deque docs
Message-ID: <1427810162.43.0.413466648837.issue23823@psf.upfronthosting.co.za>


New submission from rschwieb:

This sentence in the deque docs (https://docs.python.org/2/library/collections.html#collections.deque) is not accurate: 

"Deques are a generalization of stacks and queues ..."

Deques are a _specialization_ of stacks and queues. Every deque is-a stack and is-a queue, but saying that "deques generalize stacks and queues" reverses this relationship.

On the surface it might seem minor, but I think it's worth correcting in this case since the "is-a" relationship is so fundamental in computer science. Besides, I'd like to think Python's awesome documentation is above using words to mean the opposite of what they mean :)

----------
assignee: docs at python
components: Documentation
messages: 239710
nosy: docs at python, rschwieb
priority: normal
severity: normal
status: open
title: "Generalization" misused in deque docs
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23823>
_______________________________________

From report at bugs.python.org  Tue Mar 31 15:58:41 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Mar 2015 13:58:41 +0000
Subject: [issue18473] some objects pickled by Python 3.x are not unpicklable
 in Python 2.x because of incorrect REVERSE_IMPORT_MAPPING
In-Reply-To: <1373973767.04.0.0542870445433.issue18473@psf.upfronthosting.co.za>
Message-ID: <20150331135729.119996.27029@psf.io>


Roundup Robot added the comment:

New changeset 5c5eb374e296 by Serhiy Storchaka in branch '3.4':
Issue #18473: Fixed pickle compatibility tests for optional modules.
https://hg.python.org/cpython/rev/5c5eb374e296

New changeset 29b2b2d8e36f by Serhiy Storchaka in branch 'default':
Issue #18473: Fixed pickle compatibility tests for optional modules.
https://hg.python.org/cpython/rev/29b2b2d8e36f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18473>
_______________________________________

From report at bugs.python.org  Tue Mar 31 15:58:41 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Mar 2015 13:58:41 +0000
Subject: [issue23611] Pickle nested names with protocols < 4
In-Reply-To: <1425837040.48.0.408829364916.issue23611@psf.upfronthosting.co.za>
Message-ID: <20150331135728.119996.50668@psf.io>


Roundup Robot added the comment:

New changeset f78b9f700d45 by Serhiy Storchaka in branch 'default':
Issue #23611: Fixed enums pickling tests.  Now all picklings work with all
https://hg.python.org/cpython/rev/f78b9f700d45

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23611>
_______________________________________

From report at bugs.python.org  Tue Mar 31 16:00:33 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 14:00:33 +0000
Subject: [issue18473] some objects pickled by Python 3.x are not unpicklable
 in Python 2.x because of incorrect REVERSE_IMPORT_MAPPING
In-Reply-To: <1373973767.04.0.0542870445433.issue18473@psf.upfronthosting.co.za>
Message-ID: <1427810433.88.0.63373748112.issue18473@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed import errors. A second kind of errors was related to issue23611.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18473>
_______________________________________

From report at bugs.python.org  Tue Mar 31 16:01:23 2015
From: report at bugs.python.org (Jethro)
Date: Tue, 31 Mar 2015 14:01:23 +0000
Subject: [issue23824] in-place addition of a shadowed class field
Message-ID: <1427810483.28.0.753445482899.issue23824@psf.upfronthosting.co.za>


New submission from Jethro:

Look at this simple code:

    class A:
	tot = 0
	def __init__(self, a):
		self.tot += a

    x = A(3)
    print(x.tot, A.tot)

Result from print: 

    3 0

What the interpreter did was that it first resolved self.tot to be the class field tot, which resolves to 0, then it created an instance field tot to hold the result 3.

This is not correct, as one single self.tot meant two different things. Two ways to fix this: 

1. report a name undefined error (interpret self.tot as instance field)

2. increase A.tot (interpret self.tot as class field)

Clearly 1 seems more naturally to Python, even though I wished python could disallow a class field to be shadowed by instance field, which seems quite a reasonable thing to do.

----------
components: Interpreter Core
messages: 239714
nosy: jethro
priority: normal
severity: normal
status: open
title: in-place addition of a shadowed class field
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23824>
_______________________________________

From report at bugs.python.org  Tue Mar 31 16:11:20 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 Mar 2015 14:11:20 +0000
Subject: [issue23824] in-place addition of a shadowed class field
In-Reply-To: <1427810483.28.0.753445482899.issue23824@psf.upfronthosting.co.za>
Message-ID: <1427811080.84.0.202720714872.issue23824@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yep, this is the way it works.  When a class attribute name is referenced on an instance object, you are referencing the object pointed to by the class name.  What happens next depends on what kind of object you have, and what kind of operation you perform.  In this case, you have an immutable object, and the addition operation returns a new immutable object, which gets assigned (as always happens) to the instance attribute name.  If tot was, say, [0] and the operation was self.tot += [1], your print would print [0, 1] [0, 1], because the in-place addition operation on lists *mutatates* the list, and what gets assigned to the instance attribute name is a pointer to the *same* object that the class attribute points to.

In short, this is a more subtle instance of the confusion discussed here: https://docs.python.org/3/faq/programming.html#why-did-changing-list-y-also-change-list-x (and also the FAQ that follows that one).

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23824>
_______________________________________

From report at bugs.python.org  Tue Mar 31 16:29:03 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 14:29:03 +0000
Subject: [issue23825] test_idle fails under -OO
Message-ID: <1427812143.77.0.00519422003594.issue23825@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
components: IDLE
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_idle fails under -OO
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23825>
_______________________________________

From report at bugs.python.org  Tue Mar 31 16:38:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 14:38:02 +0000
Subject: [issue23818] test_enum failing
 test_class_nested_enum_and_pickle_protocol_four
In-Reply-To: <1427807316.71.0.103044792684.issue23818@psf.upfronthosting.co.za>
Message-ID: <1427812682.42.0.174616654394.issue23818@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is related to issue23611 and fixed by f78b9f700d45.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23818>
_______________________________________

From report at bugs.python.org  Tue Mar 31 16:39:18 2015
From: report at bugs.python.org (Jethro)
Date: Tue, 31 Mar 2015 14:39:18 +0000
Subject: [issue23824] in-place addition of a shadowed class field
In-Reply-To: <1427810483.28.0.753445482899.issue23824@psf.upfronthosting.co.za>
Message-ID: <1427812758.3.0.940630074556.issue23824@psf.upfronthosting.co.za>


Jethro added the comment:

I believe Mr. Murray somehow missed the point. My point is that the very same self.tot is interpreted as two different things: instance field and class field. In another analogous case, the interpreter would be more consistent:

>>> tot = 0
>>> def addtot(x): tot+=x
>>> addtot(3)

If this tot is allowed to be resolved to different things, there should be no problem. Instead you get an error:

Traceback (most recent call last):
  File "<pyshell#106>", line 1, in <module>
    addtot(3)
  File "<pyshell#105>", line 1, in addtot
    def addtot(x): tot += x
UnboundLocalError: local variable 'tot' referenced before assignment

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23824>
_______________________________________

From report at bugs.python.org  Tue Mar 31 16:39:29 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Mar 2015 14:39:29 +0000
Subject: [issue22117] Rewrite pytime.h to work on nanoseconds
In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za>
Message-ID: <20150331143741.95098.28810@psf.io>


Roundup Robot added the comment:

New changeset dbc92a254173 by Victor Stinner in branch 'default':
Issue #22117: Fix integer overflow check in socket_parse_timeout() on Windows
https://hg.python.org/cpython/rev/dbc92a254173

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22117>
_______________________________________

From report at bugs.python.org  Tue Mar 31 16:39:29 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Mar 2015 14:39:29 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect)
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <20150331143741.95098.21647@psf.io>


Roundup Robot added the comment:

New changeset daf3d2a717e5 by Victor Stinner in branch 'default':
Issue #23618: Refactor internal_connect()
https://hg.python.org/cpython/rev/daf3d2a717e5

New changeset c59d81b802f8 by Victor Stinner in branch 'default':
Issue #23618: Refactor internal_connect()
https://hg.python.org/cpython/rev/c59d81b802f8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Tue Mar 31 16:41:00 2015
From: report at bugs.python.org (Jethro)
Date: Tue, 31 Mar 2015 14:41:00 +0000
Subject: [issue23824] in-place addition of a shadowed class field
In-Reply-To: <1427810483.28.0.753445482899.issue23824@psf.upfronthosting.co.za>
Message-ID: <1427812860.72.0.352938855489.issue23824@psf.upfronthosting.co.za>


Changes by Jethro <ylan at pku.edu.cn>:


----------
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23824>
_______________________________________

From report at bugs.python.org  Tue Mar 31 16:52:41 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 31 Mar 2015 14:52:41 +0000
Subject: [issue23823] "Generalization" misused in deque docs
In-Reply-To: <1427810162.43.0.413466648837.issue23823@psf.upfronthosting.co.za>
Message-ID: <1427813561.91.0.218997739344.issue23823@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Sorry, I disagree.

----------
nosy: +rhettinger
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23823>
_______________________________________

From report at bugs.python.org  Tue Mar 31 16:57:28 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 Mar 2015 14:57:28 +0000
Subject: [issue23824] in-place addition of a shadowed class field
In-Reply-To: <1427810483.28.0.753445482899.issue23824@psf.upfronthosting.co.za>
Message-ID: <1427813848.93.0.735322897997.issue23824@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, now I understand your confusion.  Class variables are special.  The first time you reference a name on an instance that is not currently defined on that instance but is defined on the class, the interpreter gets the object pointer from the class reference.  It then performs the operation, and assigns the result to the *instance* attribute.  This is how class attributes work, and is an integral part of Python.  This is documented in the 'class instances' section of https://docs.python.org/3/reference/datamodel.html#objects-values-and-types.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23824>
_______________________________________

From report at bugs.python.org  Tue Mar 31 17:01:39 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 31 Mar 2015 15:01:39 +0000
Subject: [issue23793] Support __add__, __mul__, and __imul__ for deques.
In-Reply-To: <1427477638.63.0.2394294758.issue23793@psf.upfronthosting.co.za>
Message-ID: <1427814099.12.0.382338987405.issue23793@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I don't see any technical reason not to proceed.  Just because an unusual combination of parameters feels odd to you doesn't make it wrong.  It is no different than (somelist * n)[-maxlen:].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23793>
_______________________________________

From report at bugs.python.org  Tue Mar 31 17:10:41 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 15:10:41 +0000
Subject: [issue23822] test_py_compile fails under -O
In-Reply-To: <1427809153.77.0.260576385757.issue23822@psf.upfronthosting.co.za>
Message-ID: <1427814641.71.0.787717062286.issue23822@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch.

----------
keywords: +patch
nosy: +serhiy.storchaka
stage: needs patch -> patch review
Added file: http://bugs.python.org/file38760/issue23822.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23822>
_______________________________________

From report at bugs.python.org  Tue Mar 31 17:13:30 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Mar 2015 15:13:30 +0000
Subject: [issue23793] Support __add__, __mul__, and __imul__ for deques.
In-Reply-To: <1427477638.63.0.2394294758.issue23793@psf.upfronthosting.co.za>
Message-ID: <20150331151246.91338.13134@psf.io>


Roundup Robot added the comment:

New changeset b75160d24b7b by Raymond Hettinger in branch 'default':
Issue 23793:  Add deque support for __add__(), __mul__(), and __imul__().
https://hg.python.org/cpython/rev/b75160d24b7b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23793>
_______________________________________

From report at bugs.python.org  Tue Mar 31 17:14:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 15:14:11 +0000
Subject: [issue23820] test_importlib fails under -O
In-Reply-To: <1427808935.25.0.609166440001.issue23820@psf.upfronthosting.co.za>
Message-ID: <1427814851.11.0.194351043066.issue23820@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch.

----------
keywords: +patch
nosy: +serhiy.storchaka
stage: needs patch -> patch review
Added file: http://bugs.python.org/file38761/issue23820.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23820>
_______________________________________

From report at bugs.python.org  Tue Mar 31 17:14:17 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 31 Mar 2015 15:14:17 +0000
Subject: [issue23793] Support __add__, __mul__, and __imul__ for deques.
In-Reply-To: <1427477638.63.0.2394294758.issue23793@psf.upfronthosting.co.za>
Message-ID: <1427814857.89.0.784175926191.issue23793@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23793>
_______________________________________

From report at bugs.python.org  Tue Mar 31 17:23:43 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 15:23:43 +0000
Subject: [issue23825] test_idle fails under -OO
Message-ID: <1427815423.26.0.42756532266.issue23825@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch.

----------
keywords: +patch
nosy: +serhiy.storchaka
stage: needs patch -> patch review
Added file: http://bugs.python.org/file38762/issue23825.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23825>
_______________________________________

From report at bugs.python.org  Tue Mar 31 17:54:13 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 15:54:13 +0000
Subject: [issue23821] test_pdb fails under -O
Message-ID: <1427817253.47.0.758333559242.issue23821@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Tests were added in issue16596.

----------
nosy: +asvetlov, gvanrossum, serhiy.storchaka, xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23821>
_______________________________________

From report at bugs.python.org  Tue Mar 31 18:10:38 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 16:10:38 +0000
Subject: [issue23826] test_enum fails under -OO
Message-ID: <1427818238.81.0.788495836451.issue23826@psf.upfronthosting.co.za>


New submission from Brett Cannon:

======================================================================
FAIL: test_pydoc (__main__.TestStdLib)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bcannon/Repositories/cpython/default/Lib/test/test_enum.py", line 1609, in test_pydoc
    self.assertEqual(result, expected_text)
AssertionError: 'Help[450 chars]n |  \n |  value\n |  \n |  ------------------[123 chars]rs__' != 'Help[450 chars]n |      The name of the Enum member.\n |  \n [394 chars]ing.'
Diff is 969 characters long. Set self.maxDiff to None to see it.

----------
components: Tests
messages: 239728
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_enum fails under -OO
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23826>
_______________________________________

From report at bugs.python.org  Tue Mar 31 18:13:02 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 16:13:02 +0000
Subject: [issue23821] test_pdb fails under -O
In-Reply-To: <1427817253.47.0.758333559242.issue23821@psf.upfronthosting.co.za>
Message-ID: <1427818382.24.0.0858642750462.issue23821@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file38763/issue23821.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23821>
_______________________________________

From report at bugs.python.org  Tue Mar 31 18:13:13 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 16:13:13 +0000
Subject: [issue23821] test_pdb fails under -O
In-Reply-To: <1427817253.47.0.758333559242.issue23821@psf.upfronthosting.co.za>
Message-ID: <1427818393.88.0.558499153136.issue23821@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23821>
_______________________________________

From report at bugs.python.org  Tue Mar 31 18:25:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 16:25:08 +0000
Subject: [issue23826] test_enum fails under -OO
In-Reply-To: <1427818238.81.0.788495836451.issue23826@psf.upfronthosting.co.za>
Message-ID: <1427819108.53.0.630053870165.issue23826@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch.

----------
keywords: +patch
nosy: +serhiy.storchaka
stage: needs patch -> patch review
Added file: http://bugs.python.org/file38764/issue23826.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23826>
_______________________________________

From report at bugs.python.org  Tue Mar 31 18:47:28 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 31 Mar 2015 16:47:28 +0000
Subject: [issue23360] Content-Type when sending data with urlopen()
In-Reply-To: <1422794612.5.0.505084736818.issue23360@psf.upfronthosting.co.za>
Message-ID: <1427820448.09.0.657243576192.issue23360@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +demian.brecht

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23360>
_______________________________________

From report at bugs.python.org  Tue Mar 31 18:48:43 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 16:48:43 +0000
Subject: [issue18473] some objects pickled by Python 3.x are not unpicklable
 in Python 2.x because of incorrect REVERSE_IMPORT_MAPPING
In-Reply-To: <1373973767.04.0.0542870445433.issue18473@psf.upfronthosting.co.za>
Message-ID: <1427820523.75.0.401526268916.issue18473@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18473>
_______________________________________

From report at bugs.python.org  Tue Mar 31 18:49:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 16:49:01 +0000
Subject: [issue23611] Pickle nested names with protocols < 4
In-Reply-To: <1425837040.48.0.408829364916.issue23611@psf.upfronthosting.co.za>
Message-ID: <1427820541.9.0.534055788945.issue23611@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23611>
_______________________________________

From report at bugs.python.org  Tue Mar 31 18:51:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 16:51:09 +0000
Subject: [issue23824] in-place addition of a shadowed class field
In-Reply-To: <1427810483.28.0.753445482899.issue23824@psf.upfronthosting.co.za>
Message-ID: <1427820669.52.0.773729773489.issue23824@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23824>
_______________________________________

From report at bugs.python.org  Tue Mar 31 18:52:44 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 16:52:44 +0000
Subject: [issue23827] test.test_multiprocessing_spawn fails under -Werror
Message-ID: <1427820764.77.0.00384265932855.issue23827@psf.upfronthosting.co.za>


New submission from Brett Cannon:

======================================================================
FAIL: test_sys_exit (__main__.WithProcessesTestSubclassingProcess)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bcannon/Repositories/cpython/pep-488/Lib/test/_test_multiprocessing.py", line 483, in test_sys_exit
    self.assertEqual(f.read().rstrip(), str(reason))
AssertionError: "[1, 2, 3]\nException ignored in: <_io.Fi[136 chars]-8'>" != '[1, 2, 3]'
- [1, 2, 3]
?          -
+ [1, 2, 3]- Exception ignored in: <_io.FileIO name='/dev/null' mode='rb' closefd=True>
- ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='r' encoding='UTF-8'>

----------
components: Tests
messages: 239731
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test.test_multiprocessing_spawn fails under -Werror
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23827>
_______________________________________

From report at bugs.python.org  Tue Mar 31 18:53:13 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 31 Mar 2015 16:53:13 +0000
Subject: [issue23826] test_enum fails under -OO
In-Reply-To: <1427818238.81.0.788495836451.issue23826@psf.upfronthosting.co.za>
Message-ID: <1427820793.53.0.200970067675.issue23826@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23826>
_______________________________________

From report at bugs.python.org  Tue Mar 31 18:55:36 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 16:55:36 +0000
Subject: [issue23828] test_socket fails under -Werror
Message-ID: <1427820936.86.0.258398348531.issue23828@psf.upfronthosting.co.za>


New submission from Brett Cannon:

======================================================================
ERROR: testCmsgTruncLen0 (__main__.RecvmsgSCMRightsStreamTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bcannon/Repositories/cpython/pep-488/Lib/test/test_socket.py", line 2956, in testCmsgTruncLen0
    self.checkTruncatedArray(ancbuf=socket.CMSG_LEN(0), maxdata=0)
  File "/Users/bcannon/Repositories/cpython/pep-488/Lib/test/test_socket.py", line 2937, in checkTruncatedArray
    len(MSG), ancbuf)
  File "/Users/bcannon/Repositories/cpython/pep-488/Lib/test/test_socket.py", line 1921, in doRecvmsg
    result = sock.recvmsg(bufsize, *args)
RuntimeWarning: received malformed or improperly-truncated ancillary data

----------
components: Tests
messages: 239732
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_socket fails under -Werror
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23828>
_______________________________________

From report at bugs.python.org  Tue Mar 31 18:55:57 2015
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 31 Mar 2015 16:55:57 +0000
Subject: [issue23602] Implement __format__ for Fraction
In-Reply-To: <1425747969.33.0.749439080082.issue23602@psf.upfronthosting.co.za>
Message-ID: <1427820957.33.0.975812131026.issue23602@psf.upfronthosting.co.za>


Stefan Krah added the comment:

> It wouldn't be too bad if Py and C version of Decimal.__format__ had
> same interface. What do you think?

Let's discuss that in a separate issue.


[DefaultContext]
> I don't understand what do you mean with this. Is this something that
> I'm doing wrong in my patch or just another (related?) issue?

Decimal.DefaultContext has global scope and currently affects
Context() creation, unless you specify all parameters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23602>
_______________________________________

From report at bugs.python.org  Tue Mar 31 18:56:21 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 31 Mar 2015 16:56:21 +0000
Subject: [issue23829] test_warnings fails under -Werror
Message-ID: <1427820981.19.0.491329560672.issue23829@psf.upfronthosting.co.za>


New submission from Brett Cannon:

======================================================================
ERROR: test_warning_classes (__main__.CWarnTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/bcannon/Repositories/cpython/pep-488/Lib/test/test_warnings.py", line 460, in test_warning_classes
    self.module.warn('good warning category', MyWarningClass)
WarnTests.test_warning_classes.<locals>.MyWarningClass: good warning category

----------
components: Tests
messages: 239734
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: test_warnings fails under -Werror
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23829>
_______________________________________

From report at bugs.python.org  Tue Mar 31 18:59:41 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 31 Mar 2015 16:59:41 +0000
Subject: [issue23826] test_enum fails under -OO
In-Reply-To: <1427818238.81.0.788495836451.issue23826@psf.upfronthosting.co.za>
Message-ID: <1427821181.98.0.951941218048.issue23826@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee:  -> ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23826>
_______________________________________

From report at bugs.python.org  Tue Mar 31 19:10:37 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Mar 2015 17:10:37 +0000
Subject: [issue18473] some objects pickled by Python 3.x are not unpicklable
 in Python 2.x because of incorrect REVERSE_IMPORT_MAPPING
In-Reply-To: <20150331135729.119996.27029@psf.io>
Message-ID: <CAMpsgwZV0C0Vgt9=VMjxix9Le0NLn_aF6BzVhntR=Fme8HPAUw@mail.gmail.com>


STINNER Victor added the comment:

Le mardi 31 mars 2015, Roundup Robot <report at bugs.python.org> a ?crit :

>
> Roundup Robot added the comment:
>
> New changeset 5c5eb374e296 by Serhiy Storchaka in branch '3.4':
> Issue #18473: Fixed pickle compatibility tests for optional modules.
> https://hg.python.org/cpython/rev/5c5eb374e296
>
> New changeset 29b2b2d8e36f by Serhiy Storchaka in branch 'default':
> Issue #18473: Fixed pickle compatibility tests for optional modules.
> https://hg.python.org/cpython/rev/29b2b2d8e36f
>

Why do you catch AttributeError on import?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18473>
_______________________________________

From report at bugs.python.org  Tue Mar 31 19:14:07 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 17:14:07 +0000
Subject: [issue23829] test_warnings fails under -Werror
In-Reply-To: <1427820981.19.0.491329560672.issue23829@psf.upfronthosting.co.za>
Message-ID: <1427822047.67.0.719120776758.issue23829@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue23027.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> test_warnings fails with -Werror

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23829>
_______________________________________

From report at bugs.python.org  Tue Mar 31 19:16:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 17:16:18 +0000
Subject: [issue23827] test.test_multiprocessing_spawn fails under -Werror
In-Reply-To: <1427820764.77.0.00384265932855.issue23827@psf.upfronthosting.co.za>
Message-ID: <1427822178.37.0.734660339503.issue23827@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue21779.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> test_multiprocessing_spawn fails when ran with -Werror

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23827>
_______________________________________

From report at bugs.python.org  Tue Mar 31 19:17:28 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 31 Mar 2015 17:17:28 +0000
Subject: [issue23812] asyncio.Queue.put_nowait(),
 followed get() task cancellation leads to item being lost
In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za>
Message-ID: <1427822248.36.0.88112786724.issue23812@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I'm sorry, I don't have time to review this (and it's subtle enough that I don't want to approve it without understanding).

Maybe Victor understands?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23812>
_______________________________________

From report at bugs.python.org  Tue Mar 31 19:23:32 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 17:23:32 +0000
Subject: [issue18473] some objects pickled by Python 3.x are not unpicklable
 in Python 2.x because of incorrect REVERSE_IMPORT_MAPPING
In-Reply-To: <1373973767.04.0.0542870445433.issue18473@psf.upfronthosting.co.za>
Message-ID: <1427822612.46.0.388550582237.issue18473@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Why do you catch AttributeError on import?

Because importing multiprocessing.popen_fork raises AttributeError on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18473>
_______________________________________

From report at bugs.python.org  Tue Mar 31 19:35:08 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 31 Mar 2015 17:35:08 +0000
Subject: [issue16991] Add OrderedDict written in C
In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za>
Message-ID: <1427823308.21.0.682696909155.issue16991@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

> do not add a C-API

what speaks against it?

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16991>
_______________________________________

From report at bugs.python.org  Tue Mar 31 19:39:56 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Mar 2015 17:39:56 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect)
In-Reply-To: <20150331143741.95098.21647@psf.io>
Message-ID: <CAMpsgwaiWziTPy3fkvcjbhQcXNS6nyX_3PdzYrDkZRuhU1ASyg@mail.gmail.com>


STINNER Victor added the comment:

Le mardi 31 mars 2015, Roundup Robot <report at bugs.python.org> a ?crit :
>
> New changeset c59d81b802f8 by Victor Stinner in branch 'default':
> Issue #23618: Refactor internal_connect()
> https://hg.python.org/cpython/rev/c59d81b802f8
>

Oh I forgot to add an #ifdef for socklen_t. I didn't get a warning, so
socklen_t is probably an int. Getsockopt() uses a int* for the value length.

I also forgot to drop the comment before SetLastError(), it's no more
revelant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Tue Mar 31 19:40:43 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 17:40:43 +0000
Subject: [issue19100] Use backslashreplace in pprint
In-Reply-To: <1380279910.92.0.349060015388.issue19100@psf.upfronthosting.co.za>
Message-ID: <1427823643.48.0.422886402142.issue19100@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> What is the reasoning behind the DecodeWriter case, where the original stream has an interesting encoding, but ?buffer? is None? Are there any real-world cases like that?

sys.stdout and sys.stderr in IDLE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19100>
_______________________________________

From report at bugs.python.org  Tue Mar 31 20:28:59 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 31 Mar 2015 18:28:59 +0000
Subject: [issue23555] behavioural change in argparse set_defaults in python
 2.7.9
In-Reply-To: <1425209556.02.0.589190597278.issue23555@psf.upfronthosting.co.za>
Message-ID: <1427826539.25.0.395462965964.issue23555@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
superseder:  -> argparse silently ignores arguments

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23555>
_______________________________________

From report at bugs.python.org  Tue Mar 31 21:01:24 2015
From: report at bugs.python.org (Neale Ferguson)
Date: Tue, 31 Mar 2015 19:01:24 +0000
Subject: [issue23830] Add AF_IUCV support to sockets
Message-ID: <1427828484.47.0.0998681334057.issue23830@psf.upfronthosting.co.za>


New submission from Neale Ferguson:

IUCV is a hypervisor mediated communications method for z/VM guest virtual machines. Linux on z Systems (aka s390x) has supported this via the use of AF_IUCV sockets for many years (added to kernel Feb 2007). This suggested patch adds support to Python 2.7.9 for this socket type. I have built Python on both s390x and x86_64: both build cleanly and the test added to test_socket.py runs cleanly on s390x and is skipped on other platforms.

----------
components: Library (Lib)
files: af_iucv.patch
keywords: patch
messages: 239743
nosy: neale
priority: normal
severity: normal
status: open
title: Add AF_IUCV support to sockets
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file38765/af_iucv.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23830>
_______________________________________

From report at bugs.python.org  Tue Mar 31 21:32:02 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Mar 2015 19:32:02 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect)
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <20150331193118.119980.60070@psf.io>


Roundup Robot added the comment:

New changeset d9374864d4a9 by Victor Stinner in branch 'default':
Issue #23618: Cleanup internal_connect() in socketmodule.c
https://hg.python.org/cpython/rev/d9374864d4a9

New changeset 4fad2b9fc4e6 by Victor Stinner in branch 'default':
Issue #23618: Fix EINTR handling in socket.connect()
https://hg.python.org/cpython/rev/4fad2b9fc4e6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Tue Mar 31 22:15:32 2015
From: report at bugs.python.org (mps)
Date: Tue, 31 Mar 2015 20:15:32 +0000
Subject: [issue23831] tkinter canvas lacks of moveto method.
Message-ID: <1427832932.11.0.38662420535.issue23831@psf.upfronthosting.co.za>


New submission from mps:

I apologize if it has already been reported but I was unable to find similar issue reported using "search".

Maybe just add:
    def moveto(self, tagOrId, xPos, yPos):
        """Move the items given by tagOrId in the canvas coordinate  
        space so that the first coordinate pair of the bottommost 
        item with tag tagOrId is located at position (xPos,yPos). 
        xPos and yPos may be the empty string, in which case the        
        corresponding coordinate will be unchanged. All items matching
        tagOrId remain in the same positions relative to each other.    
        This command returns an empty string. 
        """
        return self.tk.call(self._w, 'moveto', tagOrId, xPos, yPos)

----------
components: Tkinter
messages: 239745
nosy: mps
priority: normal
severity: normal
status: open
title: tkinter canvas lacks of moveto method.
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23831>
_______________________________________

From report at bugs.python.org  Tue Mar 31 22:15:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Mar 2015 20:15:57 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect)
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <1427832957.51.0.92287136533.issue23618@psf.upfronthosting.co.za>


STINNER Victor added the comment:

connect_eintr-4.patch: Updated patch after all my changes to refactor socket.connect() (which is now almost a rewrite from scratch!).

----------
Added file: http://bugs.python.org/file38766/connect_eintr-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Tue Mar 31 22:20:21 2015
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 31 Mar 2015 20:20:21 +0000
Subject: [issue23821] test_pdb fails under -O
In-Reply-To: <1427817253.47.0.758333559242.issue23821@psf.upfronthosting.co.za>
Message-ID: <1427833221.82.0.621165115135.issue23821@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

FWIW looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23821>
_______________________________________

From report at bugs.python.org  Tue Mar 31 22:24:05 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Mar 2015 20:24:05 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect)
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <20150331202350.120004.44948@psf.io>


Roundup Robot added the comment:

New changeset 7ed567ad8b4c by Victor Stinner in branch 'default':
Issue #23618: Enhance EINTR handling in socket.connect()
https://hg.python.org/cpython/rev/7ed567ad8b4c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Tue Mar 31 22:24:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 Mar 2015 20:24:17 +0000
Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect)
In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za>
Message-ID: <1427833457.18.0.781376262008.issue23618@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file38767/connect_eintr-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23618>
_______________________________________

From report at bugs.python.org  Tue Mar 31 22:35:12 2015
From: report at bugs.python.org (Gerrit Holl)
Date: Tue, 31 Mar 2015 20:35:12 +0000
Subject: [issue23832] pdb's `longlist` shows only decorator if that one
 contains a lambda
Message-ID: <1427834112.73.0.627625379595.issue23832@psf.upfronthosting.co.za>


New submission from Gerrit Holl:

When a decorater contains a `lambda` declaration, using the pdb command `longlist` will show only the definition of the decorator.  The definition of the function itself is not shown:


cat mini.py

#!/usr/bin/python3.4

def foo(x, y=None):
    return x

@foo(foo, lambda a:a)
def spam():
    0+0
    1+1
    1/0

spam()
$ python3.4 -mpdb mini.py                                                                                                                                               
> /tmp/mini.py(3)<module>()
-> def foo(x, y=None):
(Pdb) cont
Traceback (most recent call last):
  File "/usr/lib64/python3.4/pdb.py", line 1661, in main
    pdb._runscript(mainpyfile)
  File "/usr/lib64/python3.4/pdb.py", line 1542, in _runscript
    self.run(statement)
  File "/usr/lib64/python3.4/bdb.py", line 431, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "/tmp/mini.py", line 3, in <module>
    def foo(x, y=None):
  File "/tmp/mini.py", line 10, in spam
    1/0
ZeroDivisionError: division by zero
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> /tmp/mini.py(10)spam()
-> 1/0
(Pdb) longlist
  6     @foo(foo, lambda a:a)
(Pdb) 


The last line illustrates the problem.  `longlist` should show the definition of `spam`, not just the decorator.

----------
messages: 239749
nosy: Gerrit.Holl
priority: normal
severity: normal
status: open
title: pdb's `longlist` shows only decorator if that one contains a lambda
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23832>
_______________________________________

From report at bugs.python.org  Tue Mar 31 22:49:07 2015
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 31 Mar 2015 20:49:07 +0000
Subject: [issue21526] Support new booleans in Tkinter
In-Reply-To: <1400445691.82.0.48051274053.issue21526@psf.upfronthosting.co.za>
Message-ID: <1427834947.64.0.952585180577.issue21526@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

I'm not sure that this change is correct.
I have Tcl version 8.6 installed, and I checked that "app->BooleanType" is NULL.

Fortunately value->typePtr is probably never NULL, but I think the comparison should be skipped in this case.

Where did you see this booleanString?

----------
nosy: +amaury.forgeotdarc
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21526>
_______________________________________

From report at bugs.python.org  Tue Mar 31 23:09:06 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 21:09:06 +0000
Subject: [issue21526] Support new booleans in Tkinter
In-Reply-To: <1400445691.82.0.48051274053.issue21526@psf.upfronthosting.co.za>
Message-ID: <1427836146.85.0.786801876883.issue21526@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The case (value->typePtr == NULL) is tested above for purpose, so it is not a bug when one of type pointers is NULL.

"booleanString" was added in 8.5, replacing "boolean", but in 8.6 it is not used. All boolean values in 8.6 are just integers 0 and 1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21526>
_______________________________________

From report at bugs.python.org  Tue Mar 31 23:46:30 2015
From: report at bugs.python.org (Craig Holmquist)
Date: Tue, 31 Mar 2015 21:46:30 +0000
Subject: [issue23779] imaplib authenticate raises TypeError if authenticator
 tries to abort
In-Reply-To: <1427322083.72.0.863898159285.issue23779@psf.upfronthosting.co.za>
Message-ID: <1427838390.89.0.0771024139812.issue23779@psf.upfronthosting.co.za>


Craig Holmquist added the comment:

Okay, I attached another patch.  The new version of the test returns success if the client's response is anything other than the abort line (*\r\n).

It fails with the current version of imaplib, fails if I change _Authenticator.process to output a byte-string besides *, and succeeds with the change in the patch.

----------
Added file: http://bugs.python.org/file38768/imap_auth3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23779>
_______________________________________